幂等是指一次和屡次申请某一个资源应该具备同样的作用。
什么是分布式的幂等
首先，咱们来构想以下几个场景：
场景一：在 App 上确认订单的时候，点击屡次没有反馈，只能重复点击几次。在这种状况下，如果无奈保障该接口的幂等性，那么将会呈现反复下单的问题。
场景二：在接管音讯的时候，音讯推送反复。如果解决音讯的接口无奈保障幂等，那么反复生产的音讯影响可能会十分大。
通常，为了满足高可用、高性能和高可扩大的个性，分布式系统领有泛滥服务节点，然而却容易导致服务调用链简短简单，服务节点之间网络通信复杂度指数级减少，一处轻微网络故障就可能导致整个服务异样。
同时，思考到硬件设施本身故障的可能性，所以分布式系统面临一个独特的问题：一个音讯（工作）可能会被反复生产。因而，如何确保同一个音讯单次生产和多次重复生产具备雷同的成果，也就是音讯的幂等性成为一个热点问题。
其余常见的分布式解决方案
1、数据库增加惟一索引，比方订单号是惟一索引，避免生产反复订单；
2、应用分布式锁，避免应用程序呈现并发操作；
3、采纳 Token 机制，无效避免反复提交。提交后盾时带 Token 值，须要先判断 Token 是否存在，若是存在，则删除 Token，执行业务逻辑；
4、数据库通过乐观锁；(update table_name set version=version+1 where version=0)
5、数据库乐观锁，通常是通过主键或惟一索引和事务一起实现。
以上是其余常见的幂等解决方案，往往在不同的业务场景下会采纳不同的办法。因为咱们的次要业务是分布式存储，IO 从 Client 到 Server 的链路都不会很长，所以咱们参考 Token 机制，实现了一套“新”机制来解决业务场景里存在的幂等问题。
不同状态的音讯解决
如图所示，这是一个简略的工作零碎，Server 胜利执行了 ① 发送来的命令，然而并没有收到对应的后果。这是因为有网络因素的存储遇到问题，Client 都须要去重试工作，以排除网络不稳固带来的影响，然而在不同状况下，Server 收到重试音讯时，须要有不同的应答计划。这时，可能会呈现以下三种状况：
第一种状况，Server 并没有收到对应的音讯，因为有网络不稳固的状况存在，Client 是须要去重试的，这时 Server 会从新收到音讯并且进行解决，失常解决之后返回对应的后果。
第二种状况，Server 收到了对应的音讯，还正在解决，因为其余因素导致工作执行工夫过长。这是因为工作依然在执行，所以为了保障幂等，咱们须要等之前的工作执行实现后，再获取其执行的后果返回给客户端。
第三种状况，Server 收到了对应的音讯，并且曾经解决实现，然而网络因素导致 Client 没有收到 ② 的后果，Server 收到重试的申请之后，间接获取曾经收到后果返回给 Client。
为了做到下面的性能，咱们须要有一套正当的机制来保留曾经收到的音讯状态，并且须要在可能判断音讯曾经被 Client 收到后果时清理这个状态，这里咱们引入了 SeqNumber 来做到这些事件。
SeqNumber 的机制
咱们每次的申请都会带着一个之前曾经实现的申请序号 ACK 和以后序号 Seq，Server 在解决时会依据 Seq 来判断以后音讯的状态，保障一个 Seq 不会被执行屡次。同时，会开释 ACK 对应的序号，因为只有在这个时候能力保障 Client 曾经正确的实现了对应的申请。
咱们在 Client 端有两个队列 finished 和 running，别离存有正在执行的和曾经实现的工作 ID。在 Server 端有一个 map，保留了所有未清理的音讯（包含正在执行，执行实现）。咱们一个申请有以下几个步骤：
1、生成一个未应用的 Seq，如图在 request 里生成了 12；
2、将这个 Seq 插入 running 队列；
3、从曾经实现的 finished 队列获取最小的 Seq 作为 ACK，如图 ACK=1，到这里 Client 将筹备好的音讯发送给 Server；
4、Server 收到申请，首先会将 ACK 对应的申请的缓存开释掉，而后获取对应 Seq 的音讯，如果没有就阐明是新的音讯，直接插入，否则依据 map 之中的状态做对应的解决（对应到上文中三种状态的解决形式）；
5、实现工作之后，返回后果给 Client，到这里 Server 曾经实现了工作解决；
6、Client 收到了音讯的后果，能够确认 Server 曾经实现工作，这时候开释 finished 队列中 ACK=1 的项，而后将刚刚实现是 Seq=12 的工作挪动到 finished 之中。
总结
分布式系统是一个十分宏大且简单的零碎，幂等只是其中十分重要且简单的问题，在分布式系统的构建中，不同的零碎对于幂等有着不同的需要，心愿这篇文章可能对大家有所帮忙。