目录
- 系列总目录
- 架构演进
- 防超售
- 单元化
- 平台化
- 防超卖
- Mysql同步实现防超卖
- Redis同步实现防超卖
- 一致性
- Mysql同步实现防超卖的一致性
- Redis同步实现防超卖的一致性
- 参考文章
系列总目录
架构演进
架构演进图.png
防超售
- 最开始商品库存只需要支撑LBS电商比如外面和闪购，这类电商由于是基于位置的服务，所以品类有限，库存有限，要实现防超卖，可以用mysql同步扣减库存。这种业务场景适合业务发展初期，快速迭代。
单元化
-
随着业务的发展，需要支持更高的QPS，更好的拓展性，以及更强的容灾能力。要抗住流浪洪峰，海量扣库存，万级TPS。原生Mysql并不能支撑，这里选用redis同步扣减，监听AOF同步mysql的方案，长久来说自研采用MTSQL(美团自研的sql + 相应的降级方案解决)。整体架构如下，Cellar是KV存储，容灾的话就是多机房建设，多IDC部署。
单元化.png
平台化
- 平台化解决各个应用测接入，并且能够支持应用侧快速迭代，避免业务侧提个简单改字段需求，平台半个月才响应。小业务复用大业务流程，大业务兼容小业务流程，避免各种if else。
- 平台化应该保证回归只回归自己业务线业务，代码简洁不冗余，这才是真正的平台化。
- 平台化整体架构, 可以看到各个业务侧有自己的Redis MySQL ElasticSearch, 长远来说应该是一种类似Skywalking的微内核可插拔服务。平台提供SPI，业务侧实现，各个业务侧独立，也就不会有业务侧提个简单改字段需求，平台半个月才响应。
-
参考文章中[vivo 评论中台的流量及数据隔离实践]指出可以设置通用业务通用的es redis mysql以适应流量比较小的业务，隔离es redis mysql给流量比较大或者需求比较特殊的业务。做个折中。
平台化.png
防超卖
Mysql同步实现防超卖
-
这种方案支撑的TPS有限，性能有限，适合最初QPS不高时的架构。
Mysql同步实现防超卖.png
- 库存交易服务使用Mysql同步扣减库存，DTS(开源可以用canal)监听增量binlog, 监听到binlog后库存异步服务记录库存流水。
- 库存异步服务会校验流水如果校验失败，则会进行补偿处理，当然如果库存交易服务异常也会发补偿消息，库存异步服务进行补偿处理。
- mysql这种解决方案，会有流水校验失败的情况之一: 调用库存服务的上游socket超时导致的不一致，又没用分布式事物。
Redis同步实现防超卖
- 对于全城送，品类丰富，库存丰富，QPS高的防超卖使用redis同步扣减。
-
架构如下:
Redis同步实现防超卖.png
- 库存交易服务同步lua脚本到redis，然后扣减成功发送流水MQ，如果提交异常则发补偿MQ。
- 库存流水服务监听redis的AOF库存流水，然后批量聚合到mysql。
一致性
Mysql同步实现防超卖的一致性
-
架构
Mysql同步实现防超卖的一致性.png
- 如果binlog积压或者DTS故障导致redis，库存异步服务数据老旧，可以通过延迟处理解决，DTS可以通过双通道(如图DTS一个主通道，美团BCP备用通道)保证。
- 如果redis，库存异步服务数据丢失，那就重新加载，库存异步服务有个校验线程。
Redis同步实现防超卖的一致性
-
架构
Redis同步实现防超卖的一致性.png
- redis集群主从可能会有主从不一致的情况，比如master更新后master的AOF还没来得及同步给slave，master宕机，slave升级为master。可通过双通道流水校验，库存校正处理。当然长远来看最好的方式是重构Redis raft协议，但这成本相对比较大。
- redis某个IDC下集群完全宕机，这时触发库存不存在，双通道校验，不存在重新加载修正。
参考文章
- 参考自小程序MTDPSalon第60期之 [美团到家商品库存演进]
- vivo 评论中台的流量及数据隔离实践
