架构杂谈《五》

架构杂谈《五》

保证最终一致性的模式

　　在大规模、高并发服务化系统中，一个功能被拆分成多个具有功能单一的子功能，一个流程会有多个系统的多个单一功能的服务组合实现，如果使用两阶段提交协议和三阶段提交协议，确实能解决系统间的一致性问题。其实现也比较复杂、成本比较高，最重要的是性能不够好，相比来看，tcc协议简单、更容易实现，但tcc协议由于每个事务都需要执行try再执行confirm 显得有点臃肿，实现最终一致性有一些非常有效、简单的模式。

一、查询模式

　　任何服务操作都需要提供一个查询接口，用来向外部输出操作执行的状态。服务操作的使用方可通过查询接口得知服务执行的状态，然后根据不同的状态来做不同的处理操作。

　　为了实现查询，每个服务操作都需要有唯一的标识符。

　　首先，单笔查询操作的必须提供的（也鼓励使用单笔订单查询），因为每次调用需要占用的负载是可控的。批量查询则根据需要来提高（如果使用了批量查询，需要有合理的分页机制，并且必须限制分页的大小，以及对批量查询的吞吐量有熔断、隔离和限流等措施）。

（查询模式图）

二、补偿模式

　　有了查询模式，可以在任何情况下都可得知具体操作所处的状态，如果整个操作都处于不正常状态，则需要我们修正操作中有问题的子操作，这可能需要重新执行未完成的子操作，或者取消已经完成的子操作，通过修复使整个分布式系统达到一致。为了让系统最终达到一致状态而做的努力都叫做补偿。

　　对于服务化系统中同步调用的操作，若业务操作发起方没有收到业务操作执行方的明确返回或者调用超时，这时业务发起方需要及时地调用业务执行方来获得操作执行的状态（这就是查询模式）。在获得业务操作执行方的状态后，如果业务执行方已完成预设工作，则业务发起方向业务的使用方返回成功；如果业务操作执行方的状态为失败或者未知，则会立即告诉业务使用方失败（也叫做快速失败策略），然后调用业务操作的逆向操作，保证操作不被执行或者回滚已经执行的操作，让业务使用方、业务操作发起方和业务操作执行方最终达到一致状态。

（补偿模式图）

　　补偿操作模式发起形式分为以下几种：

　　（1）自动恢复：程序根据发生不一致的环境，通过继续执行未完成的操作或者回滚已经完成的操作达到一致性状态。

　　（2）通知运营：如果程序无法自动恢复，并且设计师考虑到了不一致的场景，则可以提供运营功能，通过运营手工进行补偿。

　　（3）技术运营：如果程序无法自动恢复、又没有运营功能，那么必须通过技术手段来解决，技术手段包括进行数据库变更或者代码变更，这是最糟的一种场景也是我们在生产 中尽量避免的场景 。 

三、异步确保模式

　　异步确保模式是补偿模式的一个典型案例，经常应用到使用方对响应时间要求不太高的场景中，通常把这类操作从主流程中摘除，通过异步的方式进行处理，处理后把结果通过通知系统通知给使用方。这种方案的最大好处是能够对高并发流量进行消峰，例如：电商系统中的物流、配迭，以及支付系统中的计费、入账等。
　　在实践中将要执行的异步操作封装后持久入库，然后通过定时捞取未完成的任务进行补偿操作来实现异步确保模式，只要定时系统足够健壮，则任何任务最终都会成功执行 。

（异步确保模式图）

四、定期校对模式

　　系统在没有达到一致之前，系统间的状态是不一致的，甚至是混乱的，需要通过补偿操作来达到最终一致性的目的，但是如何来发现需要补偿的操作呢？

　　在操作主流程中的系统间执行校对操作，可以在事后异步地批量校对操作的状态，如果发现不一致的操作则进行补偿，另外，实现定期校对的一个关键就是分布式系统中需要有一个自始至终唯一的id。

