分布式秒杀系统的设计

分布式秒杀系统的设计

前言

不知道你在面试的过程中有没有被问到如何设计一个分布式秒杀系统?本篇博客根据大神们的梳理的体系并结合自己实际的项目经验，大致描述我们在设计分布式秒杀系统需要关注的核心内容——分布式锁、分布式限流、消息队列等等，希望可以帮助同学们可以在面试中更加从容地回答这个问题。

正文

分布式秒杀系统的设计

秒杀系统的核心的问题

• 并发读：核心的优化理念是减少用户到服务端来“读”数据，或者让他们读更少的数据；
• 并发写：要求在数据库层面独立出一个库，做特殊处理，可以理解为为秒杀设计专门的表，精简表字段。

秒杀系统的的基本要求：

• 高性能:涉及大量并发读写，可以从缓存、消息队列、 请求削峰等角度进行设计
• 一致性:保证秒杀减库存中的数据一致性。
• 高可用:保证系统的高可用和正确性，设计PlanB进行兜底。

架构原则（4要1不要）：

• 数据要尽量少：用户请求与响应的数据尽可能得少，可以减少数据序列化与反序列化的性能损耗；
• 请求数要尽量少：减少或者合并css/java script、图片，以及Ajax请求等，TCP三次握手，DNS解析等都会有资源消耗；
• 路径要尽量短：用户发出请求到返回数据这个过程中，需求经过的中间的节点数尽可能少，尽可能使用RPC调用，提升系统性能；
• 依赖要尽量少：依赖，指的是要完成一次用户请求必须依赖的系统或者服务；
• 不要有单点：无论是系统资源还是数据资源在设计的时候一定要考虑冗余。

根据上述的，可以设计如下：

秒杀系统的实现：

• 分布式限流：采用sentinel的方式进行分布式限流，诸如warm up（预热）、拒绝、匀速排队等手段；
• 负载均衡：对系统进行微服务化，拆分成商品中心、用户中心、订单中心；
• 缓存的使用：对热点数据（遵循二八原则）并且对实时性要求不高的数据进行缓存处理，如商品的基本信息；
• 消息队列的使用：针对可以异步处理的操作，如下单，采用消息队列的方式进行处理， 实行流量削峰；
• 分布式锁：进行抢购时采用分布式锁的方式保证不会出现“超卖现象”；

如何防止“超卖”现象

秒杀系统防止的“超卖”的关键在于减库存的方式，通常有三种：

• 下单减库存：一定不会出现超卖情况，但是有些人下单完不付款会影响其他人。
• 付款减库款：付款减库存，可能会因为并发高导致付款时已经卖光，付不了款。
• 预扣库存：最常用，如下单后扣库存，保留十分钟，在十分钟内未付款就不保留。如果付款时发现库存不足则不允许付款。

预扣库存，存在“黄牛抢单”恶意抢单的情况，可以通过信誉积分、设置最大购买数、已有未支付订单不允许再次下单等方式进行控制，预扣库存通常使用分布式锁来实现的。

关于系统的设计中涉及的技术可移步：

• 分布式锁可参考我的博客：从悲观锁、乐观锁到分布式锁

• 负载均衡等分布式知识可参考我的博客：溪源的Java笔记—分布式

• 消息队列可参考我的博客：溪源的Java笔记—消息队列

• 分布式限流可参考我的博客：高并发之限流算法

• springboot实现商品秒杀功能可参考我的博客：springboot实现商品秒杀功能