logo

缓存设计实战:静山平台

在秒杀场景中,有一些接口的请求频率会明显高于其他接口,我们应该针对这些高频接口做定向缓存优化。

商品详情接口

商品详情接口是整个系统中压力最大的接口,用户在购买之前会访问很多次商品详情。商品详情页面中,包含介绍视频、头部轮播图、详情页面、多个价格、该商品参加的活动、可以领取的优惠券等信息。

我们可以根据商品被访问的热度,将商品的数据缓存下来。不同的字段对缓存时间的敏感程度是不一样的:商品的基础信息变化的频率较低,我们可以缓存比较长的时间,例如一分钟。而有些信息像价格对时效性的要求很高,需要非常快地更新缓存。

库存查询接口

商品库存数量是一个对时间高度敏感的字段,而且这个值和下单接口高度相关,可以说库存查询和下单一起组成了电商秒杀系统中最核心的那个“单点”。

首先,库存及时归零可以在前端就拦截掉海量的对下单接口的无效调用:没有库存的商品无论如何是无法下单成功的,这些发送到后端的压力都是没有收益的浪费资源。

其次,哪怕只出现了一单超卖,平台和商户都会为此承担额外的损失。在最严格的系统架构设计中,这是不可接受的,属于系统设计上的失败。

购物车价格计算

和商品详情比,这并不是一个高并发接口,但是随着近两年电商平台的内卷,到手价预估,自动领券并结算,以及自动计算最优惠的折扣方案等需求的提出,给购物车价格计算工作上了强度,这个接口的响应时长和占据的 CPU 资源急剧上升,从架构师到 RD,从运营到测试,天下苦购物车久矣...

下单接口

下单接口是截止到目前唯一的一个高并发“写入”的接口,可能也是唯一一个需要实时体现出影响的写入型接口。下单接口需要处理好以下几个重要问题。

  1. 不要宕机:服务可用是一切的基础,在所有需求之前,需要先保证下单业务的持续运行。
  2. 避免超卖:这是秒杀业务最重要的需求,超卖一单就是一单的成本,涉及到钱,要小心处理。
  3. 重复点击:在秒杀的时候,用户很容易出现重复点击的情况,这就需要前端后端配合,避免重复下单的情况发生。
  4. 错误回滚:在高并发情形下,系统可能会出现各种异常,甚至接口数据前后不一致的情况,这就需要在每一步做好错误判断和状态回滚,避免系统陷入错误沼泽,无法自拔。
  5. 避免少卖:如果卖出去的商品数量低于秒杀设置的值也是一种损失。
  6. 库存计算的正确性:大部分时候,库存的计算是避免超卖、发生错误、超买等问题的核心步骤,只要库存的计算不出错,其他大部分问题都可以避免。
  7. 阻止刷单:很多人会利用机器人来刷单,刷单会对系统造成非常大的负担,需要尽可能地识别出来,屏蔽掉。
  8. 防止恶意攻击:秒杀是系统最脆弱的时候,最适合执行恶意攻击,容易出现恶意占用接口资源的攻击行为。我们可以使用严格的数据校验、验证码、请求频率限制等方法来降低恶意攻击行为对系统造成的影响。

支付接口

每个订单都需要至少一次支付,在秒杀开始以后,支付接口也会面临非常高的请求压力,需要提前和支付服务方做好流量预估和技术方案,必要的时候引入多个支付通道进行在线支付,并且要对支付失败做好回滚策略,避免整个系统的“雪崩”。

订单状态查询接口

用户在秒杀结束后会频繁查询订单的支付状态和发货状态,此时订单列表和订单详情的压力就变得特别大。这一点我们可以和天猫学习:双 11 刚开始的几分钟,用户无法实时查询到订单的支付状态,在购买系统和支付系统度过了最初的超高压力后,再异步慢慢补上支付状态。此外,在双 11 当天,天猫限制所有用户都只能看到三个月之内的订单。一方面,这可以避免“冷数据”的激活对系统造成过大的压力,另一方面也可以直接把三个月内的订单全部缓存下来,无论是用数据库做磁盘缓存还是直接做内存缓存,都可以有效提升整个系统的响应速度。

排行榜接口

排行榜也是一个容易被忽视的高并发场景。由于需要对最高销量的商品进行数据统计,这个行为会给系统带来巨大的压力。此外,许多用户,尤其是卖家以及他们开发的机器人,会频繁地访问排行榜接口。因此我们必须对排行榜接口进行全缓存设计。实时统计将给数据库带来极大的压力,容易导致系统宕机。

阅读数:2470      字数:1691 最后更新:2023-10-26 17:58:26