分布式系统之一致性和数据复制

文章来源：www.liangsonghua.me
做者介绍：京东资深工程师-梁松华，长期关注稳定性保障、敏捷开发、JAVA高级、微服务架构

一、一致性常见问题

这些问题离咱们并不遥远,数据分散在多处会致使数据不一致，必须尽量地解决此问题，才能保证良好的用户体验，最终的指望是任何人、任什么时候间、任何地点、任何接入方式、任何服务，数据都是一致的

二、一致性模式
1)、顺序一致性(Sequencial Consistency）
每一个线程内部的指令都是按照程序规定的顺序执行的(单个线程的视角)。线程执行的交错顺序能够是作任意的，可是全部线程所看见的总体程序整体执行顺序都是同样的(总体程序的视角)

2)、弱一致性-因果一致性(Casual Consistency)
若是节点A在更新完某个数据后通知了节点B，那么节点B以后对该数据的访问和修改都是基于A更新后的值。于此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制

3)、弱一致性-入口一致性(Entry Consistency)
入口一致性要求每一个普通的共享数据都要与某种同步变量如锁(lock)或屏障(barrier)相关联

进程2在没有获取”y”数据的访问锁时，读取的值将为NIL(In the following figures, since Process2 does not hold the access right (= synchronous variable) to the data item “y”, the reading result becomes NIL)

四、弱一致性-最终一致性(Eventual consistency)

5)、弱一致性-以客户为中心的一致性（Client-centric consistency model)
包括如下四种体现

（1)、单调读一致性(Monotonic reading)
若是一个进程从系统中读取出一个数据项X的某个值后，该进程对于X后续访问都不该该返回更旧的值(If a process reads data item x, any subsequent reads on x by that process will either reply with the same value or reply with a newer value)

例子：任什么时候候你登陆邮箱服务，它都能保证你上次访问服务器时能够读取的邮件如今均可以查看

(2)、单调写一致性(Monotonic writing)
一个系统要可以保证来自同一个进程的写操做被顺序的执行,它相似以数据为中心的FIFO一致性，不过它强调的是在单一进程的顺序约束而不是并发进程集(A write operation by one process to a data item x is completed before any subsequent write to x by the same process)

(3)、写后读一致性(Read Your Writes)
进程更新一个数据后，它老是能访问到自身更新过的最新值，而不会看到旧值(The result of a write operation by a process to data item x is always observed by subsequent read operations by the same process)

例子：好比当你更新一个系统的管理密码时，必须保证更新后的密码不管你在任何地方登陆时都有效

（4)、读后写一致性(Writes Follow Reads)
同一个进程对数据项X执行的读操做以后的写操做，保证发生在与X读取值相同或比之更新的值上(The result of a write operation by a process to data item x is always observed by subsequent read operations by the same process)

一致性模式描述的是严格一致性、因果一致性和顺序一致性，保证了系统不会出现脏写、脏读、不可重复读、幻读、更新丢失的坏帐

三、解决思路-ACID

最多见的实现方式是WAL(write ahead loging)技术,它并不直接写入到系统文件中，而是写入到另一个称为WAL的文件中；若是事务失败，WAL中的记录会被忽略，撤销修改；若是事务成功，它将在随后的某个时间被写回到系统文件中，提交修改

四、解决思路-CAP
ARTS-13-分布式系统入门和实践笔记
连接:www.liangsonghua.me

五、解决思路-BASE
基本可用、中间(软)状态、最终一致

六、常看法决方案
1)、两阶段提交-2PC

TM存在单点问题，并且会同步阻塞，产生资源锁定，并发低的状况

2)、补偿机制-TCC

针对每一个操做，注册一个与其对应的确认和补偿(撤销)操做，对业务侵入性大，须要设计复杂的重试、幂行、日记记录模块

3)、补偿机制-Saga

流程：

(1)、订单服务建立最终状态未知的订单记录
(2)、订单服务建立一个CreateOrderSaga负责协调订单
(3)、CreateOrderSaga发送ReserveCredit指令至用户服务
(4)、用户服务接受到指令而后为此订单预扣款，同时回复一条代表结果的信息
(5)、CreateOrderSaga接受到信息后，发送经过或拒绝指令到订单服务
(6)、订单服务接受到指令后修改其状态

Saga能够看作是一个异步的、事件驱动的补偿事务，由Sage工做流引擎协调，其适用于无需马上返回业务发起方最终状态的场景,可是它不保证隔离性

连接：https://github.com/eventuate-...

4)、基于MQ-本地消息表

将分布式事务拆分红本地事务进行处理

5)、基于MQ-事务消息

6)、经典实现-Seata

一个典型的分布式事务过程：

(1)、TM 向 TC 申请开启一个全局事务，全局事务建立成功并生成一个全局惟一的 XID
(2)、XID 在微服务调用链路的上下文中传播
(3)、RM 向 TC 注册分支事务，将其归入 XID 对应全局事务的管辖
(4)、TM 向 TC 发起针对 XID 的全局提交或回滚决议
(5)、TC 调度 XID 下管辖的所有分支事务完成提交或回滚请求

连接：https://github.com/seata/seata

七、数据复制
1)、服务端(Server Startup Replica)

2)、客户端(Client Startup Replica)
缓存失效时长不宜过长

八、数据同步
须要数据多备份就意味着须要内容同步，常见的方式有

1)、 将更新通知传输到副本(Propagate only updates notifications)
2)、 将更新数据传输到副本(Transmit update data from one copy to another)
3)、 将更新操做传输到副本-推荐方式(Propagate update operations to other replicas)

好比mysql的主从复制过程

文章来源：www.liangsonghua.me做者介绍：京东资深工程师-梁松华，长期关注稳定性保障、敏捷开发、JAVA高级、微服务架构