微服务保障数据一致性的模式
在之前的文章中，我们介绍了烟囱式到SOA再到微服务以及 从平台到中台：企业IT架构转型之道两篇文章，这里继续了解和介绍微服务。
一致性问题实例
- 案例1:下订单和扣库存
如果先下订单，扣库存失败，那么会导致超卖。反之会导致少卖。两种情况都会导致运营成本增加。
- 案例2:调用超时
服务化的系统调用常常因为网络问题导致系统间调用超时，即使是网络状况良好的机房，在大量并发的情况下，同步/异步调用超时也是家常便饭。所以在调用超时时，系统不知道调用的服务是否完成了预设的功能。
- 案例3:缓存和数据库不一致
参考我之前写的DDBS 分布式DB与Cache一致性以及DDBS 缓存架构。
- 案例4:冗余表不一致
解决一致性问题的模式和思路
这方面协议有很多，比如：
2PC
3PC
Paxos
ZAB
微服务保证最终一致性的模式
在学习了之前一系列理论后，你会发现：
虽然前面的理论除了一些自身问题外，能够解决系统之间的一致性问题，但是，它们的实现比较复杂、成本比较高，最重要的是性能不好。
在现实系统和微服务中中，其底线仅仅是达到最终一致性，而不需要实现专业的、复杂的一致性协议。
实现最终一致性往往有一些非常有效、简单的模式，下面就来介绍以下这些模式及其应用场景。
查询模式
任何服务操作都需要提供一个查询接口，用来向外输出操作执行的状态。服务操作的使用方可以通过查询接口获知服务执行状态。并且通过不同状态来作出不同的处理结果。
为了能够实现查询，每个服务操作都需要一个唯一的流水号或者资源ID（比如，请求流水号，订单号）。查询可以分为：单次和批量查询。
在这里插入图片描述
在调用超时、系统状态不一致、缓存数据库不一致等情况下，就可以使用查询模式。
补偿模式
有了查询模式，我们可以得知具体操作所处的状态，就可以通过修复使得分布式系统达到一致，这就叫做补偿。
比如同步调用操作，通过查询，我们获知了业务方执行状态：业务完成或者业务在某个子操作失败（或者未知）。此时，如果业务执行方的状态为失败或者未知，那么就会立即告诉调用方失败，也叫做快速失败策略，然后调用业务操作进行逆向回滚或者不被执行操作，从而达到最终一致性。
在这里插入图片描述
异步确保模式
异步确保模式是补偿模式的一个典型案例。经常应用到使用方对响应时间要求不太高的场景中。
通常，把这类操作从主流程中摘除，通过异步的方式进行处理，处理后把结果通过通知系统通知给使用方 。
在实践中将要执行的异步操作封装后持久库，然后通过定时（定时校对模式）捞取未完成的任务进行补偿操作来实现异步确保模式，只要定时系统足够健壮，则任何任务最终都会被成功执行。
在这里插入图片描述
定期校对模式
系统在没有达到一致之前，系统间的状态是不 致的，甚至是混乱的，需要通过补偿操作来达到最终一致性的目的，但是如何来发现需要补偿的操作呢？
实现定期校对的 个关键就是分布式系统中需要有 个自始至终唯一ID，生成全局唯一ID 有以下两种方法：
- 持久型：使用数据库表自增字段或者Sequence 生成，为了提高效率，每个应用节点可以缓存一个批次的 ID ，如果机器重启则可能会损失 部分 ID ，但是这并不会产生任何问题。
- 时间型：一般由机器号、业务号、时间、单节点内自增ID组成，由于时间一般精确到秒或者毫秒，因此不需要持久就能保证在分布式系统中全局唯 、粗略递增等。
可靠消息模式
前面提到的异步确保模式，为了让异步操作的调用方和被调用方接耦合，一般可以使用消息队列（比如Kafka）。
我们需要建立特殊的设施来保障可靠消息的发送，以及处理的幂等性。
-
消息的可靠发送
消息的可靠发送可以认为是尽最大努力发送消息通知，有以下两种实现方法。
1是在发送消息之前将消息持久到数据库，状态标记为带发送，发送成功后状态才改为发送成功。
2是将消息发送给第三方的消息管理器，然后消息管理器持久到数据库，与第一种类似。 -
消息处理器的幂等性
如果我们要保障消息成功发送出去，就会有retry，有了重试机制，我们需要对有幂等性的处理。
保障幂等性的常用方法有：1.使用数据库表的唯一键进行滤重。2.使用分布式表对请求进行滤重。3.使用状态流转的方向性来滤重，通常使用数据库的行级锁来实现。4.业务本身就是幂等的。
缓存一致性模式
在大规模、高并发系统中的一个常见的核心需求就是亿级的读需求，显然，关系型数据库并不是解决高并发读需求的最佳方案，互联网经典做法就是使用缓存来抗住读流量。下面是
使用缓存来保证一致性的最佳实践。
