分布式架构之「 副本协议」

本文讲解下「 副本协议」,副本与副本之间的”沟通交流“是怎么规定的。

上一篇文章中介绍了分布式中数据的分布方式,有普通哈希、按数据范围,按数据量、一致性哈希、哈希桶、以及组合方式。它解决了“数据”分布的问题,是一个典型的分而治之思想的体现。本文讲解下「 副本协议」,副本与副本之间的”沟通交流“是怎么规定的。

副本协议是怎么控制副本数据的读写行为、使得副本满足一定的可用性和一致性要求。它还具有一定的对抗异常状态的容错能力,一个优秀的架构师会尽可能对异常情况进行处理。回忆下之前的文章提到异常有:网络分化、机器宕机、消息丢失、消息乱序、存储数据丢失、存储数据读出的数据错误、磁盘故障、网络不稳定以及拥塞。

从CAP定理得出,想要在分布架构中设计一个满足强一致性,且出现网络异常时都可用的副本协议是不可能。实际的副本协议总是在可用性、一致性与性能等要素之间妥协折中。

中心化副本协议

中心化副本协议的基本思路是由一个中心节点协调副本数据的更新、维护副本之间的一致性。现实生活中很多机构部门都有中心节点的影子存在,可以参考对比下。中心化副本控制协议的优点是协议相对简单,所有副本的控制权都在中心节点。并发控制也在中心节点完成,从而使得一个分布式并发控制问题,简化为一个单机并发控制问题。这里的并发控制是指多个节点同时操作副本数据,解决”写写“、”读写“等并发冲突造成的脏数据。单机系统常用加锁进行并发控制。分布式并发控制,如果没有一个中心节点统一进行锁管理(转为单机进行管理),实现一个完全分布式的锁系统,会使得协议非常复杂。

中心化副本控制协议的缺点是系统的可用性依赖于中心化节点,当中心节点异常或中心节点通信中断时,系统将失去某些服务(通常失去更新服务),所以中心化副本控制协议的缺点是存在一定的停服务时间。

分布式架构之「 副本协议」

0、primary-backup协议
主备协议也叫主从协议,从是主的backup,这里的backup一般多为热备。通常是需要承担一部分读数据操作。它是一种非常常用的中心化副本控制协议。应用场景:MySQL一主多从、MongoDB一主多从、Redis一主两从、HDFS主从架构。通常仅有一个副本作为primary副本,除primary以为的副本都为backup副本。primary副本所在的节点称为中心节点,primary-backup类型的协议一般要解决四大类问题:数据更新流程、数据读取方式、primary副本的确定和切换、数据同步。

1、数据更新基本流程

  • 数据更新都由primary节点协调完成
  • 外部节点将更新操作发给primary节点
  • primary节点进行并发控制即确定并发更新操作的先后顺序
  • primary节点将更新操作发送给backup节点
  • primary根据backup节点的完成情况决定更新是否成功并将结果返回外部节点

分布式架构之「 副本协议」

其中第4步primary节点将更新操作发给backup节点,发送的也是更新数据。工程实践中,如果primary直接同时发送给其他N个副本数据,则每个backup的更新吞吐受限于primary总的出口网络带宽。每个backup最大为primary网络出口带宽的1/N。为了解决这个问题,像GFS使用接力的方式同步数据,primary将更新发送给第一个backup副本,第一个backup副本在发送给第二个backup,依次往下。由于网络异常的不可避免,第4步的更新操作可能在有些副本上成功,有些副本上失败,在有些副本上超时。对数据一致性要求不同的副本控制协议对异常处理不同。提供最终一致性服务的系统中,backup节点可以与primary不一致,只要后续backup节点可以慢慢同步到与primary一致的状态即可满足最终一致性的要求。

2、数据读取方式

与数据更新流程类似,读取方式也与一致性高度相关。如果只需要最终一致性,则读取任意副本都可以满足需求。如果需要会话一致性,则可以为副本设置版本号,每次更新后递增版本号,用户读取副本时验证版本号,从而保证与读取到的数据在会话范围内单调递增。使用primary-backup比较困难的是实现强一致性

