本文已收录在Github，关注我，紧跟本系列专栏文章，咱们下篇再续！
- 🚀 魔都架构师 | 全网30W技术追随者
- 🔧 大厂分布式系统/数据中台实战专家
- 🏆 主导交易系统百万级流量调优 & 车联网平台架构
- 🧠 AIGC应用开发先行者 | 区块链落地实践者
- 🌍 以技术驱动创新，我们的征途是改变世界！
- 👉 实战干货：编程严选网
⑥ 复杂且较多外部RPC依赖
如何保证全局性的事务处理，最直接场景就是交易的下单。
- 营销优惠券服务、库存服务、下单服务分开部署。交易创建流程中：订单、券和库存的状态须保证一致性
- 调用券/库存服务超时/失败，异步发消息通知回滚
- MQ 生产端发送失败，可以重试，消息框架要采用幂等性生产者 。消费端通过ACK机制保证最终一致
- 消除2PC提交等分布式事务框架的侵入性影响
- 最后一步的DB订单置为 “可见” 要采用事务性消息，以保证一致性。
也可能存在优惠券预冻结后，交易服务器宕机，废单消息发送失败。可参考RocketMQ的回查机制，通过轮询任务，扫描出相关记录，反查订单状态，决定最终提交或回滚。
若业务逻辑复杂，内部涉及大量的接口调用，串行调用等待时间较长，如果各个节点间没有依赖关系，可以考虑并行化处理。
⑦ 尽可能使用缓存
既有本地缓存，也有分布式缓存。大促活动时，提前对缓存预热，借助缓存的高性能抗住大部分访问压力。
⑧ 购物车，混合存储
暂存用户想购买的商品，支持：
- 添加商品
- 列表查看
- 结算下单
所存信息相对有限（用户id、商品id、sku_id、数量、添加时间）。用户体验维度注意：
添加购物车时，后端校验用户未登录，常规就是引导用户跳转登录页，待登录成功后，再添加购物车。多了一步操作，给用户一种强迫的感觉，体验较差。
京东、淘宝等，即使未登录态也能添加购物车，如何实现呢？服务端这边在用户登录态校验时，做了分支路由：用户未登录时，会创建临时Token，作为用户唯一标识，购物车数据挂载在该Token，为避免购物车数据相互影响及系统复杂度，这里有个临时购物车表。
临时购物车表的数据量并不会太大，毕竟用户不会一直闲着加购物车玩，当用户登录后，查看自己的购物车，服务端会从请求的cookie里查找购物车Token标识，并查询临时购物车表是否有数据，然后合并到正式购物车表。
临时购物车一定要存储在服务端吗？有人倾向前置存储，将数据存储在浏览器或者APP LocalStorage，这部分数据不是共享，但是不太好的增加了设计复杂度：
- 客户端需借助本地数据索引，远程请求查完整信息
- 如果是登录态，还要增加数据合并逻辑
考虑到这两部分数据只是用户标识的差异性，所以还是推荐统一存到服务端，即使业务逻辑变更，也只需改一处。
