积分兑换网站制作 第1篇
到这里就OK了吗？还没呢！
但是坏处就是，万一仓储服务执行新增发货申请失败了怎么办？
这个时候就需要引入可靠消息服务了，他需要去保证仓储服务一定会完成新增发货申请这个事。
具体的流程如下：
1、积分服务发送消息给可靠消息服务，可靠消息服务在消息表中新增记录，然后发送消息到MQ（消息中间件）
2、然后仓储服务消费消息新增发货申请单，如果成功就回调可靠消息服务的一个接口说自己成功了，可靠消息服务就可以更新本地消息表中的记录状态为成功
3、如果仓储服务长时间没通知可靠消息服务自己成功了，可靠消息服务不停的重试再次发送消息
通过这样的设计，就可以保证可靠消息服务一定会无限次重试保证让仓储服务成功执行。再加上重试机制后，整个流程图如下所示：
积分兑换网站制作 第2篇
通过这篇文章的分析，可以看到对这类开放式面试题的一个回答思路，首先得从业务上来考虑这个系统应该有哪些业务组成部分，如何实现业务流程？
其次就是你得考虑面临对应的业务场景的时候，这个系统会有哪些技术挑战，各个环节可能会有哪些技术问题？
然后应该针对这些技术挑战和技术问题，现场给出一些你的思路。只要给出大致的思路就可以，比如应该往哪个方向去解决，应该引入哪些机制。
说实话，大部分人是没实际做过这类系统的。比如让你设计一个秒杀系统，如何设计？
试问，国内有多少人真的做过秒杀系统？其实面试官只不过是通过这个问题考察你的技术面、技术功底，对各种常规技术方案的积累，以及现场分析业务，分析技术问题，进而基于你过去的技术积累，给出合理解决方案的一个能力。
这种能力，是一个高级Java工程师必须具备的能力，因为如果你是一个有5年以上经验的高级工程师，那你必须在团队里能独立负责一个系统。
此时你必须有这个能力，对项目面临的问题，要能够分析业务，分析技术问题，然后给出合理的技术方案和架构设计。
积分兑换网站制作 第3篇
最后一个问题，如果仓储服务卡在第三方物流系统申请物流单的环节，长时间阻塞，所以没回调通知可靠消息服务。
但是可靠消息服务过了一段时间，感觉没收到回调通知，就自己重试发送了消息，这样岂不是会让仓储服务新增两条发货申请单？
因此我们还要保证仓储服务新增发货申请单的幂等性，其实也非常简单，回顾一下发货申请单表的结构：
发货申请表：
id（自增id主键） type（发货类型，1：购买，2：积分兑换） credit_exchange_id（积分兑换表的id） product_id（要发货的商品id） express_no（物流单号）
只要在“credit_exchange_id”字段上建立一个唯一索引就可以了，保证每个积分兑换记录只能创建一条发货申请单，如果重复创建就会被唯一索引被阻止，这样就可以保证这个行为的幂等性了。
至此，对这道系统设计题目的回答，全部结束。
积分兑换网站制作 第4篇
业务流程整个捋顺之后，接下来就涉及到技术的考虑了。你得考虑一下，这种业务系统里怎么能没有事务呢？
扣减积分、新增积分兑换记录、新增发货申请单，这三个步骤必须是要么一起完成，要么一起失败的。也就是说，这三个步骤必须是在一个事务里的。
现在有一个问题，对一个电商平台自身的业务系统来说，仅仅包含积分服务。但是仓储服务一般是独立部署的一套系统，或者是一个独立的服务。
也就是说，扣减积分和新增积分兑换记录可以在一个服务里是一个事务，但是新增发货申请单，他是在另外一个服务里的，这个事务如何保证呢？
有朋友可能马上回答：用分布式事务啊！先别急，咱们可以先用最简单的模式来实现一下。
比如积分服务在一个事务代码块中，先执行扣减积分、新增积分兑换记录两个步骤。
然后记住，在事务代码块中，最后一步调用仓储服务的接口，如果接口调用成功，那么就可以提交事务了。如果接口调用失败，那么就抛异常让事务回滚，这样可以不可以？
这个流程如下所示：