保证最终一致性的模式

保证最终一致性的模式

查询模式 任何服务操作都需要提供一个查询接口，用来向外部输出操作执行 的状态。服务操作的使用方可以通过查询接口得知服务操作执行的状 态，然后根据不同的状态来做不同的处理操作。 为了能够实现查询，每个服务操作都需要有唯一的流水号标识，也 可使用此次服务操作对应的资源ID来标识，例如：请求流水号、订单号 等。 首先，单笔查询操作是必须提供的，也鼓励使用单笔订单查询，这 是因为每次调用需要占用的负载是可控的。批量查询则根据需要来提 供，如果使用了批量查询，则需要有合理的分页机制，并且必须限制分 页的大小，以及对批量查询的吞吐量有容量评估、熔断、隔离和限流等 措施。

补偿模式 有了上面的查询模式，在任何情况下，我们都能得知具体的操作所 处的状态，如果整个操作都处于不正常的状态，则我们需要修正操作中有问题的子操作，这可能需要重新执行未完成的子操作，后者取消已经 完成的子操作，通过修复使整个分布式系统达到一致。为了让系统最终 达到一致状态而做的努力都叫作补偿。 对于服务化系统中同步调用的操作，若业务操作发起方还没有收到 业务操作执行方的明确返回或者调用超时，则可参考案例 2，这时业务 发起方需要及时地调用业务执行方来获得操作执行的状态，这里使用在 前面学习的查询模式。在获得业务操作执行方的状态后，如果业务执行 方已经完成预设工作，则业务发起方向业务的使用方返回成功；如果业 务操作执行方的状态为失败或者未知，则会立即告诉业务使用方失败， 也叫作快速失败策略，然后调用业务操作的逆向操作，保证操作不被执 行或者回滚已经执行的操作，让业务使用方、业务操作发起方和业务操 作执行方最终达到一致状态。

补偿操作根据发起形式分为以下几种。  自动恢复：程序根据发生不一致的环境，通过继续进行未完成的 操作，或者回滚已经完成的操作，来自动达到一致状态。  通知运营：如果程序无法自动恢复，并且设计时考虑到了不一致 的场景，则可以提供运营功能，通过运营手工进行补偿。  技术运营：如果很不巧，系统无法自动回复，又没有运营功能， 那么必须通过技术手段来解决，技术手段包括进行数据库变更或者代码 变更，这是最糟的一种场景，也是我们在生产中尽量避免的场景。

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

定期校对模式 系统在没有达到一致之前，系统间的状态是不一致的，甚至是混乱 的，需要通过补偿操作来达到最终一致性的目的，但是如何来发现需要 补偿的操作呢？ 在操作主流程中的系统间执行校对操作，可以在事后异步地批量校 对操作的状态，如果发现不一致的操作，则进行补偿，补偿操作与补偿 模式中的补偿操作是一致的。 另外，实现定期校对的一个关键就是分布式系统中需要有一个自始至终唯一的ID，生成全局唯一ID有以下两种方法。 · 持久型：使用数据库表自增字段或者Sequence生成，为了提高效 率，每个应用节点可以缓存一个批次的ID，如果机器重启则可能会损失 一部分ID，但是这并不会产生任何问题。 · 时间型：一般由机器号、业务号、时间、单节点内自增ID组成， 由于时间一般精确到秒或者毫秒，因此不需要持久就能保证在分布式系 统中全局唯一、粗略递增等。

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

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

定期校对模式多应用于金融系统中。金融系统由于涉及资金安全， 需要保证准确性，所以需要多重的一致性保证机制，包括商户交易对 账、系统间的一致性对账、现金对账、账务对账、手续费对账等，这些 都属于定期校对模式。顺便说一下，金融系统与社交应用在技术上的本 质区别为：社交应用在于量大，而金融系统在于数据的准确性。

可靠消息模式 在分布式系统中，对于主流程中优先级比较低的操作，大多采用异 步的方式执行，也就是前面提到的异步确保模型，为了让异步操作的调 用方和被调用方充分解耦，也由于专业的消息队列本身具有可伸缩、可 分片、可持久等功能，我们通常通过消息队列实现异步化。对于消息队 列，我们需要建立特殊的设施来保证可靠的消息发送及处理机的幂等 性。 1）消息的可靠发送 消息的可靠发送可以认为是尽最大努力发送消息通知，有以下两种 实现方法。 第1种，在发送消息之前将消息持久到数据库，状态标记为待发 送，然后发送消息，如果发送成功，则将消息改为发送成功。定时任务 定时从数据库捞取在一定时间内未发送的消息并将消息发送。

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

一些公司把消息的可靠发送实现在了中间件里，通过Spring的注 入，在消息发送时自动持久消息记录，如果有消息记录没有发送成功， 则定时补偿发送。

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

缓存一致性模式 在大规模、高并发系统中的一个常见的核心需求就是亿级的读需 求，显然，关系型数据库并不是解决高并发读需求的最佳方案，互联网 的经典做法就是使用缓存来抗住读流量。下面是使用缓存来保证一致性 的最佳实践。 · 如果性能要求不是非常高，则尽量使用分布式缓存，而不要使用 本地缓存。 · 写缓存时数据一定要完整，如果缓存数据的一部分有效，另一部 分无效，则宁可在需要时回源数据库，也不要把部分数据放入缓存中。 · 使用缓存牺牲了一致性，为了提高性能，数据库与缓存只需要保 持弱一致性，而不需要保持强一致性，否则违背了使用缓存的初衷。 · 读的顺序是先读缓存，后读数据库，写的顺序要先写数据库，后 写缓存。