知其所以然~分布式事务cap

背景

　一致性是一个抽象的、具有多重含义的计算机术语，在不同应用场景下，有不同的定义和含义。在传统的IT时代，一致性通常指强一致性，强一致性通常体现在你中有我、我中有你、浑然一体；而在互联网时代，一致性的含义远远超出了它原有的含义，在我们讨论互联网时代的一致性之前，我们先了解一下互联网时代的特点，互联网时代信息量巨大、需要计算能力巨大，不但对用户响应速度要求快，而且吞吐量指标也要向外扩展（既：水平伸缩），于是单节点的服务器无法满足需求，服务节点开始池化，想想那个经典的故事，一只筷子一折就断，一把筷子怎么都折不断，可见人多力量大的思想是多么的重要，但是人多也不一定能解决所有事情，还得进行有序、合理的分配任务，进行有效的管理，于是互联网时代谈论最多的话题就是拆分，拆分一般分为“水平拆分”和“垂直拆分”（大家不要对应到数据库或者缓存拆分，这里主要表达一种逻辑）。这里，“水平拆分”指的是同一个功能由于单机节点无法满足性能需求，需要扩展成为多节点，多个节点具有一致的功能，组成一个服务池，一个节点服务一部分的请求量，团结起来共同处理大规模高并发的请求量。“垂直拆分”指的是按照功能拆分，秉着“专业的人干专业的事儿”的原则，把一个复杂的功能拆分到多个单一的简单的元功能，不同的元功能组合在一起，和未拆分前完成的功能是一致的，由于每个元功能职责单一、功能简单，让维护和变更都变得更简单、安全，更易于产品版本的迭代，在这样的一个互联网的时代和环境，一致性指分布式服务化系统之间的弱一致性，包括应用系统一致性和数据一致性。
　　无论是水平拆分还是垂直拆分，都解决了特定场景下的特定问题，凡事有好的一面，都会有坏的一面，拆分后的系统或者服务化的系统最大的问题就是一致性问题，这么多个具有元功能的模块，或者同一个功能池中的多个节点之间，如何保证他们的信息是一致的、工作步伐是一致的、状态是一致的、互相协调有序的工作呢？
　　本文根据作者在互联网企业的实际项目经验，对服务化系统中最难解决的一致性问题进行研究和探讨，试图从实践经验中找到规律，抽象出模式，分享给大家，希望对大家的项目实施有所帮助，在对实践的总结中也会对相关的一致性术语做最朴实的解释，希望能帮助大家彻底理解一致性的本质，并能将其应用到实践，解决读者现实中遇到的服务化系统的一致性问题，本文使用理论与实践相结合的方法，突出在实践中解决问题的模式，因此叫做《分布式服务化系统一致性的“最佳实干”》。
　　

实例，产生不一致的例子

1. 案例1：买房
   　　假如你想要享受生活的随意，只想买个两居，不想让房贷有太大压力，而你媳妇却想要买个三居，还得带花园的，那么你们就不一致了，不一致导致生活不愉快、不协调，严重情况下还会吵架，可见生活中的不一致问题影响很大。
2. 案例2：转账
   　　转账是经典的不一致案例，设想一下银行为你处理一笔转账，扣减你账户上的余额，然后增加别人账户的余额；如果扣减你的账户余额成功，增加别人账户余额失败，那么你就会损失这笔资金。反过来，如果扣减你的账户余额失败，增加别人账户余额成功，那么银行就会损失这笔资金，银行需要赔付。对于资金处理系统来说，上面任何一种场景都是不允许发生的，一旦发生就会有资金损失，后果是不堪设想的，严重情况会让一个公司瞬间倒闭，可参考案例（http://blog.jobbole.com/50392/）。
3. 案例3：下订单和扣库存
   　　电商系统中也有一个经典的案例，下订单和扣库存如何保持一致，如果先下订单，扣库存失败，那么将会导致超卖；如果下订单没有成功，扣库存成功，那么会导致少卖。两种情况都会导致运营成本的增加，严重情况下需要赔付。
4. 案例4：同步超时
   　　服务化的系统间调用常常因为网络问题导致系统间调用超时，即使是网络很好的机房，在亿次流量的基数下，同步调用超时也是家常便饭。系统A同步调用系统B超时，系统A可以明确得到超时反馈，但是无法确定系统B是否已经完成了预定的功能或者没有完成预定的功能。于是，系统A就迷茫了，不知道应该继续做什么，如何反馈给使用方。（曾经的一个B2B产品的客户要求接口超时重新通知他们，这个在技术上是难以实现的，因为服务器本身可能并不知道自己超时，可能会继续正常的返回数据，只是客户端并没有接受到结果罢了，因此这不是一个合理的解决方案）。
