13 | 分布式锁Chubby（二） ：众口铄金的真相

徐老师好，分布式事务的一致性（Consistency），要从数据库事务ACID的特性之一，一致性去理解，指的是不同数据不会产生矛盾。分布式共识（Consensus），分布式系统的各个部分就按何种顺序处理数据达成一致意见的过程。也就是说一致性是结果，共识是达成一致的过程。可串行化（Serializable）是数据库事务中的概念，指的是事务被顺序处理，可线性化（Linearizability）是分布式中的概念，读操作可以读到最新写入的数据。以两次读取操作为例，可以看到Serializable和Linearizability的区别，在Serializable的要求下，两次读取操作需要顺序执行，在Linearizability的要求下，则可以并发执行。 至于为什么翻译之后为什么会很接近，这是由不同的文化差异造成的，有些词换一门语言找不到对应的表达方式。比如汉语会区分父亲和母亲两边的亲戚，有叔叔、伯伯、舅舅多种称呼，而英语中只有Uncle。阿拉伯人对骆驼的命名，爱斯基摩人对雪的命名，很多都是中文不能翻译的，而大家掌握的方言也是如此，有些词没法准确的翻译成普通话。

这个隔离级别的介绍好像有问题：串行化是为了解决幻读，幻读是在一个事务中，原来没有的记录，在执行事务的过程中增加了，导致的。可这里在可重复读中描述的问题就是不可重复读，可重复读级别，会把相关的数据加锁，所以在事务完成前，应该是刷不了卡的。

从数据库事务到状态机复制这个地方绕了好大一圈，本来没有这个疑惑，但是讲完这个完全给讲蒙圈了，看了两三遍才看明白，这两个是讲两个事情，为什么非要讲一下数据库事务呢？？ 是我还是没有明白这两个的关联，还是，这个地方本来就没有什么关系呢

感觉没必要介绍数据库的隔离级别，和分布式共识其实没啥关系，就是名字长得像吧。

针对图有几处不明白： 1、既然S1，S2，S3代表服务器，那图里的备注“S3，server 1，即ID为1的服务器”，是不是应该写成"S3，server 3，即ID为3的服务器” 2、既然S1，S2，S3都是提案者，又是接受者，那为什么S1发起的提案，图中S3没有画出来 3、提案4.2：代表第4轮，服务器2发出的提案，为什么在图中是S3发起的提案，但提案号是4.5？

一个事务里会多次读取我们的银行卡余额。如果在这个过程中，我们在其他地方刷卡消费了，那么两次读到的余额会不同。这个隔离级别一般也不太会使用，因为这样一个事务中两个完全相同的读操作，会读到完全不同的数据，也就是会出现“幻读”。------这个问题不是幻读，是不可重复读。RR隔离级别是解决不可重复读的，mysql innodb存储引擎也能同时解决有些情况下的幻读。可序列化才能解决幻读。

1、分布式共识是一种协议，一种方法论，按照这个协议流程多个参与者可以针对某一个决议达成一直的结论； 2、分布式事务，是行为描述，是描述我多个参与者做一个决议，这个决议的内容可能相同，可能不同角色内容是不同的，但是要求做的这个动作是满足ACID的； 3、可以用raft共识协议达成分布式事务的一致，可以用paxos共识协议达成分布式事务的一致，可以用；两阶段，三阶段协议达成分布式事务的一致，可以直接用一把锁达成分布式事务的一致，关键是这个事务行为的一致的要求是是什么？是什么隔离级别？性能？容错等？ 可串行化和可线性化的理解： 可串行化：理解成一个操作的互斥程度，还是单机的例子，一个文件命A和B同时来修改，不管谁先谁后，都是一个操作完成后，另外一个才开始；迁移到分布式事务的场景来看，也就是事务之间也是要支持这种串行执行的效果，因为本身可以随意改的，但是要支持这种效果 可线性化：是在操作数据的这个角色视角来看的，我写入了马上能查到，操作者不关系底层是分布式的还是单机的

可线性化（Linearizability）和可串行化（Serializability）在英文环境中看着还挺像的，通过中文翻译了一次之后反而觉得还好。 串行化指在竞态条件（至少一个写操作）出现时，一次一个的执行操作。 线性化指写请求完成后，读请求能读到刚刚写入的值，使得多台机器组成的集群看起来只有一个数据副本一样。

读已提交 和 可重复读 在读的时候加锁就 可以解决一房两卖的问题

串行化就是事务是一个一个执行的，对相同的数据执行并发的读/写，写/写只能一个一个的执行，这应该也是共识算法所达成的效果，既这一轮只能有一个提案者的提案被接受执行，对于同一数据只要通过共识就算成功；可线性化是同一个客户端发起操作成功之后，对于分布式下所有副本的读/写都是基于前一个操作下的