一致性理论

当我们的单个数据库的性能产生瓶颈的时候，我们可能会对数据库进行水平分区，这里所说的分区指的是物理分区，分区之后可能不同的库就处于不同的服务器上了，这个时候单个数据库的 ACID 已经不能适应这种情况了，而在这种 ACID 的集群环境下，再想保证集群的 ACID 几乎是很难达到，或者即使能达到那么效率和性能会大幅下降，最为关键的是再很难扩展新的分区了，这个时候如果再追求集群的 ACID 会导致我们的系统变得很差，这时我们就需要引入一个新的理论原则来适应这种集群的情况，就是 CAP 原则或者叫 CAP 定理

在分布式系统中，一致性（Consistency）、可用性（Availability）和分区容忍性（Partition Tolerance）3 个要素最多只能同时满足两个，不可兼得。其中，分区容忍性又是不可或缺的。

一致性模型

数据的一致性模型可以分成以下 3 类：
强一致性：数据更新成功后，任意时刻所有副本中的数据都是一致的，一般采用同步的方式实现。
弱一致性：数据更新成功后，系统不承诺立即可以读到最新写入的值，也不承诺具体多久之后可以读到。
最终一致性：弱一致性的一种形式，数据更新成功后，系统不承诺立即可以返回最新写入的值，但是保证最终会返回上一次更新操作的值。

分布式事务的几个解决方案

基本所有的分布式事务都离不开2阶段提交，都是基于2阶段提交的优化。传统意义的2pc具有非常严重的局限性，体现在：
1.使用全局事务，数据被锁住的时间横跨整个事务，直到事务结束才释放，在高并发和涉及业务模块较多的情况下 对数据库的性能影响较大。
2.在技术栈比较复杂的分布式应用中，存储组件可能会不支持 XA 协议。

解决方案一：TCC补偿模式

TCC 方案是二阶段提交的 另一种实现方式，它涉及 3 个模块，主业务、从业务和 活动管理器（协作者）

第一阶段：主业务服务分别调用所有从业务服务的 try 操作，并在活动管理器中记录所有从业务服务。当所有从业务服务 try 成功或者某个从业务服务 try 失败时，进入第二阶段。

第二阶段：活动管理器根据第一阶段从业务服务的 try 结果来执行 confirm 或 cancel 操作。如果第一阶段所有从业务服务都 try 成功，则协作者调用所有从业务服务的 confirm 操作，否则，调用所有从业务服务的 cancel 操作。

在第二阶段中，confirm 和 cancel 同样存在失败情况，所以需要对这两种情况做 异常处理以保证数据一致性。

Confirm 失败：则回滚所有 confirm 操作并执行 cancel 操作。

Cancel 失败：从业务服务需要提供自动 cancel 机制，以保证 cancel 成功。

举个例子：

try阶段：

confirm阶段：

cancel阶段：

该模式对代码的嵌入性高，要求每个业务需要写三种步骤（Try-Confirm-Cancel）的操作。并且数据一致性的控制几乎完全由开发者控制，对业务开发难度要求高，耦合度高，严重侵入业务代码。但是该模式也有一定的好处，对有无本地事务控制的资源层都可以支持，使用面广。

解决方案二：消息队列可靠消息提交

如果仔细观察生活的话，生活的很多场景已经给了我们提示。

比如在北京很有名的姚记炒肝点了炒肝并付了钱后，他们并不会直接把你点的炒肝给你，往往是给你一张小票，然后让你拿着小票到出货区排队去取。为什么他们要将付钱和取货两个动作分开呢？原因很多，其中一个很重要的原因是为了使他们接待能力增强（并发量更高）。

还是回到我们的问题，只要这张小票在，你最终是能拿到炒肝的。同理转账服务也是如此，当支付宝账户扣除1万后，我们只要生成一个凭证（消息）即可，这个凭证（消息）上写着“让余额宝账户增加 1万”，只要这个凭证（消息）能可靠保存，我们最终是可以拿着这个凭证（消息）让余额宝账户增加1万的，即我们能依靠这个凭证（消息）完成最终一致性。

如何可靠保存凭证（消息）：
　　1）支付宝在扣款事务提交之前，向实时消息服务请求发送消息，实时消息服务只记录消息数据，而不真正发送，只有消息发送成功后才会提交事务；
　　2）当支付宝扣款事务被提交成功后，向实时消息服务确认发送。只有在得到确认发送指令后，实时消息服务才真正发送该消息；
　　3）当支付宝扣款事务提交失败回滚后，向实时消息服务取消发送。在得到取消发送指令后，该消息将不会被发送；
　　4）对于那些未确认的消息或者取消的消息，需要有一个消息状态确认系统定时去支付宝系统查询这个消息的状态并进行更新。为什么需要这一步骤，举个例子：假设在第2步支付宝扣款事务被成功提交后，系统挂了，此时消息状态并未被更新为“确认发送”，从而导致消息不能被发送。
　　优点：消息数据独立存储，降低业务系统与消息系统间的耦合；
　　缺点：一次消息发送需要两次请求；业务处理服务需要实现消息状态回查接口。

如何解决消息重复投递的问题：
　　还有一个很严重的问题就是消息重复投递，以我们支付宝转账到余额宝为例，如果相同的消息被重复投递两次，那么我们余额宝账户将会增加2万而不是1万了。
　　为什么相同的消息会被重复投递？比如余额宝处理完消息msg后，发送了处理成功的消息给支付宝，正常情况下支付宝应该要删除消息msg，但如果支付宝这时候悲剧的挂了，重启后一看消息msg还在，就会继续发送消息msg。
　　解决方法很简单，在余额宝这边增加消息应用状态表（message_apply），通俗来说就是个账本，用于记录消息的消费情况，每次来一个消息，在真正执行之前，先去消息应用状态表中查询一遍，如果找到说明是重复消息，丢弃即可，如果没找到才执行，同时插入到消息应用状态表（同一事务）。

解决方案三：最大努力通知

解决方案四：阿里开源分布式中间件 Seata —— 标准分布式模型 TXC