标签：字段 rod 需求 返回 很多 ima 多少 解耦 消息中间件
1、业务需求的描述
假设面试官现在给出来对于这个电商平台的积分兑换系统的相关需求如下：
用户在电商平台里平时通过购买商品、晒单评论可以有不断的积累积分积累到足够的积分后，就可以在电商平台的积分兑换页面中，选择使用自己的积分来兑换一些礼品。
需求其实就这么简单，那么面试官说了，针对这个业务场景给出你对这个机制实现的思考过程以及这里要注意的一些地方。
2、对业务流程的思考
如何思考？首先，用户不停的购买商品以及晒单评论，会不断的获取积分，那么是不是需要一张积分表，专门用来存储每个用户的积分呢？没错，这个表是一定需要的，可以现场给出下述的表结构。
积分表：
id（自增id主键）
user_id（用户id）
credit（积分）
继续来看，假设在积分兑换页面，用户选择用自己的20000积分兑换一瓶洗发水，后台的逻辑应该如何设计呢？
这个也是必须得现场给出一个思考过程的，这个其实看起来简单，但是很多年纪较轻，经验不足的朋友，可能没法快速思考出来。
首先你要用20000积分去进行兑换，那么一定是必须要在积分表里扣减掉这20000积分的吧？所以在流程设计中，首先就得有一个20000积分扣减的过程。
其次，你用这20000积分兑换了什么东西呢？
所以你是不是还需要一张单独的表，叫做积分兑换记录表，记录下来你这个用户本次用多少积分兑换了一件什么商品？
这个积分兑换记录表的结构如下所示，你是不是需要在下面的那个表里插入一条记录，说这个用户本次用多少积分兑换了哪个商品？
积分兑换表：
id（自增id主键）
user_id（用户id）
exchanged_credit（用于兑换的积分）
product_id（兑换的商品id）
最后，光是插入上述那条积分兑换记录是不够的，你必须得调用仓储业务模块的接口，通知仓储业务模块新增一条发货申请，而且应该是积分兑换对应的发货申请，这样保证仓库可以准备对应的商品进行发货。
这个发货申请大致对应如下的表结构：
发货申请表：
id（自增id主键）
type（发货类型，1：购买，2：积分兑换）
credit_exchange_id（积分兑换表的id）
product_id（要发货的商品id）
其实这里的发货申请表简化了很多，按理说还得有发货商品的数量等等字段，但是这里可以简化处理也没事，毕竟是面试现场。
简单画出来这个流程大致如下所示。
3、物流配送进度查询，考虑到了吗？
如果把上面那整个业务流程给面试官说了，就完事了吗？
当然不是！
你可以站在用户的角度考虑一下，你是不是肯定还需要查看积分兑换的记录？这个在积分兑换表里可以查看到你用多少积分兑换了什么商品。
但是你兑换商品的物流配送进度，能查看到吗？不能。所以你应该在业务流程里再考虑进去对应的物流配送的逻辑。
通常来说一个基本的逻辑，就是在生产发货申请单的时候，需要调用第三方物流公司的接口申请一个物流单，这样仓库管理员打包准备好商品，坐等物流公司商品收快递就可以了。
物流公司会根据物流单去进行配送，这个配送地址当然是用户自己在电商平台选择的自己的某个地址。
此时发货申请单的表结构是不是如下所示？
发货申请表：
id（自增id主键）
type（发货类型，1：购买，2：积分兑换）
credit_exchange_id（积分兑换表的id）
product_id（要发货的商品id）
express_no（物流单号）
所以在生产发货申请单时，先得调用第三方物流公司的接口申请一个物流单，这样发货申请单中是有一个物流单号的，而且每个积分兑换记录都通过id跟发货申请单关联起来。
这样在页面上对每个兑换记录，是不是可以找到发货申请单中的物流单号，然后根据物流单号调用第三方物流公司的接口，去获取配送的进度？
这就是一个非常典型的业务系统的技术实现的逻辑思考，一个经验丰富合格的工程师，往往都具备了一定的业务思维，可以很好的根据业务系统中的用户逻辑来考虑，反推自己的系统技术实现逻辑。
上述整个过程，如下图所示：
4、事务的保证
业务流程整个捋顺之后，接下来就涉及到技术的考虑了。你得考虑一下，这种业务系统里怎么能没有事务呢？
扣减积分、新增积分兑换记录、新增发货申请单，这三个步骤必须是要么一起完成，要么一起失败的。也就是说，这三个步骤必须是在一个事务里的。
现在有一个问题，对一个电商平台自身的业务系统来说，仅仅包含积分服务。但是仓储服务一般是独立部署的一套系统，或者是一个独立的服务。
也就是说，扣减积分和新增积分兑换记录可以在一个服务里是一个事务，但是新增发货申请单，他是在另外一个服务里的，这个事务如何保证呢？
有朋友可能马上回答：用分布式事务啊！先别急，咱们可以先用最简单的模式来实现一下。
比如积分服务在一个事务代码块中，先执行扣减积分、新增积分兑换记录两个步骤。
然后记住，在事务代码块中，最后一步调用仓储服务的接口，如果接口调用成功，那么就可以提交事务了。如果接口调用失败，那么就抛异常让事务回滚，这样可以不可以？
这个流程如下所示：
积分服务 事务 {
-> 扣减积分
-> 新增积分兑换记录
-> 调用仓储服务
}
5、消息中间件的引入
上述设计其实理论上是没问题的，但是这里你忽略了一个问题，在这个业务场景中，积分服务是没有必要同步调用仓储服务的。
因为积分兑换是一个用户执行的操作，假设你的仓储服务在生成发货申请单的时候调用第三方物流公司的接口，被卡住了，或者失败了，怎么办？
此时可能导致用户在页面上看到积分兑换按钮点击之后，卡在那儿可能几十秒都无法执行成功，所以这个系统如此设计是错误的。
那应该怎么做呢？你必须得在这里引入消息中间件进行异步化的解耦，保证用户点击积分兑换按钮之后，尽快返回。如下图所示：
6、重试机制的引入
到这里就OK了吗？还没呢！
一旦引入消息中间件之后，好处是用户点击积分兑换按钮，直接就是在积分服务里扣减积分以及新增积分兑换记录，然后发送一条消息到消息中间件里就结束了，速度很快，保证了用户体验。
但是坏处就是，万一仓储服务执行新增发货申请失败了怎么办？
这个时候就需要引入可靠消息服务了，他需要去保证仓储服务一定会完成新增发货申请这个事。
具体的流程如下：
积分服务发送消息给可靠消息服务，可靠消息服务在消息表中新增记录，然后发送消息到MQ（消息中间件）
然后仓储服务消费消息新增发货申请单，如果成功就回调可靠消息服务的一个接口说自己成功了，可靠消息服务就可以更新本地消息表中的记录状态为成功
如果仓储服务长时间没通知可靠消息服务自己成功了，可靠消息服务不停的重试再次发送消息
通过这样的设计，就可以保证可靠消息服务一定会无限次重试保证让仓储服务成功执行。再加上重试机制后，整个流程图如下所示：
7、引入幂等性机制
最后一个问题，如果仓储服务卡在第三方物流系统申请物流单的环节，长时间阻塞，所以没回调通知可靠消息服务。
但是可靠消息服务过了一段时间，感觉没收到回调通知，就自己重试发送了消息，这样岂不是会让仓储服务新增两条发货申请单？
因此我们还要保证仓储服务新增发货申请单的幂等性，其实也非常简单，回顾一下发货申请单表的结构：
发货申请表：
id（自增id主键）
type（发货类型，1：购买，2：积分兑换）
credit_exchange_id（积分兑换表的id）
product_id（要发货的商品id）
express_no（物流单号）
只要在“credit_exchange_id”字段上建立一个唯一索引就可以了，保证每个积分兑换记录只能创建一条发货申请单，如果重复创建就会被唯一索引被阻止，这样就可以保证这个行为的幂等性了。
至此，对这道系统设计题目的回答，全部结束。
标签：字段 rod 需求 返回 很多 ima 多少 解耦 消息中间件
原文地址：https://www.cnblogs.com/lingboweifu/p/11897357.html
