秒杀系统设计中的数据处理

前两篇文章，从业务端和技术端分析了秒杀系统的构建中咱们能够采用的思路。收到部分同窗的留言，问了一些细节上的问题，今天会集中整理一下这些问题，做为秒杀系列的一个收尾。

昨天提到了商品详情页要作静态化的问题。实际上，页面上仍是有一些动态数据，例如购买人数，购买比例这样的动态数据（见下图），那么问题就来了，在秒杀条件下，这种频繁更新的动态数据一旦数据更新不及时，会有大量的前端请求，透传到后端来，会不会致使超卖呢？

这是一个很好的问题，我这里的答案是，不会的，最终的一致性不是靠前端来完成的。在读的场景下，为了保证系统的总体性能，咱们是能够容许必定的“脏数据”，这里的不一致性的影响是颇有限的，只会让少许一些本来已经没有库存的下单请求误认为还有库存而已。在达到CAP的过程当中，须要有所平衡和取舍，这里就是经过一致性来换取高可用性作平衡，来解决这种高并发的数据读取问题。

从这个问题，咱们能够引伸出一个咱们秒杀系统中读写数据的原则

读数据： 不作强一致性校验，数据经过分层校验来修正。

写数据： 写数据进行强一致性校验，经过限流保护来保证写数据的成功性。

根据这个原则，在秒杀功能中，咱们会分层对数据流进行不一样的处理方式：

1. 经过CDN，把大量静态不须要检验的数据放在系统以外的地方；减小没必要要的流量到服务器端。

2. 预加载用户静态信息，在前端读系统中检验一些基本信息，如用户是否具备秒杀资格、商品状态是否正常、秒杀是否已经结束等；过滤大量无效请求。

3. 在写数据系统中再校验一些如是不是非法请求，写的数据一致性如检查库存是否充足等；

4. 最后在数据库层保证数据最终准确性，避免超卖。

处理并发锁的一个思路

昨天的文章其实已经提到了两个解决的办法，1. 应用层对数据提交排队，走队列，下降并发度。 2. 水平分库，物理上进行分流。

今天再提供一个野路子：

1. 将秒杀产品数据记录A，拆分为10条，A1, A2... A10。

2. 库存数分担到这10条记录中。

3. 订单服务有一个随机函数Rom()，生成订单记录前，根据函数结果决定从某一条记录中扣除库存。

4. 秒杀结束后，经过程序，对订单记录进行一个批量处理，对订单数据进行整合。

这个思路的出发点是以最小的代价下降单条行锁的压力，保证高压下写操做的成功率。固然，这背后是要创建一套产品和订单的归并映射逻辑。

扫描二维码或手动搜索微信公众号【架构栈】： ForestNotes

欢迎转载，带上如下二维码便可