Design Data-Intensive Applications 读书笔记二十六 第九章:一致性保障

第九章 共识和一致性

这章讨论一些算法来构建稳健的分布式系统。讨论时我们认为第8章讨论的问题都会发生：网络会丢包，会重复订阅，会有冗余值，网络延迟不确定；时钟大概近似；节点任何时候都可能暂停或者故障。

构建这类系统的最好方法就是找到一些系统保障的抽象模型，然后实现它们，让应用依赖这些保障模型。

分布式系统最重要的一个抽象就是“共识”consensus，即所有节点都认同一件事。在网络错误和进程故障的情况下，要实现共识是件很难的事情。一旦实现了共识，应用就能做到很多事情。比如在单一主节点的分布式数据库中，如果主节点故障，那么需要进行故障转移，需要选举出新的主节点，这时候就需要所有节点对新的主节点达成共识。后续章节我们会解决共识及相关问题，首先我们要浏览分布式系统中能够提供的保障和对应的抽象，了解理论的边界。

 

一致性保障

之前提到过“最终一致性”保证，如果你在同一时间查看数据库的两个不同节点，你可能看到不同的数据，因为不同节点处理写入请求的时间不同。如果停止写入，等一段时间，那么各节点上的数据会趋于一致，这就是最终一致性，换句话说就是“收敛”。但这只是弱的一致性保障，对于应用来说是不够的；如果你写入后立马读取，看到的可能不符合预期；使用弱的保障，应用需要做更多的事情，而且很难发现bug，所以应用大多时候不能很好地工作。这章讨论能够提供的强一致性模型，我们会看到这些问题都是相互关联的：1、线性一致性。2、事件的排序，特别是逻辑性相关的和整体排序。3、如何原子化提交分布式事务，这能引导我们解决共识问题。

 

线性一致性

使用提供最终一致性的数据库时，如果同一时间查看两个不同的节点，可能看到不同的值，这很让人困惑；那么数据库能不能伪装成只有一个备份，这样素有客户端看到的都是相同的数据。这个想法背后是线性一致性， linearizability（也称atomic consistency, strong

consistency, immediate consistency, or external consistency）。在线性化系统的系统中，只要有一个客户端写入了值，那么所有客户端都应该能从数据库中看到刚才写入的值。这意味着读取的值都是最新的，而不是过期的缓存。

图9-1所示就不满足线性一致性，一个客户端写入后，不同客户端看到的数据不同。

 

什么使得系统线性化

图9-2所示：三个客户端同时写入或者读取相同的键x，client C写入时，其他客户端可能读取到0或者1，但是写入后，都读取到1；但是这并不够

如图9-3；在写入时，其他客户端可能读取到0或者1，但是只要一个客户端读取到1，那么后续的读取操作都返回1，不论写入是否完成。

图9-4，标注了操作的顺序；这就是线性化的直观感受。

 

 

依赖线性一致性

什么情况下，线性一致性有用？

1、加锁和选举主节点

类似ZooKeeper这种协调服务需要使用一致性算法来实现加锁和主节点选举。

2、一致性和唯一性保证

数据库里很多地方需要唯一性，比如主键，用户名这些需要唯一性保证。类似的银行账户余额，机票订单等都需要唯一性限制。

3、跨渠道定时依赖

假设你有一个网站，用户可以上传照片，同时后台还有一个进程用于修改图片尺寸（生成缩略图），这个架构和数据流如图9-5

如果系统不是线性一致的，那么可能产生竞态条件。如果上图中发送消息比较快，也就是3和4快于存储服务的内置备份过程，这种情况下，步骤5中，图片裁剪器可能看到旧版本的全尺寸图片，如果处理的是旧版本的图片，那么全尺寸的图片和裁剪后的就对不上了。发生这种问题是因为网页服务和图片之间有两个通信渠道，可能发生竞态条件。