最近在写 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 是维护代价高,但是不需要太多皇子, 而大多数选举需要大量的和自己一样的人,但是不需要拼命维持他们的思想一致.
这么看来, 随着节点的觉醒. 强制的维护思想一致是不靠谱的, 还得是潜移默化的影响大多数人.所以,,,,其实没差别手段不同而已.
1
ClutchBear 2018-11-29 18:19:13 +08:00
其实按照正统马克思 5 段轮, 封建是不独裁的, 而且只适用于西欧.
欧洲历史的封建跟我们现在所说的封建是两回事. 中国现在所说的 5 段轮是斯大林强推的全世界的. |
2
misaka19000 2018-11-29 18:23:02 +08:00
所以 kafka 道理用了哪种模式?在摘抄的部分没能看出来
|
3
petelin OP @misaka19000 皇子池, in-sync replicas.
|
4
misaka19000 2018-11-29 18:47:13 +08:00
> 最简单最直观的方案是,所有 Follower 都在 ZooKeeper 上设置一个 Watch,一旦 Leader 宕机,其对应的 ephemeral znode 会自动删除,此时所有 Follower 都尝试创建该节点,而创建成功者( ZooKeeper 保证只有一个能创建成功)即是新的 Leader,其它 Replica 即为 Follower。
是这段吧,这个其实很分布式锁很像啊 |
5
petelin OP @misaka19000 嗯, 一开始是这样的, 架构在 zookeeper 上,可不就是用了人家的锁嘛. 后来改成一个 controler 来干这件事了. 但是本质还是维护一个同步的列表.
|