分布式服务协调---幂等(Idempotent)机制

背景

      在业务开发中，咱们常会面对防止重复请求的问题。当服务端对于请求的响应涉及数据的修改，或状态的变动时，可能会形成极大的危害。重复请求的后果在交易系统、售后维权，以及支付系统中尤为严重。
前台操做的抖动，快速操做，网络通讯或者后端响应慢，都会增长后端重复处理的几率。 

      重复消息是SOA服务实现中很是常见的问题，你永远不要期望调用方每次请求消息不同，对于读操做，重复消息可能无害，可对于写操做极可能就是灾难。

能够经过幂等(Idempotent)模式处理重复的消息，基本处理思路是：

• 调用者给消息一个惟一请求ID标识。ID标识一个工做单元，这个工做单元只应执行一次，工做单元ID能够是Schema的一部分，也能够是一个定制的SOAP Header，服务的Contract 能够说明这个惟一请求ID标识是必须的；
• 接收者在执行一个工做单元必须先检验该工做单元是否已经执行过。检查是否执行的逻辑一般是根据惟一请求ID ，在服务端查询请求是否有记录，是否有对应的响应信息，若是有，直接把响应信息查询后返回；若是没有，那么就当作新请求去处理。

幂等方案

      对时间全局性要求高的，可能就必须选择DB这种持久化方案比较可靠，可是性能不够好啊（而后就要考虑loadmemory，以及数据同步的问题，就一步还要考虑实时性要求了）。在空间的要求中，根据不一样的幂等范围，能够考虑分布式数据库（分布式集群全局流水号幂等）。仍是某种少许数据幂等（可能只须要单台，作好主备）。

数据的对象和范围

• 你要考虑你的幂等的全局性：空间全局性和时间全局性。
• 空间全局性：好比是交易流水幂等仍是用户ID幂等。是某种类型交易流水幂等，仍是某我的|机构|渠道的交易流水幂等
• 时间全局性：是幂等几秒，仍是几分钟，仍是永远。
• 不一样的要求，能够有不同的解决方案、难度和成本。