额外的状态字段,这个状态值一般只会单流程变更,不管通过什么消息传递,目前申万宏源的每一个业务大部分都走流程,走的过程就有唯一的业务字段配合
工作流workflow服务来进行业务流转
个人观点解决幂等只有两种方式
第一种依赖上游带过来的唯一标志，然后我们给这个唯一标志加锁保证请求只有一个请求，别的都直接反回。
第二种,上游啥都不做，下游通过请求参数摘要来控制幂等，hash有冲突，为了降低hash冲突的概率，出了hash 碰撞以后，可以在检查 方法名字，请求参数大小。来降低偶然的可能。如果按照上游唯一标志产生方式不同，都算是不同幂等性的解决方案，我觉得我可以写出1万种幂等解决方案。
在实际项目中有很多操作，不管是做多少次，都应该产生一样的效果或返回一样的结果
前端重复提交选中的数据，后台应该只产生对应这个数据的一个反应结果
我们发起一笔付款请求，应该只扣用户账户一次钱，当遇到网络重发或系统 bug 重发，也应该只扣一次钱
发送消息，也应该只发一次，同样的短信发给用户，用户会哭的
创建业务订单，一次业务请求只能创建一个，创建多个就会出大问题等等很多重要的情况都需要幂等的特性来支持
接口幂等性概念
接口幂等性：是指用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用或不同的结果。简言之，幂等性就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的
防重复和幂等，其实是有区别的
防重复主要为了避免产生重复数据，对接口返回没有太多要求
幂等除了避免产生重复数据之外，还要求每次请求都返回一样的结果
