分布式事务／微服务架构下的数据一致性

********* https://www.cnblogs.com/szlbm/p/5588543.html

 

分布式理论：

CAP定理

CAP定理是由加州大学伯克利分校Eric Brewer教授提出来的，他指出WEB服务没法同时知足一下3个属性：

• 一致性(Consistency) ： 客户端知道一系列的操做都会同时发生(生效)
• 可用性(Availability) ： 每一个操做都必须以可预期的响应结束
• 分区容错性(Partition tolerance) ： 即便出现单个组件没法可用,操做依然能够完成

具体地讲在分布式系统中，在任何数据库设计中，一个Web应用至多只能同时支持上面的两个属性。显然，任何横向扩展策略都要依赖于数据分区。所以，设计人员必须在一致性与可用性之间作出选择。

一：2PC两阶段提交协议，该协议分为如下两个阶段：

• 第一阶段：事务协调器要求每一个涉及到事务的数据库预提交(precommit)此操做，并反映是否能够提交.
• 第二阶段：事务协调器要求每一个数据库提交数据。

3PC在两阶段基础上增长超时处理。

    CanCommit，PreCommit，doCommit。

二：BASE理论

在分布式系统中，咱们每每追求的是可用性，它的重要程序比一致性要高，那么如何实现高可用性呢？ 前人已经给咱们提出来了另一个理论，就是BASE理论，它是用来对CAP定理进行进一步扩充的。BASE理论指的是：

• Basically Available（基本可用）
• Soft state（软状态）
• Eventually consistent（最终一致性）

BASE理论是对CAP中的一致性和可用性进行一个权衡的结果，理论的核心思想就是：咱们没法作到强一致，但每一个应用均可以根据自身的业务特色，采用适当的方式来使系统达到最终一致性（Eventual consistency）。

 

分布式事务 解决方案

1、两阶段提交（2PC）

2、补偿事务（TCC）

TCC 其实就是采用的补偿机制，其核心思想是：针对每一个操做，都要注册一个与其对应的确认和补偿（撤销）操做。它分为三个阶段：

• Try 阶段主要是对业务系统作检测及资源预留

• Confirm 阶段主要是对业务系统作确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm必定成功。

• Cancel 阶段主要是在业务执行错误，须要回滚的状态下执行的业务取消，预留资源释放。

3、本地消息表（异步确保）

本地消息表这种实现方式应该是业界使用最多的，其核心思想是将分布式事务拆分红本地事务进行处理

消息生产方，须要额外建一个消息表，并记录消息发送状态。消息表和业务数据要在一个事务里提交，也就是说他们要在一个数据库里面。而后消息会通过MQ发送到消息的消费方。若是消息发送失败，会进行重试发送。

消息消费方，须要处理这个消息，并完成本身的业务逻辑。此时若是本地事务处理成功，代表已经处理成功了，若是处理失败，那么就会重试执行。若是是业务上面的失败，能够给生产方发送一个业务补偿消息，通知生产方进行回滚等操做。

生产方和消费方定时扫描本地消息表，把还没处理完成的消息或者失败的消息再发送一遍。若是有靠谱的自动对帐补帐逻辑，这种方案仍是很是实用的。

这种方案遵循BASE理论，采用的是最终一致性，笔者认为是这几种方案里面比较适合实际业务场景的，即不会出现像2PC那样复杂的实现(当调用链很长的时候，2PC的可用性是很是低的)，也不会像TCC那样可能出现确认或者回滚不了的状况。

即：

（1）Producer端准备1张消息表，把update DB和insert message这2个操做，放在一个DB事务里面。

（2）准备一个后台程序，源源不断的把消息表中的message传送给消息中间件。失败了，不断重试重传。容许消息重复，但消息不会丢，顺序也不会打乱。

（3）Consumer端准备一个判重表。处理过的消息，记在判重表里面。实现业务的幂等。

4、MQ 事务消息

第一阶段Prepared消息，会拿到消息的地址。
第二阶段执行本地事务。

第三阶段经过第一阶段拿到的地址去访问消息，并修改状态。

RocketMQ解决分布式事务

http://blog.csdn.net/chunlongyu/article/details/53844393?from=timeline&isappinstalled=0

5、Sagas 事务模型

http://www.cnblogs.com/savorboard/p/distributed-system-transaction-consistency.html

 

Paxos 算法

第一阶段：Prepare阶段

A把申请修改的请求Prepare Request发给全部的结点A，B，C。注意，Paxos算法会有一个Sequence Number（你能够认为是一个提案号，这个数不断递增，并且是惟一的，也就是说A和B不可能有相同的提案号），这个提案号会和修改请求一同发出，任何结点在“Prepare阶段”时都会拒绝其值小于当前提案号的请求。因此，结点A在向全部结点申请修改请求的时候，须要带一个提案号，越新的提案，这个提案号就越是是最大的。

若是接收结点收到的提案号n大于其它结点发过来的提案号，这个结点会回应Yes（本结点上最新的被批准提案号），并保证不接收其它<n的提案。这样一来，结点上在Prepare阶段里老是会对最新的提案作承诺。

优化：在上述 prepare 过程当中，若是任何一个结点发现存在一个更高编号的提案，则须要通知 提案人，提醒其中断此次提案。

第二阶段：Accept阶段

若是提案者A收到了超过半数的结点返回的Yes，而后他就会向全部的结点发布Accept Request（一样，须要带上提案号n），若是没有超过半数的话，那就返回失败。

当结点们收到了Accept Request后，若是对于接收的结点来讲，n是最大的了，那么，它就会修改这个值，若是发现本身有一个更大的提案号，那么，结点就会拒绝修改。

 

https://mp.weixin.qq.com/s?__biz=MzA4NDc2MDQ1Nw==&mid=2650238031&idx=1&sn=d7ba7844f15d587c83906aedd073748a&mpshare=1&scene=1&srcid=1024bnPerFqUMufkSC8uzmMI&key=93f66e49714b3d734c88f2c68d820c505a898bd42b9c9714296f5216e5c4d40a9681644c993864c293a59ab6b3397948a6160d2a015c134991150f71c25230a74a02d490cacb42bf6d9cb8b8b19a68b2&ascene=0&uin=Mjc5Nzc3MDE4MA%3D%3D&devicetype=iMac+MacBookPro12%2C1+OSX+OSX+10.12.2+build(16C67)&version=12020010&nettype=WIFI&fontScale=100&pass_ticket=v8qHthuF0zac388%2Bnxt6zRpmvjTkgXdRZTxPzbb1XcT29GVsDtF%2BAT1fKF5TN0wb

 

https://waylau.com/distributed-system-transaction/

 

 

https://mp.weixin.qq.com/s?__biz=MzIwMzg1ODcwMw==&mid=2247486826&idx=1&sn=e28b4ba3d42aadbe46f81cdf3f07c424&chksm=96c9bb0aa1be321c29dc6238e8332f9c5545c183d996c206a455615a78f53fea63faf1552e40&scene=27#wechat_redirect