Kafka设计解析（二）- Kafka High Availability （上）(8/8)

本篇文章主要介绍了"Kafka设计解析（二）- Kafka High Availability （上）"，主要涉及到ability,kafka方面的内容，对于软件工程感兴趣的同学可以参考一下： 摘要　　Kafka在0.8以前的版本中，并不提供High Availablity机制，一旦一个或多个Broker宕机，则宕机期间其上所有Partition都无法...

1
2
3
4
5
6
7
8
9
10
11

Schema:
{ "fields":
    [ {"name": "version", "type": "int", "doc": "version id"},
      {"name": "brokerid", "type": "int", "doc": "broker id of the controller"}
    ]
}
Example:
{
    "version":1,
　　"brokerid":8
}

/controller_epoch -> int (epoch)直接以整数形式存储controller epoch，而非像其它znode一样以JSON字符串形式存储。 　　 　　

broker failover过程简介

1. Controller在Zookeeper注册Watch，一旦有Broker宕机（这是用宕机代表任何让系统认为其die的情景，包括但不限于机器断电，网络不可用，GC导致的Stop The World，进程crash等），其在Zookeeper对应的znode会自动被删除，Zookeeper会fire Controller注册的watch，Controller读取最新的幸存的Broker
2. Controller决定set_p，该集合包含了宕机的所有Broker上的所有Partition
3. 对set_p中的每一个Partition
   　　3.1 从/brokers/topics/[topic]/partitions/[partition]/state读取该Partition当前的ISR
   　　3.2 决定该Partition的新Leader。如果当前ISR中有至少一个Replica还幸存，则选择其中一个作为新Leader，新的ISR则包含当前ISR中所有幸存的Replica。否则选择该Partition中任意一个幸存的Replica作为新的Leader以及ISR（该场景下可能会有潜在的数据丢失）。如果该Partition的所有Replica都宕机了，则将新的Leader设置为-1。
   　　　3.3 将新的Leader，ISR和新的leader_epoch及controller_epoch写入/brokers/topics/[topic]/partitions/[partition]/state。注意，该操作只有其version在3.1至3.3的过程中无变化时才会执行，否则跳转到3.1
4. 直接通过RPC向set_p相关的Broker发送LeaderAndISRRequest命令。Controller可以在一个RPC操作中发送多个命令从而提高效率。
   　　Broker failover顺序图如下所示。
   

以上就介绍了Kafka设计解析（二）- Kafka High Availability （上），包括了ability,kafka方面的内容，希望对软件工程有兴趣的朋友有所帮助。

本文网址链接：http://www.codes51.com/article/detail_1013585_8.html