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