目录
前言：分布式一致性问题的提出
在系统架构中，采用多副本
1）增加可用性，避免单点
2）通过负载均衡技术，提供性能
引入了一个重要问题：数据的复制问题
客户端C1将系统中的值K由V1更新成V2，客户端C2无法立刻读取到K的最新值，需要一段时间后才能读到。数据库之间的复制延迟。
什么是分布式一致性问题？
引入多副本后，对一个副本数据进行更新的同时，必须确保能够更新其他的副本，否则不通副本之间数据将不一致
MySQL同步复制、半同步复制、异步复制
同步复制：保证数据一致性，但是系统性能下降
异步复制：系统性能高，但是无法保证slave数据与master一致
数据复制带来的挑战：如何保证数据一致，但又不影响系统性能
一致性级别
-
强一致性：系统写入的数据是什么，读出来的就是什么（可理解为实时，任何时刻）
-
弱一致性：系统在写入数据成功后，不承诺可以立即读到写入的值，也不承诺多久之后能够达到一致
会话一致性：保证对于写入的值，同一个客户端会话可以读到，但其他会话不保证
用户一致性：保证对于写入的值，同一个用户可以读到，但其他用户不保证
-
最终一致性：保证在一定时间内，能够得到数据一致（业界在大型分布式系统的数据一致性上推崇的模型）
1.1 从集中式到分布式
| 概念 |
特点 |
问题 |
||
|---|---|---|---|---|
| 集中式 |
系统由1台或多台计算机组成中心节点，系统的所有业务单元都集中部署在中心节点上。 |
优点：部署结构简单。 |
IBM大型主机 |
1）大型主机人才培养成本高，要求运维人员掌握技术细节。 2）大型主机昂贵，IBM大型主机，售价可能在上百万美元。 3）单点问题。
|
| 分布式 |
硬件或软件组件分布在不通的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调。 |
1）分布性 计算机节点在空间上随意分布，且分布情况随时变动 2）对等性 计算机节点是对等的，无主从之分 副本 数据副本：不同节点上持久化同一份数据 服务副本：多个节点提供相同的服务 3）并发性 多个节点并发操作共享资源，如数据库或分布式存储 4）缺乏全局时钟 缺乏全局时钟控制，很难定义两个事件谁先谁后 5）故障总是会发生 |
PC机性能提升及网络技术快速普及，很多企业改用小型机和普通PC搭建分布式系统。阿里巴巴去“IOE”（其中的I指的是IBM的小型机，O指的是Oracle的数据库，E指的是EMC的高端存储）。 |
分布式环境典型问题 通信异常 消息丢失：光纤、路由器等设备故障 或者 系统不可以导致无法通信。 消息延迟：节点之间通信延迟大于单机操作。单机内存访问延时为纳秒数量级(通常10ns左右)，正常的一次网络延迟在0.1-1ms左右。约100倍。 网络分区 脑裂：网络发生异常，导致节点之间延时增大，仅部分节点之间能进行正常通信，出现局部小集群。 三态 单机系统中的函数调用，结果是明确的，成功或失败。 分布式系统中每一次请求与响应，存在“三态”，成功、失败、超时。 超时发生时，请求方无法确定请求是否被成功处理。 超时情形1：client发送请求超时 超时情形2：server端发送响应时超时
节点故障 节点宕机或“僵死”。 |
1.2 从ACID到CAP/BASE
ACID
事务的ACID特性。
原子性（Atomicity)
指事务是一个原子的操作序列。
要么1）全部成功执行
要么2）全部不执行
一致性（Consistency）
事务执行的结果使数据库从一个一致性状态转变为另一个一致性状态。
如果数据库故障，事务尚未完成就*中断，事务对数据库所做的修改一部分已写入数据库，数据库就处于不一致状态。
隔离性（Isolation）
指在并发环境中，并发的事务是相互隔离的，一个事务的执行不能被其他事务干扰。
事务隔离级别
标准SQL规范中，4个事务隔离级别，读未提交（Read Uncommitted）、读提交（Read Committed）、可重复读（Repeatable Read）、串行化（Serializable）。
脏读：事务读取了其他事务未提交的数据
不可重复读：事务会对某一数据多次读取，多次读取到的值的不一样的（事务操作过程中，由于其他事务对数据做了修改）。
幻读：事务会对某一数据集(注意是数据集)多次读取，多次读取过程中，发现数据集多了一些记录或少了一些记录。（事务操作过程中，由于其他事务对数据集做了新增或删除操作）
不可重复读的和幻读很容易混淆，不可重复读侧重于修改，幻读侧重于新增或删除。解决不可重复读的问题只需锁住满足条件的行，解决幻读需要锁表
事务隔离级别详解：
| 隔离级别 |
定义 |
举例 |
脏读 |
不可重复读 |
幻读 |
|---|---|---|---|---|---|
| 读未提交 （Read Uncommitted） |
事务对某一数据进行了更新，未提交时，其他事务能够访问此数据。 |
事务A和事务B同时执行，事务A的操作是将某个数据项的值从1开始，每次加1，直到变成10后进行事务提交。 此时，事务B能够看到A操作过程中的所有中间值（1,2,3,4,5...,9,10）。 |
存在 （能够读到未提交的数据） |
存在 （多次对同一数据的读取，读到的值不一样） |
存在 |
| 读提交 （Read Committed） |
只允许读取到其他事务已经提交的数据。 |
事务A和事务B同时执行，事务A的操作同上。 此时，事务B无法看到A操作过程中的所有中间值，只能看到1,10。 但是，如果还有一个事务C，执行和事务A类似的操作将数据项从10加到20， 此时，事务B也能够看到C操作的最终操作值20。 |
存在 （多次对同一数据的读取，读到的值不一样） |
存在 |
|
| 可重复读 （Repeatable Read） |
事务处理过程中，对同一个数据的多次读取，是一致的。 |
事务A和事务B同时执行，事务A的操作同上、事务C的操作也同上。 此时，事务B只能看到数据的值1。
|
存在 （举例： 教务系统，某事务查找语文成绩90分以上的学生，事务执行过程中，其他事务做修改导致语文90分以上学生增加了或减少了，导致多次获取到的数据集不一样。) |
||
| 串行化 （Serializable） |
要求所有事物被串行执行，即事务只能一个接一个地处理，不能并行处理。 |
事务B需要等待事务A执行完后执行。 |
事务隔离级别越高，越能保证数据的完整性和一致性，同时对并发性能的影响就越大。
MySQL默认事务隔离级别是可重复读（Repeatable Read）。
持久性（Durability）
指一个事务一旦提交，它对数据库中数据的变更就是永久性的。
即使系统崩溃会机器宕机，数据库重启后，一定能恢复会事务提交后的状态。
分布式事务
分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上。
通常一个分布式事务由多个分布式的操作序列组成，会涉及多个数据源或业务系统的操作。
一个典型的分布式事务场景：跨银行转账
从中国银行转账到建设银行10000元，
中国银行的账户需要使用取款服务取出10000元，
建设银行的账户需要使用存款服务存入10000元。
这存款和取款两个服务是相互独立的，共同构成了一个完整的分布式事务。
如果从中国银行取款成功，但是因某种原因建设银行存款服务失败了，那么就必须回滚到取钱前的状态。
CAP理论
CAP理论来源
2000年7月，加州大学伯克利分校的Eric Brewer教授，首次提出CAP猜想。
2002年，麻省理工学院的Seth Gilbert和Nancy Lynch从理论上证明了CAP猜想。
从此，CAP理论正式成为分布式计算领域工人的定理，深深影响了分布式计算的发展。
CAP理论
一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）。最多只能同时满足其中两项。
一致性
指数据在多个副本之间能够保持一致。
在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统被认为具有强一致性（或严格一致性）。
可用性
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每个请求总是能够在有限的时间内返回结果。
“有限的时间内”：系统必须能够在指定的时间（即响应时间）内返回对应的处理结果，如果超过了，则认为系统不可用。
有限的时间内是系统设计之初九设定好的运行指标（SLA），不同系统之间有很大不同。
举例：搜索引擎通常0.5秒内返回用户检索结果。HIVE海量数据查询平台，数据检索时间20-30秒。
“返回结果”：系统返回一个正常的返回结果，能够明确反映请求处理是成功还是失败。
举例：系统返回结果是系统错误，如“OutOfMemoryError”或“System has crashed”认为系统是不可用的。
分区容错性
分区容错性是指分布式系统在遇到任何网络分区故障的时候，仍然能够保证对外系统满足一致性和可用性的服务。
网络分区指分布式系统中不同的节点分布在不同的子网络中，子网络之间网络不连通，但是各个子网络内部网络是正常的，导致整个系统的网络环境被切分成若干个孤立的区域。
对应分布式系统，在网络异常时，必然会出现子网络，因此，分区容错性是最基本的要求。
因此，通常根据业务特点在C(一致性)和A(可用性)之间做平衡。
CAP定理应用
| 放弃CAP |
说明 |
总结 |
|
|---|---|---|---|
| CA |
放弃P |
放弃P后如何处理： 由于网络异常时，网络分区必然出现。 为了避免出现网络分区问题，最简单的做法是将所有数据都放到一个分布式节点上。 放弃P的同时意味着放弃了系统可扩展性。 |
单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。 |
| CP |
放弃A |
放弃A后如何处理： 一点遇到网络分区或其他故障，受影响的服务需等待一段时间。 因此，在等待期间系统无法提供正常服务，即不可用。 |
满足一致性，分区容错性的系统，通常性能不是特别高。 |
| AP |
放弃C |
放弃C后如何处理： 放弃C指的是放弃数据的强一致性，保留数据的最终一致性。 即不保证数据实时一致性，但承诺，数据最终会达到一致。 （时间窗口，具体多久达到一致取决于系统的设计） |
满足可用性，分区容错性的系统，通常可能对一致性要求低一些。 |
BASE理论
由eBay的架构师提出。
BASE
BA（Basically Available）：基本可用
S（Soft state）：软状态
E（Eventually consistent）：最终一致性
BASE是基于CAP定理演化而来，是对CAP中一致性和可用性权衡的结果。
核心思想是：即使无法做到强一致性，但是应用应根据自身业务特点，采用适当的方式达到最终一致性。
基本可用
指分布式系统出现故障时，允许损失部分可用性。
举例：
1）响应时间上的损失
通常，搜索引擎返回结果在0.5秒内。在发生故障(部分机房断电或断网)，响应时间增加到1-2秒。
2）功能上的损失
正常情况下，电子商务网站上每一次购物，消费者都能顺利完成每一笔订单。
但是，在节日大促时，流量激增，为保存系统，部分消费者被引导到降级页面。
软状态
指系统中的数据存在中间状态，并认为中间态不影响系统可用性。
即允许系统不同节点间数据副本之间数据同步存在延迟。
最终一致性
指系统中所有数据副本，经过一段时间的同步后，最终能够达到一致。
在实际工程实践中，最终一致性存在5种变种。
| 最终一致性变种 |
说明/举例 |
|---|---|
| 因果一致性 |
进程A更新完数据通知了进程B，进程B对数据的访问和更新应该都是基于A更新后的最新值，不能发生丢失更新的情况。 与进程A无因果关系的进行C则无此限制。 |
| 读己之所写 |
进程A更新完数据，自己总是能够访问到更新后的最新值。 （因果一致性的特殊情况） |
| 会话一致性 |
会话内的“读己之所写”。 在同一个会话内，客户端总是能够读取到数据的最新值。 |
| 单调读一致性 |
进程从系统中读取出数据项的一个值后，后续访问不应该返回更旧的值。 |
| 单调写一致性 |
系统需要保证来自同一个进程的写操作顺序执行。 |