apache kafka系列之replication设计机制

apache kafka中国社区QQ群:162272557

概览:

其中一个broker被选举作为整个集群控制器，他将负责几个方面工作：

1.管理或领导分区变化.

2.create topic,delete topic

3.replicas(执行复制计划，复制partition)

集群控制器做出决定以后，操作信息或状态将永久注册并存储在zookeeper上，并且也可以通过RPC方式发送新的决定操作broker。控制器发布的决定来源真实，他将用于client请求路由和broker的重启或恢复状态。

如果有一个新的broker加入或启动。controller会通过RPC调用发出新的决定。

潜在的优点：

1.当leader发生变化时，更容易集中到一个地方做调试(排除故障)。

2.当leader发生变化时，ZK可以把读取/写状态信息成批广播到其他broker，因此当leader failover的时候会减少broker之间恢复的延迟时间。

3.需要更少的监听器。

4.使用更高效的RPC通信方式，代替在zookeeper中队列实现方式。

潜在的缺点：

需要考虑controller failover

zookeeper中路径列表说明

1.Controller path:存储当前controller信息.

2.Broker path:存储当前所有活着的brokers信息。

3.存储一个主题的所有分区副本任务。对于每一个副本，我们存储的副本指派一个broker ID。第一个副本是首选的复制品。注意，对于一个给定的分区，在一个broker上有至多一个副本。因此，broker ID可以作副本标识.

4.LeaderAndISR path:存储一个分区leader and ISR

5.分区分配path：当我们重新分配某些分区到不同的brokers时，此path会被使用。对于每个分区重新分配，他将会存储一个新副本列表和他们相应的brokers信息。

每当某个管理员操作如下命令成功后，且这个分区迁移到目标broker成功后，源broker上的分区会自动删除。

kafka中专有词语解释：

AR(assign replicas):分配副本 ISR(in-sync replicas)：在同步中的副本

请注明转载自: http://blog.csdn.net/lizhitao/article/details/24491551
后续.....