5. 案例5：异步回调超时
   　　此案例和上一个同步超时案例类似，不过这个场景使用了异步回调，系统A同步调用系统B发起指令，系统B采用受理模式，受理后则返回受理成功，然后系统B异步通知系统A。在这个过程中，如果系统A由于某种原因迟迟没有收到回调结果，那么两个系统间的状态就不一致，互相认知不同会导致系统间发生错误，严重情况下会影响核心事务，甚至会导致资金损失。
6. 案例6：掉单
   　　分布式系统中，两个系统协作处理一个流程，分别为对方的上下游，如果一个系统中存在一个请求，通常指订单，另外一个系统不存在，则导致掉单，掉单的后果很严重，有时候也会导致资金损失。
7. 案例7：系统间状态不一致
   　　这个案例与上面掉单案例类似，不同的是两个系统间都存在请求，但是请求的状态不一致。
8. 案例8：缓存和数据库不一致
   　　交易相关系统基本离不开关系型数据库，依赖关系型数据库提供的ACID特性（后面介绍），但是在大规模高并发的互联网系统里，一些特殊的场景对读的性能要求极高，服务于交易的数据库难以抗住大规模的读流量，通常需要在数据库前垫缓存，那么缓存和数据库之间的数据如何保持一致性？是要保持强一致呢还是弱一致性呢？
9. 案例9：本地缓存节点间不一致
   　　一个服务池上的多个节点为了满足较高的性能需求，需要使用本地缓存，使用了本地缓存，每个节点都会有一份缓存数据的拷贝，如果这些数据是静态的、不变的，那永远都不会有问题，但是如果这些数据是半静态的或者常被更新的，当被更新的时候，各个节点更新是有先后顺序的，在更新的瞬间，各个节点的数据是不一致的，如果这些数据是为某一个开关服务的，想象一下重复的请求走进了不同的节点（在failover或者补偿导致的场景下，重复请求是一定会发生的，也是服务化系统必须处理的），一个请求走了开关打开的逻辑，同时另外一个请求走了开关关闭的逻辑，这导致请求被处理两次，最坏的情况下会导致灾难性的后果，就是资金损失。
10. 案例10：缓存数据结构不一致
    　　这个案例会时有发生，某系统需要种某一数据结构的缓存，这一数据结构有多个数据元素组成，其中，某个数据元素都需要从数据库中或者服务中获取，如果一部分数据元素获取失败，由于程序处理不正确，仍然将不完全的数据结构存入缓存，那么缓存的消费者消费的时候很有可能因为没有合理处理异常情况而出错。

ACID（酸）

　　如何保证强一致性呢？计算机专业的童鞋在学习关系型数据库的时候都学习了ACID原理，这里对ACID做个简单的介绍。如果想全面的学习ACID原理，请参考ACID（https://en.wikipedia.org/wiki/ACID）。
　　关系型数据库天生就是解决具有复杂事务场景的问题，关系型数据库完全满足ACID的特性。
　　

ACID指的是：

• A: Atomicity，原子性
• C: Consistency，一致性
• I: Isolation，隔离性
• D: Durability，持久性

具有ACID的特性的数据库支持强一致性，强一致性代表数据库本身不会出现不一致，每个事务是原子的，或者成功或者失败，事物间是隔离的，互相完全不影响，而且最终状态是持久落盘的，因此，数据库会从一个明确的状态到另外一个明确的状态，中间的临时状态是不会出现的，如果出现也会及时的自动的修复，因此是强一致的。
　　3个典型的关系型数据库Oracle、Mysql、Db2都能保证强一致性，Oracle和Mysql使用多版本控制协议实现，而DB2使用改进的两阶段提交协议来实现。
　　如果你在为交易相关系统做技术选型，交易的存储应该只考虑关系型数据库，对于核心系统，如果需要较好的性能，可以考虑使用更强悍的硬件，这种向上扩展（升级硬件）虽然成本较高，但是是最简单粗暴有效的方式，另外，Nosql完全不适合交易场景，Nosql主要用来做数据分析、ETL、报表、数据挖掘、推荐、日志处理等非交易场景。
　　前面提到的案例2-转账和案例3-下订单和扣库存都可以利用关系型数据库的强一致性解决。
　　然而，前面提到，互联网项目多数具有大规模高并发的特性，必须应用拆分的理念，对高并发的压力采取“大而化小、小而化了”的方法，否则难以满足动辄亿级流量的需求，即使使用关系型数据库，单机也难以满足存储和TPS上的需求。为了保证案例2-转账可以利用关系型数据库的强一致性，在拆分的时候尽量的把转账相关的账户放入一个数据库分片，对于案例3，尽量的保证把订单和库存放入同一个数据库分片，这样通过关系型数据库自然就解决了不一致的问题。
　　然而，有些时候事与愿违，由于业务规则的限制，无法将相关的数据分到同一个数据库分片，这个时候我们就需要实现最终一致性。
　　对于案例2-转账场景，假设账户数量巨大，对账户存储进行了拆分，关系型数据库一共分了8个实例，每个实例8个库，每个库8个表，共512张表，假如要转账的两个账户正好落在了一个库里，那么可以依赖关系型数据库的事务保持强一致性。
　　如果要转账的两个账户正好落在了不同的库里，转账操作是无法封装在同一个数据库事务中的，这个时候会发生一个库的账户扣减余额成功，另外一个库的账户增加余额失败的情况。
　　对于这种情况，我们需要继续探讨解决之道，CAP原理和BASE原理，BASE原理通过记录事务的中间的临时状态，实现最终一致性。

