从接口 和 消息最终一致性 两方面 探讨 幂等新问题解决思路

总结：通俗来讲，幂等就是 一次很多次 的处理产生的结果一样，这种东东叫做幂等性。

          1. 从restfull 接口上来讲 

              # GET：读取（Read） 幂等 就是单纯的取数据 不会产生什么影响
　　　　# POST：新建（Create） 不幂等 需要处理
　　　　# PUT：更新（Update） 幂等 因为就算更新 两次 产生的结果也一样
　　　　# PATCH：更新（Update），幂等 ，通常是部分更新
　　　　# DELETE：删除（Delete）幂等 多次删除同一一条记录 产生的结果也一样

           综上 通常不幂等 就是create 创建，你创建两次 就会有两条结果（通常先查 后保存）比如网路延时等原因，快速保存两次 可能回出现 两条记录，避免这种情况 通常的方式就是，前端 disable,后端 防止重复提交（前几篇博客有提到 比如 数据库唯一索引，分布                       式锁 只处理一个请求，或者 限流 限制处理次数）

           

         2.最终消息一致性分析：

           中间件优点：

           异步通讯、解耦、并发缓冲

           名词：消息发送一致性：是指产生消息的业务动作与消息发送的一致。（也就是说，如果业务操作成功，那么由这个业务操作所产生的消息一定要成功投递出去，否则就丢消息） 

1. 处理方式1
public void createProduct() {
// （业务操作）
productService.create();
// （发送消息）
sendProductCreateMsg();
}
如果业务操作成功，执行消息发送前应用故障，消息发不出去，导致消息丢失（商品系统与进销存系统的数据不一致）
如果业务操作成功，应用正常，但消息系统故障或网络故障，也会导致消息发不出去（订单系统与会计系统的数据不一致）
2. 处理方式2
public void createProduct() {
// （发送消息）
sendProductCreateMsg ();
// （业务操作）
productService.create();
}
这种情况下，更不可控，消息发出去了，但业务可能会失败（商品系统与进销存系统的数据不一致）

解决思路：

主动方应用系统加入消息存储模块。即业务操作和消息存储与发送在同一个本地事务中。先将需要发送的消息存储在本地数据库，设置其状态为代发送
将消息数据中为待发送的消息发送到MQ,MQ 推送到其他应用系统处理
其他应用系统处理结束后回调主动发系统并修改消息的状态或者删除消息
消息恢复系统：用来查询那些超时未处理状态的消息并设置延时发送

 

这种由于 会有重试 机制 业务需自己处理幂等 可参考接口思路