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

文章首发于公众号:松花皮蛋的黑板报

作者就职于京东,在稳定性保障、敏捷开发、高级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工作流引擎协调，其适用于无需立刻返回业务发起方最终状态的场景,但是它不保证隔离性

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

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

5)、基于MQ-事务消息

6)、经典实现-Seata

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

(1)、TM 向 TC 申请开启一个全局事务，全局事务创建成功并生成一个全局唯一的 XID

(2)、XID 在微服务调用链路的上下文中传播

(3)、RM 向 TC 注册分支事务，将其纳入 XID 对应全局事务的管辖

(4)、TM 向 TC 发起针对 XID 的全局提交或回滚决议

(5)、TC 调度 XID 下管辖的全部分支事务完成提交或回滚请求

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