最近在写 kafka 的文章,发现一个有趣的东西分享一下
一种非常常用的选举 leader 的方式是“ Majority Vote ”(“少数服从多数”),但 Kafka 并未采用这种方式。这种模式下,如果我们有 2f+1 个 Replica (包含 Leader 和 Follower ),那在 commit 之前必须保证有 f+1 个 Replica 复制完消息,为了保证正确选出新的 Leader,fail 的 Replica 不能超过 f 个。因为在剩下的任意 f+1 个 Replica 里,至少有一个 Replica 包含有最新的所有消息。这种方式有个很大的优势,系统的 latency 只取决于最快的几个 Broker,而非最慢那个。Majority Vote 也有一些劣势,为了保证 Leader Election 的正常进行,它所能容忍的 fail 的 follower 个数比较少。如果要容忍 1 个 follower 挂掉,必须要有 3 个以上的 Replica,如果要容忍 2 个 Follower 挂掉,必须要有 5 个以上的 Replica。也就是说,在生产环境下为了保证较高的容错程度,必须要有大量的 Replica,而大量的 Replica 又会在大数据量下导致性能的急剧下降。这就是这种算法更多用在 ZooKeeper 这种共享集群配置的系统中而很少在需要存储大量数据的系统中使用的原因。例如 HDFS 的 HA Feature 是基于 majority-vote-based journal,但是它的数据存储并没有使用这种方式。
看完有没有觉得大多数选举就是民主制度. 而 Kafka 这种就是封建独裁皇帝制度
大多数选举是假设手下这批人都心怀鬼胎, 老大死了之后, 大多数和自己一样思想的人依然掌握大权. 而封建独裁是皇帝活着的时候,维护了一个皇子池,保证这些皇子池里的皇子思想和自己一样, 自己死了, 随便选个皇子就行.反正都是影子.
这么看来 kafka 是维护代价高,但是不需要太多皇子, 而大多数选举需要大量的和自己一样的人,但是不需要拼命维持他们的思想一致.
这么看来, 随着节点的觉醒. 强制的维护思想一致是不靠谱的, 还得是潜移默化的影响大多数人.所以,,,,其实没差别手段不同而已.
这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。
V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。
V2EX is a community of developers, designers and creative people.