共计 2767 个字符，预计需要花费 7 分钟才能阅读完成。
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 的主从复制过程
BLOG 连接：www.liangsonghua.me
作者介绍：京东资深工程师 - 梁松华，长期关注稳定性保障、敏捷开发、JAVA 高级、微服务架构
