如何设计一个秒杀系统和架构原则

如何设计一个秒杀系统

• 主要解决两个问题：一个是并发读，一个是并发写
  • 并发读：并发读的核心优化理念是尽量减少用户到服务端来“读”数据，或者让他们读更少的数据；
  • 并发写的处理原则也一样，它要求我们在数据库层面独立出来一个库，做特殊的处理。
• 遵循的原则：保证用户请求的数据尽量少、请求数尽量少、路径尽量短、依赖尽量少，并且不要有单点。
• 高性能。 秒杀涉及大量的并发读和并发写，因此支持高并发访问这点非常关键。本专栏将从设计数据的动静分离方案、热点的发现与隔离、请求的削峰与分层过滤、服务端的极致优化这 4 个方面重点介绍。
• 一致性。 秒杀中商品减库存的实现方式同样关键。可想而知，有限数量的商品在同一时刻被很多倍的请求同时来减库存，减库存又分为“拍下减库存”“付款减库存”以及预扣等几种，在大并发更新的过程中都要保证数据的准确性，其难度可想而知。因此，我将用一篇文章来专门讲解如何设计秒杀减库存方案。
• 高可用。 虽然我介绍了很多极致的优化思路，但现实中总难免出现一些我们考虑不到的情况，所以要保证系统的高可用和正确性，我们还要设计一个 PlanB 来兜底，以便在最坏情况发生时仍然能够从容应对。专栏的最后，我将带你思考可以从哪些环节来设计兜底方案。

---

架构原则

• 数据尽量少
  • 数据包括用户上传给系统的数据和系统返回给用户的数据（通常就是网页）。原因1是网络传输需要时间，2是数据需要服务器处理（压缩和字符解码等），这些都非常消耗CPU。例如，可以简化秒杀页面大小，去掉不必要的装饰效果等。
  • 除此之外，系统依赖的数据也尽量少，包括完成业务逻辑需要读取和保存的数据。尽量和数据库打交道越少越好，数据越简单越好。
• 请求数尽量少
  • 用户请求的页面返回后，浏览器渲染页面还需要额外的请求，比如页面依赖的CSS/JS、图片等等。一个例子是可以将CSS和JS文件合并，在URL中用逗号隔开。这些文件在服务端仍然各自存放，但服务端用一个组件进行解析，然后合并后一起返回。
• 路径尽量短
  • 从用户发出请求到返回数据经过的中间节点数尽可能少。节点可能是一个系统或者一个socket连接
• 依赖尽量少
  • 指的是完成一次用户请求必须依赖的系统或者服务。
  • 如要展示秒杀页面，必须有商品信息、用户信息，但比如优惠券、成交列表这种弱依赖紧急情况可以不要。
  • 方法：可以给系统分级，例如支付系统是0级，优惠券系统1级，要减少0级系统对1级系统的强依赖，防止0级系统被后面的系统拖垮
• 不要有单点
  • 单点就意味着没有备份，分布式系统的设计中最重要的原则就是消除单点。
  • 方法：关键是避免将服务的状态跟机器绑定，即把服务无状态化，这样服务就可以在机器中随意移动。例如可以把和机器相关的配置参数化，并用配置中心进行配置，服务启动时就动态获取。对于必须要绑定的（例如存储服务），则可以通过冗余多个备份解决。