首先幂等的范围不单只接口，消息消费也是需要业务幂等的，比如订单例子，订单服务收到退款消息消费时。其次接口幂等，service层的职责根据作者划分为业务编排，按此划分，业务校验也可能会放在这层，比如银行转账例子，校验B账户是否被冻结，A账户资金是否足够等校验，当校验不通过，都不需要走下层逻辑，直接返回或报错，这个也是业务幂等的体现。最后幂等难点其实不是在哪里做，而是怎样做，包括复用性、复杂性平衡等。
为了防止上述情况的发生，我们需要提供一个防护措施，对于同一笔支付信息如果我其中某一次处理成功了，我虽然又接收到了消息，但是这时我不处理了，即保证接口的 幂等性。
维基百科上的定义：
幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。
- *在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。**幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。例如，“setTrue()”函数就是一个幂等函数,无论多次执行，其结果都是一样的，更复杂的操作幂等保证是利用唯一交易号(流水号)实现.
任意多次执行所产生的影响均与一次执行的影响相同，这是幂等性的核心特点。其实在我们编程中主要操作就是CURD，其中读取（Retrieve）操作和删除（Delete）操作是天然幂等的，受影响的就是创建（Create）、更新（Update）。
对于业务中需要考虑幂等性的地方一般都是接口的重复请求，重复请求是指同一个请求因为某些原因被多次提交。导致这个情况会有几种场景：
对于一些业务场景影响比较大的，接口的幂等性是个必须要考虑的问题，例如金钱的交易方面的接口。否则一个错误的、考虑不周的接口可能会给公司带来巨额的金钱损失，那么背锅的肯定是程序员自己了。
对于和web端交互的接口，我们可以在前端拦截一部分，例如防止表单重复提交，按钮置灰、隐藏、不可点击等方式。
但是前端做控制实际效益不是很高，懂点技术的都会模拟请求调用你的服务，所以安全的策略还是需要从后端的接口层来做。
那么后端要实现分布式接口的幂等性有哪些策略方式呢？主要可以从以下几个方面来考虑实现：
针对前端重复连续多次点击的情况，例如用户购物提交订单，提交订单的接口就可以通过 Token 的机制实现防止重复提交。
主要流程就是：