DDIA 读书分享第五章：Replication，复制滞后问题

DDIA 读书分享会，会逐章进行分享，结合我在工业界分布式存储和数据库的一些经验，补充一些细节。每两周左右分享一次，欢迎加入，网站在这里。我们有个对应的分布式&数据库讨论群，每次分享前会在群里通知。如想加入，可以加我的微信号：qtmuniao，简单自我介绍下，并注明：分布式系统群。

如前所述，使用多副本的好处有：

对于读多写少的场景，想象中，可以通过使劲增加读副本来均摊流量。但有个隐含的条件是，多副本建的同步得做成异步的，否则，读副本一多，某些副本就很容易出故障，进而阻塞写入。

但若是异步复制，就会引入不一致问题：某些副本进度落后于主副本。

如果此时不再有写入，经过一段时间后，多副本最终会达到一致：最终一致性。

在实际中，网络通常比较快，副本滞后（replication lag）不太久，也即这个_最终_通常不会太久，比如 ms 级别，最多 s 级别。但是，对于分布式系统，谁都不敢打包票，由于网络分区、机器高负载等等软硬件问题，在极端情况下，这个_最终_可能会非常久。

总之，最终是一个非常不精确的限定词。

对于这种最终一致的系统，在工程中，要考虑到由于副本滞后所带来的一致性问题。

读你所写

read after write

上图问题在于，在一个异步复制的分布式数据库里，同一个客户端，写入主副本后返回；稍后再去读一个落后的从副本，就会发现：读不到自己刚写的内容！

为了避免这种反直觉的事情发生，我们引入一种新的一致性：读写一致性（read-after-write consistency），或者 读你所写一致性（read-your-writes consistency）。

若数据库提供这种一致性保证，对于单个客户端来说，就一定能够读到其所写变动。也即，这种一致性是从单个客户端角度来看的一种因果一致性。

那么如何提供这种保证，或者说，实现这种一致性呢？列举几种方案：

按内容分类。对于客户端可能修改的内容集，只从主副本读取。如社交网络上的个人资料，读自己的资料时，从主副本读取；但读其他人资料时，可以向从副本读。
按时间分类。如果每个客户端都能访问基本所有数据，则方案一就会退化成所有数据都要从主副本读取，这显然不可接受。此时，可以按时间分情况讨论，近期内有过改动的数据，从主副本读，其他的，向从副本读。那这个区分是否最近的时间阈值（比如一分钟）如何选取呢？可以监控从副本一段时间内的最大延迟这个经验值，来设置。
利用时间戳。客户端记下本客户端上次改动时的时间戳，在读从副本时，利用此时间戳来看某个从副本是否已经同步了改时间戳之前内容。可以在所有副本中找到一个已同步了的；或者阻塞等待某个副本同步到该时间戳后再读取。时间戳可以是逻辑时间戳，也可以是物理时间戳（此时多机时钟同步非常重要）。

会有一些实际的复杂 case：

数据分布在多个物理中心。所有需要发送给主副本的请求都要首先路由到主副本所在的数据中心。
一个逻辑用户有多个物理客户端。比如一个用户通过电脑、手机多终端同时访问，此时就不能用设备 id，而需要使用用户 id，来保证用户角度的读写一致性。但不同设备有不同物理时间戳，不同设备访问时可能会路由到不同数据中心。