备份落后的问题

备份的原因不仅仅是容错性，像前面说到的，减小延迟和扩展性也是目标。Leader-based的备份会把所有的写请求通过一个节点完成，但是读请求可以调用其他本分节点。对于那些读负载很大，但是写请求比较少的应用来说，有一个非常好的方法。创建大量的Follower，把读请求分配到这些Follower中。这样可以减轻Leader负载的同时，让读请求就近访问，减小延迟。

在这种读扩展(read-scaling)的架构下，你可以简单地通过加Follower的方法提高读请求的负载。但是实际情况中，只有异步的同步方式才可用，如果你企图把所有的Follower都设成同步请求，一个节点异常就会导致整个系统挂掉。节点越多，越容易出问题，所以把所有的节点都设成同步请求显然是不现实的。但是从异步同步的Follower中读取数据会有一个问题，Follower的数据可能是过期的。这就导致数据库无法保证一致性，当你同时发送两个请求分别到Leader和Follower时，返回结果可能不一样，因为Leader的备份数据可能还没同步到Follower中。这种不一致时暂时的，当你停止写入，然后等一会，Follower最终会跟上Leader的进度并且与之一致。所以我们会称他为最终一致（eventual consistency）

最终这个词就跟字面上的含义一样，备份节点到底落后了多少不好说，一般可能只有不到一秒钟，可能你根本感觉不到。但是如果系统负载太大，这种落后就可以轻松达到几秒甚至分钟级。当这种落后太大的时候，不一致性的问题就不再是理论上的问题而是一个实际需要处理的问题了。这节我们讲3种典型的问题，并且讲些解决他们的方法。

读取刚写入的内容

很多应用都允许用户在提交数据之后查看他刚提交的内容。当用户提交的时候，请求肯定通过Leader，但是读取的时候可能是通过Follower读取的。在异步备份中，就会有像Figure 5.3的问题。如果用户在写入后很短的时间内去查看数据，数据没有到Follower，用户看上去就好像数据丢了一样，显然，上帝们就不太高兴了。

这种情况下，我们需要一个读写一致， （read-after-write consistency / read-your-writes consistency）。我们需要保证用户一旦刷新页面，就能看到自己所有最新的更新，不过其他用户的更新就不用保证了。只有这样才能让用户放心，他的数据都正确的保存了。 要如何才能实现呢？有几种方法

• 如果读取的内容用户可能刚刚更新，从leader读取，否则从Follower读取。这就要求你不实际去查询数据库但是能够知道某条数据可能更新了。举个例子，一般一个用户的档案信息只有用户自己可以修改，所以当一个人查看自己的档案的时候，从Leader读取，查其他人档案的时候，从Follower读取。
• 如果很多东西可能被修改，那上面那个方法就不好使了。那某些其他的字段可能能帮助你知道要不要从Leader读取。比如你可以跟踪记录你上次更新的时间，如果超过1分钟，从Follower读取，否则从Leader读取。可能还需要监控Follower的更新的落后情况，用以决定应该怎么搞。
• 客户端可以记下自己最近更新的时间戳，然后系统保证所有Follower当处理到这个用户的读取请求时，至少要更新到对应的时间戳才可以正常返回。如果一个备份节点没有更新到这个时间戳，那要么请求会被分配给其他的备份节点，或者请求等到备份更新之后才返回。这个时间戳可以是逻辑时间戳，比如更新的日志序列号，也可以是系统时间戳。
• 但是这样也会带来额外的复杂度，因为一旦发现请求必须通过Leader返回，那如果你的服务是跨地区的就惨了，你的请求要跨越千山万水发到Leader对应的数据中心去处理。耗时可想而知。

另外有一个问题是用户可能通过多个设备访问你的应用，比如同时用手机和网页。这个时候你还需要一个跨设备的读写一致(cross-device read-after-write consistency),这就又有新问题需要考虑了

