【Kafka集群架构设计原理】

一、Kafka的Zookeeper元数据梳理

1、zookeeper整体数据
Kafka将状态信息保存在Zookeeper中，这些状态信息记录了每个Kafka的Broker服务与另外的Broker服务
有什么不同。通过这些差异化的功能，共同体现出集群化的业务能力。这些数据，需要在集群中各个Broker
之间达成共识，因此，需要存储在一个所有集群都能共同访问的第三方存储中。
2、Controller Broker选举机制
在Kafka集群进行工作之前，需要选举出一个Broker来担任Controller角色，负责整体管理集群内的分区和
副本状态。选举Controller的过程就是通过抢占Zookeeper的/controller节点来实现的。
3、Leader Partition选举机制
在Kafka中，一个Topic下的所有消息，是分开存储在不同的Partition中的。在使用kafka-topics.sh脚本创
建Topic时，可以通过–partitions 参数指定Topic下包含多少个Partition，还可以通过–replication-factors参
数指定每个Partition有几个备份。而在一个Partition的众多备份中，需要选举出一个Leader Partition，负责
对接所有的客户端请求，并将消息优先保存，然后再通知其他Follower Partition来同步消息。
4、Leader Partition自动平衡机制
在一组Partiton中，Leader Partition通常是比较繁忙的节点，因为他要负责与客户端的数据交互，以及向
Follower同步数据。默认情况下，Kafka会尽量将Leader Partition分配到不同的Broker节点上，用以保证
整个集群的性能压力能够比较平均。
5、Partition故障恢复机制
Kafka设计时要面对的就是各种不稳定的网络以及服务环境。如果Broker的服务不稳定，随时崩溃，Kafka
集群要怎么保证数据安全呢？
当一组Partition中选举出了一个Leader节点后，这个Leader节点就会优先写入并保存Producer传递过来
的消息，然后再同步给其他Follower。当Leader Partition所在的Broker服务发生宕机时，Kafka就会触发
Leader Partition的重新选举。但是，在选举过程中，原来Partition上的数据是如何处理的呢？
Kafka为了保证消息能够在多个Parititon中保持数据同步，内部记录了两个关键的数据：
LEO(Log End Offset): 每个Partition的最后一个Offset
这个参数比较好理解，每个Partition都会记录自己保存的消息偏移量。leader partition收到并记录了生产
者发送的一条消息，就将LEO加1。而接下来，follower partition需要从leader partition同步消息，每同步
到一个消息，自己的LEO就加1。通过LEO值，就知道各个follower partition与leader partition之间的消息
差距。
HW(High Watermark): 一组Partiton中最小的LEO。
follower partition每次往leader partition同步消息时，都会同步自己的LEO给leader partition。这样
leader partition就可以计算出这个HW值，并最终会同步给各个follower partition。leader partition认为这
个HW值以前的消息，都是在所有follower partition之间完成了同步的，是安全的。这些安全的消息就可以
被消费者拉取过去了。而HW值之后的消息，就是不安全的，是可能丢失的。这些消息如果被消费者拉取过
去消费了，就有可能造成数据不一致。