业务需求描述
1.用户在电商平台里通过购买商品、晒单评论可以有不断的积累积分；
2.积累到足够的积分后，可以在电商平台的积分兑换页面中，选择使用自己的积分来兑换礼品。
对业务流程的思考
首先需要一张积分表，专门存储每个用户的积分。
积分表(
id int(主键)
user_id (用户id)
credit(积分)
)
继续来看，假设在积分兑换页面，用户选择用自己的2000积分兑换一瓶洗发水，后台的逻辑应该如何设计呢？
- 首先，要在积分表里扣减掉这20000积分，所以在流程设计中，首先就得有一个2000积分扣减的过程。
- 其次，得有一个积分兑换记录表，记录下来这个用户本次用多少积分兑换了一件什么商品？
积分兑换记录表(
id int(主键)
user_id (用户id)
exchanged_credit（用于兑换的积分）
product_id（兑换的商品id）
)
- 最后，必须得调用仓储业务模块的接口，通知仓储业务模块新增一条发货申请，而且应该是积分兑换对应的发货申请，这样保证仓库可以准备对对应的商品进行发货。
发货申请表(
id int(主键)
type（发货类型，1：购买，2：积分兑换）
credit_exchange_id（积分兑换表的id）
product_id（要发货的商品id）//部分发货 全部发货
)
第三方物流配送进度的查询
站在用户的角度考虑一下，你可以在积分兑换表里可以查看到用多少积分兑换了什么商品。但是你兑换商品的物流配送进度，还不能查看得到。所以应该在业务流程里考虑加上对应的物流配送的逻辑。
- 基本的逻辑，就是在生产发货申请单的时候，需要调用第三方物流公司的接口申请一个物流单，这样仓库管理员打包准备好商品，坐等物流公司商品收快递就可以了。
- 物流公司会根据物流单去进行配送，这个配送地址当然是用户自己在电商平台选择的自己的某个地址。
发货申请表NEW(
id int(主键)
type（发货类型，1：购买，2：积分兑换）
credit_exchange_id（积分兑换表的id）
product_id（要发货的商品id）//部分发货 全部发货
express_no（物流单号）
)
- 所以在生产发货申请单时，先得调用第三方物流公司的接口申请一个物流单，这样发货申请单中是有一个物流单号的，而且每个积分兑换记录都通过id跟发货申请单关联起来。
- 这样在页面上对每个兑换记录，就可以找到发货申请单中的物流单号，然后根据物流单号调用第三方物流公司的接口，去获取配送的进度。
事务的保证
以上业务流程基本捋顺之后，接下来就得考虑涉及到的技术。这种业务系统里一定得有事务的支持。
- 扣减积分、新增积分兑换记录、新增发货申请单，这三个步骤必须是要么一起完成，要么一起失败的。也就是说，这三个步骤必须是在一个事务里的。
- 扣减积分和新增积分兑换记录可以在一个服务里是一个事务，但是新增发货申请单，他是在另外一个服务里的，这个事务如何保证呢？(分布式事务？)
- 可以在积分事务代码块中，调用仓储服务的接口，如果接口调用成功，那么就可以提交事务了。如果接口调用失败，那么就抛异常让事务回滚(貌似也可以吧？)
消息中间件的引入
- 这个业务场景中，积分服务是没有必要同步调用仓储服务的。
- 积分兑换是一个用户执行的操作，假设你的仓储服务在生成发货申请单的时候调用第三方物流公司的接口，被卡住了，或者失败了，会给用户非常不好的体验。
- 必须得在这里引入消息中间件进行异步化的解耦，保证用户点击积分兑换按钮之后，尽快返回。
重试机制的引入
- 引入消息中间件之后，好处是用户点击积分兑换按钮，直接就是在积分服务里扣减积分以及新增积分兑换记录，然后发送一条消息到消息中间件里就结束了，速度很快，保证了用户体验。
- 坏处就是，如果仓储服务执行新增发货申请失败后果不堪设想。
- 引入可靠消息服务，可以去保证仓储服务一定会完成新增发货申请这个事。
- 可靠消息服务也就是最终一致性分布式事务原理，大致流程如下：
- 积分服务发送消息给可靠消息服务，可靠消息服务在消息表中新增记录，然后发送消息到MQ（消息中间件）。
- 然后仓储服务消费消息新增发货申请单，如果成功就回调可靠消息服务的一个接口说自己成功了，可靠消息服务就可以更新本地消息表中的记录状态为成功。
- 如果仓储服务长时间没通知可靠消息服务自己成功了，可靠消息服务不停的重试再次发送消息。
- 通过这样的设计，就可以保证可靠消息服务一定会无限次重试保证让仓储服务成功执行。
引入幂等性机制
- 如果仓储服务卡在第三方物流系统申请物流单的环节，长时间阻塞，所以没回调通知可靠消息服务。
- 但是可靠消息服务过了一段时间(时间差)，感觉没收到回调通知，就自己重试发送了消息，这样就会让仓储服务新增两条发货申请单！！！
- 因此还要保证仓储服务新增发货申请单的幂等性。
- 只要在“credit_exchange_id”字段上建立一个唯一索引就可以完美解决，保证每个积分兑换记录只能创建一条发货申请单，如果重复创建就会被唯一索引被阻止，这样就可以保证这个行为的幂等性了。(全部申请发货)
整体架构
积分兑换系统.png
·
