分布式一致性保证模式之【定期校对模式 】

既然我们在系统中实现最终一致性，系统在没有达到一致之前，系统间的状态是不一致的，甚至是混乱的，需要补偿操作来达到一致的目的，但是我们如何来发现需要补偿的操作呢？ 
　　在操作的主流程中的系统间执行校对操作，我们可以事后异步的批量校对操作的状态，如果发现不一致的操作，则进行补偿，补偿操作与补偿模式中的补偿操作是一致的。 
　　另外，实现定期校对的一个关键就是分布式系统中需要有一个自始至终唯一的ID，ID的生成请参考SnowFlake（https://github.com/twitter/snowflake）。 
　　 
　　在分布式系统中，全局唯一ID的示意图如下：

　　一般情况下，生成全局唯一ID有两种方法：

• 持久型：使用数据库表自增字段或者Sequence生成，为了提高效率，每个应用节点可以缓存一批次的ID，如果机器重启可能会损失一部分ID，但是这并不会产生任何问题

• 时间型：一般由机器号、业务号、时间、单节点内自增ID组成，由于时间一般精确到秒或者毫秒，因此不需要持久就能保证在分布式系统中全局唯一、粗略递增能特点

  　　实践中，为了能在分布式系统中迅速的定位问题，一般的分布式系统都有技术支持系统，它能够跟踪一个请求的调用链，调用链是在二维的维度跟踪一个调用请求，最后形成一个调用树，原理可参考谷歌的论文Dapper, a Large-Scale Distributed Systems Tracing Infrastructure（https://research.google.com/pubs/pub36356.html），一个开源的参考实现为pinpoint（https://github.com/naver/pinpoint）。 
  　　 
  　　在分布式系统中，调用链的示意图如下：

 
　　 
　　全局的唯一流水ID可以把一个请求在分布式系统中的流转的路径聚合，而调用链中的spanid可以把聚合的请求路径通过树形结构进行展示，让技术支持人员轻松的发现系统出现的问题，能够快速定位出现问题的服务节点，提高应急效率。 
　　关于订单跟踪、调用链跟踪、业务链跟踪，我们会在后续文章中详细介绍。 
　　在分布式系统中构建了唯一ID，调用链等基础设施，我们很容易对系统间的不一致进行核对，通常我们需要构建第三方的定期核对系统，以第三方的角度来监控服务执行的健康程度。 
　　 
　　定期核对系统示意图如下：

 
　　 
　　对于案例6：掉单、案例7：系统间状态不一致通常通过定期校对模式发现问题，并通过补偿模式来修复，最后完成系统间的最终一致性。 
　　定期校对模式多应用在金融系统，金融系统由于涉及到资金安全，需要保证百分之百的准确性，所以，需要多重的一致性保证机制，包括：系统间的一致性对账、现金对账、账务对账、手续费对账等等，这些都属于定期校对模式，顺便说一下，金融系统与社交应用在技术上本质的区别在于社交应用在于量大，而金融系统在于数据的准确性。 
　　到现在为止，我们看到通过查询模式、补偿模式、定期核对模式可以解决案例4到案例7的所有问题，对于案例4：同步超时，如果同步超时，我们需要查询状态进行补偿，对于案例5：异步回调超时，如果迟迟没有收到回调响应，我们也会通过查询状态进行补偿，对于案例6：掉单、案例7：系统间状态不一致，我们通过定期核对模式可以保证系统间操作的一致性，避免掉单和状态不一致导致问题。