电商秒杀系统设计分析

1，乐视秒杀，每秒钟10万的订单更新（insert/update），以用户ID分库分表，二叉树分库扩容，表级同步，DB1 - DB8， order1 - order10， DB编号 = （uid/10）%8，表编号=uid%10，这样单库基本上可以保持1万左右的并发，可以业务层分库分表，也可以使用mycat之类的中间件。

订单ID结构：分库分表信息+时间戳+机器号+自增序号,分信息：1bit数据库编号如5，第2bit为表编号如3，但是为了保证最终扩容，分库信息=(uid / 10) %64 +1，扩容到16 32 64个库都不是问题 。但是还需要根据商户ID来查询订单，所以又引入对商户维度的order表集群，将uid维度的order集群冗余一份到商户ID维度的order表集群，这样可以支持多维度查询，保持2个维度集群使用MQ异步同步，MQ也会异常导致数据不一致，引入实时监控服务，实时计算2个维度集群差异，做一致性同步。

1级，订单、支付流水，对实时和准确性要求高，不加入任何缓存，读写直接DB。2级，用户数据相关，读多写少，采用redis缓存。3级，支付配置，量少读多，用内存本地缓存，使用高可用消息推送平台，修改配置则推送更新并反馈。

采用nginx的nginx_max_conns限流修改DB并发为有限并发异步写，创建1个TaskQueue，所有DB写入放入并发度16的TaskQueue，通过queue异步更新DB。抢购库采用redis的nosql，属于业务层不属于数据层，然后在抢购库前再加上redis list队列，如产品A配置了20件，来了N个人，均会查询redis队列的长度，<=0则有权限减抢购库库存，队列长度<20则等待对头位置获取抢购权限，太长则直接返回。

2，同一商品并发读放到缓存中，采用一致性hash，同一个key在同一台机器，也采用应用层内存，应用上缓存相关数据（也有动静态），如不变属性（标题），在描述

前推到秒杀机器并缓存到描述结束，库存动态采用被动缓存方式一定时间（数秒），失效再去tair缓存拉取最新数据，真正写数据时仍然会一致性。

热点商品放在单独热点库，应用层做排队，DB做限流队列，在InnoDB做patch，单行做并发排队，可对多条SQL做合并。

3，request进来可以采用redis的inc/desc，扣完则直接返回

可以采用事务控制流程，也可以先去一个表insert之类拿一个资格，然后处理流程，实际库存扣减失败要更新到缓存中，拦截+数据一致性。

也可以将num保存到redis，多个用户对num进行desc，并且返回值，大于0时才生成订单，redis为单线程处理数据。

4，引入队列，所有写DB在队列中排队，串行，达到阈值就不再消费队列，关闭购买。解决超卖，但是多种商品则需要多条队列。

写操作到memcache中，利用memcache的cas锁减库存，同一时刻只有1个写入成功，解决建库存问题。

5，京东提交订单，1次订单要写10多张表，当订单数达到上万时，系统就无法承受，就将订单转化为xml，这样只写一张表，后面再去做异步，先将整个xml订单

的信息存储下来，然后再通过状态机异步写原来的10多张表数据，针对商品维度、商品ID等所有数据会异构一份到库存、促销、商品，又将数据分为A,B,C包，

A可能为基础数据，B为扩展数据例如。

装1个程序承载异步MYSQL的数据落地，再通过work写到MYSQL服务里面，正常双写MYSQL，redis，购物车服务端存储，GZIP压缩。

6，将提交操作变成两段式，先申请后确认。然后利用Redis的原子自增操作，同时利用Redis的事务特性来发号，保证拿到小于等于库存阀值的号的人都可以成功提交订单。然后数据异步更新到DB中。

优点：解决超卖问题，库存读写都在内存中，故同时解决性能问题。

缺点：由于异步写入DB，可能存在数据不一致。另可能存在少买，也就是如果拿到号的人不真正下订单，可能库存减为0，但是订单数并没有达到库存阀值。

7，一号店做法

排队模块：负责接收用户的抢购请求，将请求以先入先出的方式保存下来。每一个参加秒杀活动的商品保存一个队列，队列的大小可以根据参与秒杀的商品数量（或加点余量）自行定义。排队模块还负责提供一系列接口，如：给已进入队列的用户查询下单状态的接口，给调度模块拉取请求的接口，服务模块回写业务处理状态的接口等。

调度模块：负责排队模块到服务模块的动态调度，不断检查服务模块，一旦处理能力有空闲，就从排队队列头上把用户访问请求调入服务模块。并负责向服务模块分发请求。这里调度模块扮演一个中介的角色，但不只是传递请求而已。它还担负着调节系统处理能力的重任。我们可以根据服务模块的实际处理能力，动态调节向排队系统拉取请求的速度。作用有点类似水坝的闸门，当下游干旱时就打开闸门多放些水，当下游洪涝时，就放下闸门少放些水。

服务模块：是负责调用真正业务处理服务，并返回处理结果，并调用排队模块的接口回写业务处理结果。我们设计这个模块，是为了和后面真正的业务处理服务解耦。目前我们的系统不只支持秒杀抢购这种业务场景，后续有其他适用于排队系统的业务都可以接入，如：领取抵用券等等。同时我们也可以针对后面业务系统的处理能力，动态调节服务模块调用后面业务处理服务的速度。

8，站点层是可以通过加机器扩容的，最不济1k台机器来呗。