大数据技术系列----副本更新策略

副本更新策略

通常情况，大规模分布式存储系统会将一份数据在系统内复制多份并保存在不同的存储。一方面可以通过数据冗余来增加系统的可用性，另一方面也可以增加读操作的并发程度。在多副本的情况下，有3种可能的更新策略：同时更新策略、主从式更新策略和任意节点更新策略。

同时更新

多副本更新主要有以下2种情形：

类型1：不通过一致性协议

不通过任何一致性协议直接同时更新多个副本数据。这种情形存在法硕的数据一致性问题：如果同一时刻两个不同的客户端对这个数据同时发出update1和update2更新请求，那么系统会无法确定其执行顺序，这样会在有的副本中，执行顺序是update1–>update2；而在有的副本中，执行顺序是update2–>update1。

类型2：一致性协议预先处理

通过某种一致性协议来预先处理，这种处理可以用来唯一确定不同更新操作的顺序。这样可以保证数据的一致性，但是由于协议本身会有处理成本，从而会增加请求延时。

主从式更新策略

如果在多个副本中有一个主副本，其他副本为从副本，这种情况下称为主从式更新策略。所有对这个数据的更新操作会首先提交到主副本，再由主副本通知从副本进行数据更新。如果有多个数据更新操作需要处理，主副本会决定不同更新操作的执行顺序，其他从副本也遵循主副本的更新顺序。根据主副本通知从副本的不同机制，可以分为三种类型：

类型1：同步方式

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

类型2：异步方式

主副本通知从副本更新之前即可确认更新操作。这种情况下，如果主副本还没有通知其他从副本就发生崩溃，那么就会影响到数据的一致性，所以一般会先在另外的可靠存储位置将这次更新操作记录下来，以免发生意外。

在异步方式中，如何权衡请求延时和数据一致性取决于对读操作的响应方式，根据读操作的响应方式，可以分为如下2种情况：

1. 如果所有读请求都必须通过主副本来响应，也就是说，任何一个从副本在接收到读请求后都要将该请求转发给主副本。这种情况下数据的一致性可以保障，但是无疑会增加请求延时。因为当一个客户端发出读操作请求时，原本可以由距离这个客户端最近的从副本响应请求，现在则需要将这个请求转发给距离较远的主副本。

2. 如果任意一个从副本都可以响应请求，这种情况下会降低延时，但是数据一致性无法保证，因为有些副本还可能存在着旧版本的数据信息。

类型3：混合方式

也可采用同步、异步混合的方式：主副本先同步更新部分从副本数据，然后即可确认更新操作完成，其他副本通过异步方式进行更新。在这种情况下，请求延时和数据一致性之间的权衡也取决于读操作的响应方式：

1. 如果一个读操作的数据至少要从一个同步更新的节点中读出，则强一致性可以获得保证，但与此同时请求延时会增加，因为不管两步方式还是异步方式，请求延时都会发生，而由于其涉及的节点少于单一的同步方式和异步方式，所以延时的问题没有那么严重。

2. 如果读操作不要求一定要从至少一个同步更新节点读出，那么会出现异步方式下第2种情况中的数据不一致问题。

任意节点更新策略

客户端的数据更新请求可能会发给多副本中的任意一个节点，由这个节点负责通知其他节点进行数据更新，这种方式与“主从式更新”的区别是：对于数据的更新操作请求，并不存在某个指定的首先进行响应的主副本，而是任意一个节点都可以进行响应。它的特殊性在于：在同一时刻，有两个不同的客户端对同一数据进行更新操作请求，而此时有可能有两个不同的副本各自响应。

这种方式下的请求延时和数据一致性之间的权衡也有2种情况：

类型1：同步通知其他副本

这种情况与”主从式更新”中的类型1相似。此外，为了识别出是否存在客户端同时更新不同副本的情况，还需要付出更多的请求延时。

类型2：异步通知其他副本

这种情况与”同时更新策略”及”主从式更新策略”的类型2相似。

正常情况下，”主从式更新”的类型3发挥作用，而当主副本发生故障时，”任意节点更新策略”发挥作用。

-_________________________________________________

Standing on shoulders of Giants