理论修炼之Quorum协议——分布式系统的一致性实现

1,817 阅读3分钟

这是我参与8月更文挑战的第16天,活动详情查看:8月更文挑战

  • 📢欢迎点赞 :👍 收藏 ⭐留言 📝 如有错误敬请指正,赐人玫瑰,手留余香!
  • 📢本文作者:由webmote 原创,首发于 【掘金】
  • 📢作者格言: 生活在于折腾,当你不折腾生活时,生活就开始折腾你,让我们一起加油!💪💪💪

🎏 序言

“但凡有现成的中间件或者开源库,就拿现成的用吧,不要再造轮子了。”之前公司的某同事曾经这么说过。

有现成的东西拿来用,固然轻松惬意省劲,可是当没有现成的东西或者不够合适的时候,我们也需要知道构建它的原理,甚至自己动手构建出类似的组件。

当然多学一下别人的底层思路甚至原理,遇到问题的时候,思路大开,或许就刚好恰当的解决了手中的问题。

🎏 01. Quorum的缘起?

1979年,David K. Gifford 发表了一篇《Weighted Voting for Replicated Data》的论文,详细阐述了一种被称作Quorum的算法用来保持分布式系统中复制副本的一致性。

在分布式系统中,为了保持数据的可用性,增加了更多的节点来并行处理相同的数据,并隐藏部分系统的故障。

🎏 02. Quorum的逻辑?

  • 每个拥有文件的副本节点都有投票权,总结点为 n
  • 我们设定每笔读事务收到的票数为 r,每笔写事务收到的票数为w,并且 r+w > n
  • 然后,每对读/写集的交集为非空⇒ 每次读取都会看到至少一份写入的最新值

如果我们假设r=1,w=n,那么集群就变成了WARO(Write All Read one)模式的完全副本模式,不过这个模式并不能实现高可用,因为只要其中一个节点故障,那么就会导致不能写入,只能读取。

最好的性能模式时 1<r<w<n, 就是2个读,3个写,总共4个节点。这主要是大部分的应用都是读多写少的。

🎏 03. Quorum的一般流程

image.png

这里引入了时间戳概念,记录数据的版本号,每个节点都需要自己维护。 只要达到读票数和写票数就认为成功了。内部无需再次同步。

  1. 如何读取最新的数据?在已经知道最近成功提交的时间戳的前提下,最多读r个副本就可以读到最新的数据了。

  2. 如何确定最新时间戳的数据是一个成功提交的数据?继续读其他的副本,直到读到的时间戳出现了w次。

🎏 04. Quorum的优化

上述的一般流程,大部分情况没有问题。但在数据量非常大的时候,就不太适合了。这是可以引入数据的Hash值。

  • 将Hash与数据一起存储在每台服务器上
  • 在读取操作期间返回哈希值和元数据(非数据)
  • 根据Hash进行投票
  • 确定正确的Hash后,向单个服务器查询数据对象
  • 并计算其Hash以验证数据完整性

🎏 05. 系统分析

读性能: 需要读取节点的平均响应时间; 写性能: 需要写入的节点的平均响应时间;

虽然使用Quorum协议的集群内部并不是强一致性(所有节点都写入),但其保留了高可用性。作为一个黑盒子来看待,对外达到了强一致性和高可用性的效果。

🎏 06. 小结

例行小结,理性看待!

结的是啥啊,结的是我想你点赞而不可得的寂寞。😳😳😳

👓都看到这了,还在乎点个赞吗?

👓都点赞了,还在乎一个收藏吗?

👓都收藏了,还在乎一个评论吗?