本文说说分布式事务的经典场景：秒杀的实现。
可以说秒杀是任何一个电商系统都无法避免的一个场景了，而在互联网公司面试过程中，也经常喜欢以这个场景来提问如何实现，考察面试者的水平。下面本文试从小库存商品秒杀和大库存商品秒杀两个角度来谈谈如何实现。
本文依然总结自钟华老师的《企业IT架构转型之道 阿里巴巴中台战略思想与架构实战》一书，购书连接：
小库存商品秒杀
先看图：
关于小库存商品秒杀系统的实现有如下几点总结：
1.秒杀单独布一台应用实例，隔离部署，不要影响普通业务；
2.商品的详情和库存信息都缓存在tair服务器；
3.商品的基本信息本地缓存，不要每次都从服务器取，可考虑使用浏览器缓存；
4.商品定时上架，页面设置定时器，到时开放下单按钮，注意后台也要判断下单时间；
5.使用乐观锁机制实现(where条件中加字段判断前后库存值)；
上图是秒杀的流程。重点在于两处：页面上的库存信息是从缓存中加载出来的，并不一定是真实的库存信息。只有当进入提交订单阶段，才会去判断数据库中的真实库存，当此时获取的库存大于0时，则进行库存的扣减操作(步骤3-2)，在通过步骤3-3更新了商品数据库中的库存信息后，同时也会更新缓存中该商品的库存信息(步骤3.4)，则前方用户再访问该商品信息时，看到的就是已经更新后的库存信息。
大库存商品秒杀
流程图如下：
在秒杀活动开始前，直接将该商品的初始库存信息通过商品中心(图中的IC)加载到缓存服务器Tair上(步骤0.1)。
跟小库存商品秒杀场景相同，当用户访问商品详情页时，是从Tair缓存服务器上获取商品的库存信息(步骤1.1)，在库存大于0的情况下，用户进入到下单界面(Buy), 并点击"确认购买"按钮进行下单操作时(步骤3 )， 后端处理的逻辑就跟小库存商品秒杀有了较大的区别。
在用户进行了下单操作后，程序首先会为该订单创建一个订单详单记录，只不过在库存成功扣减前，该订单的状态是用户不可见的。保存该订单的信息非常重要的作用是当缓存服务出现故障不可用时，可通过商品数据库中初始缓存的信息和数据库中订单详单信息能还原出订单处理的最新状态，而不至于出现因为缓存的故障造成业务数据的丢失。
在数据库中成功创建订单详单后，会发送一个库存修改的请求到消息服务器。因为一般的缓存平台还不支持MVCC(多版本并发控制，读不加锁且读写不冲突)或数据锁的功能，此时利用消息服务可让库存修改的请求线性处理，这里可利用上文提到的事务消息的方式，保证在订单详单创建成功后，发送消息到消息服务器，当消息的订阅程序从消息服务器获取到消息后，则对缓存中的库存数据进行更新处理。因为缓存数据更新时间在纳秒级，所以整体的库存处理性能相比传统数据库方式差别至少在百倍。当缓存中的库存数据成功更新后，则将之前创建的订单详情状态修改为成功下单状态，整个订单创建过程结束。
1633
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
