缓存设计实战：静山平台

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

商品详情接口

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

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

库存查询接口

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

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

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

购物车价格计算

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

下单接口

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

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

支付接口

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

订单状态查询接口

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

排行榜接口

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