副本更新策略

分布式理论系列

序

本文主要摘要了一些主要的副本更新策略。

多个副本之间存在一个主副本（Master Replica），其他副本为从副本，这种称为主从更新策略。所有对数据的更新首先提交到主副本，再由主副本通知从副本进行数据更新。如果同时产生多个数据更新操作，由主副本决定不同更新操作的顺序。

主副本等待所有从副本更新完成之后才确认更新操作完成，这样确保数据的强一致性，但是会存在较大的请求延时，尤其是在多副本跨数据中心的情形下，因为请求延时取决于最慢的那个副本的更新速度。

主副本在通知从副本更新之前即可确认更新操作。假设主副本还没有通知任何其他从副本就发生崩溃，那么数据一致性可能会出现问题，一般首先在另外的可靠存储位置将这次更新操作记录下来，以防这种情况发生。

1）所有读请求都通过主副本来响应，任意一个副本接收到读请求后转发为主副本，可以保证强一致，但是本来可以由距离近的副本响应的操作又得转发给距离较远的主副本，增加了请求延时，Google的Chubby采用这种方式。
2）任意一个副本都可以响应读请求，请求延时大大降低，但是可能导致读不一致，因为有些副本可能还存在旧版本的数据，Zookeeper就是采用这种方法获得低延时，但牺牲了一致性。

同步混合异步，主副本首先同步更新部分从副本，然后确认更新操作完成，其他副本通关异步方式获得更新，Kafka就是采用这种混合方式来维护数据副本的不一致性。

不区分主从副本，任意节点都可以接收请求，然后又它去通知其他副本进行更新。

存在和主从更新的类型A的情况，除此之外，为了识别出是否存在不同客户端向不同副本发送对同一数据的更新操作，还需要额外付出更多的请求延时

存在主从更新的B方式问题。

Dynamo/Cassandra/Riak同时采取了主从式更新的类型C（同步+异步），以及任意节点更新的策略。