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

文章首发于公众号:松花皮蛋的黑板报
作者就职于京东,在稳定性保障、敏捷开发、高级JAVA、微服务架构有深入的理解

1、一致性常见问题

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

2、一致性模式
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)

4、弱一致性-最终一致性(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)

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

3、解决思路-ACID

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

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

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

6、常见解决方案
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

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

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

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

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高级、微服务架构