业务场景实战(一)美团到家商品库存演进

目录

• 系列总目录
• 架构演进
  • 防超售
  • 单元化
  • 平台化
• 防超卖
  • 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

1. 库存交易服务使用Mysql同步扣减库存，DTS(开源可以用canal)监听增量binlog, 监听到binlog后库存异步服务记录库存流水。
2. 库存异步服务会校验流水如果校验失败，则会进行补偿处理，当然如果库存交易服务异常也会发补偿消息，库存异步服务进行补偿处理。
3. mysql这种解决方案，会有流水校验失败的情况之一: 调用库存服务的上游socket超时导致的不一致，又没用分布式事物。

Redis同步实现防超卖

• 对于全城送，品类丰富，库存丰富，QPS高的防超卖使用redis同步扣减。

• 架构如下:

  
  
  Redis同步实现防超卖.png

1. 库存交易服务同步lua脚本到redis，然后扣减成功发送流水MQ，如果提交异常则发补偿MQ。
2. 库存流水服务监听redis的AOF库存流水，然后批量聚合到mysql。

---

一致性

Mysql同步实现防超卖的一致性

• 架构

  
  
  Mysql同步实现防超卖的一致性.png

1. 如果binlog积压或者DTS故障导致redis，库存异步服务数据老旧，可以通过延迟处理解决，DTS可以通过双通道(如图DTS一个主通道，美团BCP备用通道)保证。
2. 如果redis，库存异步服务数据丢失，那就重新加载，库存异步服务有个校验线程。

Redis同步实现防超卖的一致性

• 架构

  
  
  Redis同步实现防超卖的一致性.png

1. redis集群主从可能会有主从不一致的情况，比如master更新后master的AOF还没来得及同步给slave，master宕机，slave升级为master。可通过双通道流水校验，库存校正处理。当然长远来看最好的方式是重构Redis raft协议，但这成本相对比较大。
2. redis某个IDC下集群完全宕机，这时触发库存不存在，双通道校验，不存在重新加载修正。

---

参考文章

• 参考自小程序MTDPSalon第60期之 [美团到家商品库存演进]
• vivo 评论中台的流量及数据隔离实践