CAP（帽子理论）

　　如果想深入的学习CAP理论，请参考CAP（https://en.wikipedia.org/wiki/CAP_theorem）。
　　由于对系统或者数据进行了拆分，我们的系统不再是单机系统，而是分布式系统，针对分布式系的帽子理论包含三个元素：

• C：Consistency，一致性, 数据一致更新，所有数据变动都是同步的
• A：Availability，可用性, 好的响应性能，完全的可用性指的是在任何故障模型下，服务都会在有限的时间处理响应
• P：Partition tolerance，分区容错性，可靠性

帽子理论证明，任何分布式系统只可同时满足二点，没法三者兼顾。关系型数据库由于关系型数据库是单节点的，因此，不具有分区容错性，但是具有一致性和可用性，而分布式的服务化系统都需要满足分区容错性，那么我们必须在一致性和可用性中进行权衡，具体表现在服务化系统处理的异常请求在某一个时间段内可能是不完全的，但是经过自动的或者手工的补偿后，达到了最终的一致性。

BASE（碱）

　　BASE理论解决CAP理论提出了分布式系统的一致性和可用性不能兼得的问题，如果想全面的学习BASE原理，请参考Eventual consistency（https://en.wikipedia.org/wiki/Eventual_consistency）。
　　BASE在英文中有“碱”的意思，对应本节开头的ACID在英文中“酸”的意思，基于这两个名词提出了酸碱平衡的结论，简单来说是在不同的场景下，可以分别利用ACID和BASE来解决分布式服务化系统的一致性问题。
　　BASE模型与ACID模型截然不同，满足CAP理论，通过牺牲强一致性，获得可用性，一般应用在服务化系统的应用层或者大数据处理系统，通过达到最终一致性来尽量满足业务的绝大部分需求。

BASE模型包含个三个元素：

• BA：Basically Available，基本可用
• S：Soft State，软状态，状态可以有一段时间不同步
• E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致

BASE模型的软状态是实现BASE理论的方法，基本可用和最终一致是目标。按照BASE模型实现的系统，由于不保证强一致性，系统在处理请求的过程中，可以存在短暂的不一致，在短暂的不一致窗口请求处理处在临时状态中，系统在做每步操作的时候，通过记录每一个临时状态，在系统出现故障的时候，可以从这些中间状态继续未完成的请求处理或者退回到原始状态，最后达到一致的状态。
　　以案例1-转账为例，我们把用户A给用户B转账分成四个阶段，第一个阶段用户A准备转账，第二个阶段从用户A账户扣减余额，第三个阶段对用户B增加余额，第四个阶段完成转账。系统需要记录操作过程中每一步骤的状态，一旦系统出现故障，系统能够自动发现没有完成的任务，然后，根据任务所处的状态，继续执行任务，最终完成任务，达到一致的最终状态。
　　在实际应用中，上面这个过程通常是通过持久化执行任务的状态和环境信息，一旦出现问题，定时任务会捞取未执行完的任务，继续未执行完的任务，直到执行完成为止，或者取消已经完成的部分操作回到原始状态。这种方法在任务完成每个阶段的时候，都要更新数据库中任务的状态，这在大规模高并发系统中不会有太好的性能，一个更好的办法是用Write-Ahead Log（写前日志），这和数据库的Bin Log（操作日志）相似，在做每一个操作步骤，都先写入日志，如果操作遇到问题而停止的时候，可以读取日志按照步骤进行恢复，并且继续执行未完成的工作，最后达到一致。写前日志可以利用机械硬盘的追加写而达到较好性能，因此，这是一种专业化的实现方式，多数业务系系统还是使用数据库记录的字段来记录任务的执行状态，也就是记录中间的“软状态”，一个任务的状态流转一般可以通过数据库的行级锁来实现，这比使用Write-Ahead Log实现更简单、更快速。