　　在实践中想在分布式系统中迅速定位问题时，可通过分布式系统的调用链跟踪系统进行，它能够跟踪一个请求的调用链。调用链是从二维的维度跟踪一个调用请求 ， 最后形成一个调用树。

　　全局的唯一id 可以将一个请求在分布式系统中的流转路径聚合，而调用链中的spanid 可以将聚合的请求路径通过树形结构进行展示，让技术支持工作人员轻松地发现系 统出现的问题 ， 能够快速定位出现问题的服务节点，提高应急效率。

　　在分布式系统中构建了唯一 id、调用链等基础设施后，我们很容易对系统间的不一致进行核对 。 通常我们需要构建第三方的定期核对系统，从第三方的角度来监控服务执行的健康程度 。

（定期核对模式图）

 

五、可靠消息模式

　　在分布式系统中，对于主流程中优先级 比较低的操作，大多采用异步的方式执行，也就是前面提到的异步确保模型，为了让异步操作的调用方和被调用方充分解耦，也由于专业的消息队列本身具有可伸缩、可分片、可持久等功能，我们通常通过消息队列实现异步化。对于消息队列，我们需要建立特殊的设施来保证可靠的消息发送及处理机的幕等性。

　　（1）消息的可靠发送

　　　　　　消息的可靠发送可以认为是尽最大努力发送消息通知，有以下两种实现方法。

　　　　　　a）在发送消息之前将消息持久到数据库，状态标记为待发送 ， 然后发送消息，如果发送成功，则将消息改为发送成功。定时任务定时从数据库捞取在一定时间内未发送的消息并将消息发送。

 

（可靠消息发送模式1 ）

　　　　　　　b）该实现方式与第 1 种类似，不同的是持久消息的数据库是独立 的， 并不藕合在业务系统中。发送消息前，先发送一个预消息给某个第三方的消息管理器，消息管理器将其持久到数据库，并标记状态为待发送，在发送成功后，标记消息为发送成功。定时任务定时从数据库中捞取一定时间内未发送的消息，查询业务系统是否要继续发送，根据查询结果来确定消息的状态。

 

 

 

(可靠消息发送模式 2 )

　　

（2）消息处理器的幂等性　　

　　如果我们要保证可靠地发送消息，简单来说就是要保证消息一定发送出去，那么需要有重试机制。有了重试机制后，消息就一定会重复，那么我们需要对重复的问题进行处理。处理重复问题的最佳方式是保证操作的幕等性，幕等性的数学公式为：
　　　　　　　　f (j(x)) =f (x)
　　保证操作的幕等性的常用方法如下。
　　　　1、使用数据库表的唯一键进行滤重，拒绝重复的请求。
　　　　2、使用分布式表对请求进行滤重。
　　　　3、使用状态流转的方向性来滤重，通常使用数据库的行级锁来实现。
　　　　4、根据业务的特点，操作本身就是幕等的 ， 例如 ： 删除一个资源、增加一个资源、获得一个资源等。

六、缓存一致性模式

　　在大规模、高并发系统中的一个常见的核心需求就是亿级的读需求，显然，关系型数据库并不是解决高并发读需求的最佳方案，互联网的经典做法就是使用缓存来抗住读流量。下面是使用缓存来保证一致性的最佳实践。

　　1、如果性能要求不是非常高，则尽量使用分布式缓存，而不要使用本地缓存。

　　2、写缓存时数据一定要完整

　　3、使用缓存牺牲了一致性，为了提高性能，数据库与缓存只需要保持弱一致性，而不需要保持强一致性，否则违背了使用缓存的初衷。

　　4、读的顺序是先读缓存，后读数据库，写的顺序要先写数据库，后写缓存。 

说明：

　　1、参考书籍：《分布式服务架构：原理、设计与实战》

　　2、如有不合适的地方请反馈。综合后更改。