这里简单讨论下primary-backup实现强一致性的几种思路。

  • 数据更新流程都是通过primary控制的,primary副本上数据一定是最新的,始终只读primary副本的数据。实践中,如果副本中数据分布不与机器绑定,而是按照数据段为单位维护副本,仅有primary副本提供读服务在很多场景下不会造成机器资源浪费。每台机器上有一些数据的primary副本,也有一些数据段的backup副本。
  • primary控制节点backup节点的可用性。当primary更新某个backup副本不成功时,primary将该backup副本标记为不可用。从而用户不再读取不可用的副本。不可用的副本可以继续尝试与primary同步数据,当与primary完成数据同步后,则该backup副本标记为可用。这样使得所有可用的副本都是可读的。标记的数据需要依赖一个中心元数据管理系统,记录副本可用、不可用状态。其实是通过降低系统的可用性来提高系统的一致性。实际的副本协议总是在可用性、一致性与性能等要素之间妥协折中。

3、primaty副本的确定与切换

如何确定primary副本,尤其是在原primary副本所在的机器出现宕机等异常时,需要某种机制切换primary副本,使得某个backup副本成为新的副本。哪个副本是primary这一信息都属于元信息,由专门的元数据服务器维护。

切换副本难点在于两个方面,其一:如何确定节点的状态以发现原primary节点异常。下一篇文章我们介绍基于Lease机制确定节点状态的方法。 其二:切换primary后,不能影响副本的一致性。尤其是提供强一致性服务的系统,切换的新primary的副本必须和原primary的副本一致。如何在原primary发送宕机异常时,如何确定一个顶替的副本是与原primary副本上的数据一致。后面我们会介绍Quorum机制确定新primary的方法。

确定发现primary副本的异常是需要一定探测时间的,通常是10秒级别,意味着在确定期间内,没有primary,系统不能提供primary的更新服务、读服务。primary-backup类副本的最大缺点就是primary的切换带来一定的停服务时间

4、数据同步

primary-backup类型协议都会遇到backup副本与primary不一致的问题。不一致的backup副本需要与primary进行同步。

异常造成的不一致形式有三种:

  • 网络分化等异常,backup上的数据落后于primary上的数据

    • 回放primary上的操作日志(通常是redo日志),追赶上primary的更新进度
  • 某些协议下,backup上的数据有可能是脏数据,需要被丢弃

    • 设计的分布式协议不产生脏数据,或者降低产生脏数据的概率到非常低
    • 丢弃有脏数据的副本,backup副本完全没有数据就可以直接拷贝primary,被拷贝的primary得继续服务,就要求primary副本支持快照功能,对某一刻的副本数据形成快照,拷贝快照后使用回放日志方式追赶快照后的更新操作
    • 基于undo日志的方式回退从而删除脏数据
  • backup是一个新增加的副本,完全没有数据,需要从其他副本上拷贝数据

去中心化副本协议

去中心化副本控制是另一种较为复杂的副本控制协议。去中心化副本控制协议是没有中心节点,协议中所有的节点都是完全对等的,节点之间通过平等协商达到一致。不会因为中心化节点异常带来停服务的问题。去中心化协议最大的缺点就是协议过程比较复杂。尤其当去中心化协议要实现强一致性的时候,协议流程变得复杂且不容易理解。由于流程的复杂,去中心化协议的效率或者性能一般比中心化协议低。一个不恰当的比方是,中心化副本控制协议类似专制制度,效率高但高度依赖于中心节点,一旦中心节点异常,系统就会出现不可用。去中心化副本控制协议类似民主制度,节点集体协议,效率低但个别节点的异常不会造成不可用。副本协议总是在可用性、一致性与性能等要素之间妥协折中。

分布式架构之「 副本协议」

后面我们会讲强一致性去中心化副本控制协议paxos。

工程投影

primary-backup

去中心化

参考资料:《分布式系统原理介绍》作者:刘杰

相关文章

感觉本篇文章不错,对你有收获?

¥我要小额赞助,鼓励作者写出更好的教程
80 160 120

作者:

  • 出处: https://www.mi360.cn/articles/178
  • 本文版权归作者,欢迎转载,但未经作者同意必须保留 此段声明,且在文章页面明显位置给出原文连接,否则保留追究法律责任的权利。

评论区

最新评论

扫码关注