• 想要知道用户的最后更新时间戳就变得更难了，原来一个设备自己记着就挺麻烦了，现在他因为没办法知道其他设备上发生了什么，所以这个功能就不能存在本地设备中而要存到一个中心服务器去了。
• 同样还是多个设备可能需要跨数据中心访问Leader的问题，跟上面问题差不多。因为虽然地域相同，但是你的不同设备走的网络不一定一样，原本可能就近访问的请求也要调到Leader的数据中心去了。

单调读 （Monotonic Reads）

第二个异常情况是当你从一个异步的Follower中读取数据时，你可能会读到过去时间的内容。

举个例子，如Figure 5-4所示，user2345的同一个请求发送给了两个Follower，一个落后的比较少，一个比较多，这就好像用户刷新了两次页面，随机分给了不同的机器。第一次他会发现user 1234更新了一条评论，但是第二次由于Follower没有更新到这个时间，就却看不到了。这就导致用户第二次请求看到的内容比第一次看到的时间要早。如果第一次也没返回，问题就还好，因为反正他也不知道，但是当下这种一会看到了，一会又看不到的情况就让人感觉很差了。

单调读（Monotonic reads）就是用来保证这个问题不会出现的。他比强一致性要求低一些，但是又比最终一致（eventual consistency）的要求高。在这个场景下，当你请求数据时，你还是有可能看到老的数据，但是他保证如果你顺序的请求几次，后面的请求一定比先前的请求的结果更新。也就是你不会看到比这次更老的数据。

实现他的一个方法是让客户端永远从一个备份节点中读取数据，比如客户端不再是随机从备份节点中挑一个请求，而是根据自己的id做hash选定某一个备份节点。如果这个节点崩了，再去访问其他的节点。

读取数据的前后一致性（Consistent Prefix Reads)

第三个问题是读取数据的逻辑顺序可能被破坏，想象这么一个对话场景

Mr. Poons:
你一般能预测多久的未来？  Mrs. Cake?
Mrs. Cake:
一般十秒左右,Mr. Poons.

这个对话里面有一个逻辑前后顺序，Mrs Cake 一定是听到了Mr. Poons的讯问后才会回到问题。但是如果有第三个人通过Follower在听他们的对话，可能会因为两句话不同的Follower的落后的进度不一样，所以可能会变成下面这样。原因如Figure 5-5所示

Mrs. Cake:
一般十秒左右,Mr. Poons.
Mr. Poons:
你一般能预测多久的未来？  Mrs. Cake?

我们需要另外一个种保证机制以防止这类问题的出现，读取数据的前后一致性（consistent prefix reads）。它要求读取数据的顺序必须和写入数据的顺序一样。这个在分区（partitioned）数据库中问题尤为明显，这个第6章讲。如果数据库按照写入请求的顺序处理请求，那一般不会有问题，但是分区的数据库中，不同的分区往往独立处理接收到的请求，所以针对写入请求没办法知道他在全局的顺序。这个时候逻辑前后顺序就不好搞了。

有一个方法是让这种有前后一致性问题的请求写入都发给同一个分区，但是实际操作却很难实现。这个方法也是以后会有专门一节来讲的。

更新落后的解决方案

如果你的数据库能实现最终一致，那你就要考虑如果你的备份节点落后了比较多，比如几分钟或者几小时，会不会有问题？如果是没问题，那就不用管了。如果不行，那就要考虑提供更强的保证了，比如前面讲到的读写一致。

前面也将过了，有提供更强保证的方法，比如让Leader处理特定的读请求，但是具体实现起来往往比较难且容易出错。如果能让开发者不用操心这些问题，就很爽了。事务(transactions)能帮助你搞定这个，他能够让数据库提供更强的保证，让开发者也更省心。单节点的数据库早就提供事务支持了，但是分布式系统往往就不支持了，因为这会给性能和可用性带来极大的挑战。并且他们认为前面讲到的那些问题在一个可扩展的系统中是很难避免的，能达到最终一致性就可以了。在某种程度上，他们说的对，但是想的太过于简单了，所以我们后面会有些许不同的视角来看这个问题，第7-9章还会讨论事务的内容，另外第三章还会介绍一些他的替代方案。