前言
为什么自己要整理博客和学习笔记呢？是想把知识系统的，有条理的归纳在一起~
而且一个东西的完成，也很有成就感，还可以打卡某一个知识点。
标红可以快速回忆自己整理过的知识~
ZooKeeper是什么？
一个典型的分布式数据一致性解决方案，分布式应用程序可以基于 ZooKeeper 实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知、集群管理、Master 选举、分布式锁和分布式队列等功能。
kafka中的zookeeper~
Kafka严重依赖于ZooKeeper集群。所有的broker在启动的时候都会往zookeeper进行注册，目的就是选举出一个controller，controller会读取注册上来的从节点的数据（通过监听机制），生成集群的元数据信息，之后把这些信息都分发给其他的服务器，让其他服务器能感知到集群中其它成员的存在 。通过这个方法让整个集群都得知这个分区方案，此时从节点就各自创建好目录等待创建分区副本即可。这也是整个集群的管理机制。
(zookeeper 其实主要的存在意义就是给集群的管理机制上面，做保证。 都注册到zk，这样就可以相互发现了)
zookeeper有什么缺点？
实际上，问题不在于ZooKeeper本身，而在于外部元数据管理的概念上。
ZooKeeper中的数据也需要反映在Kafka控制器上，这会导致双重缓存。
当Kafka集群启动的controller时，controller必须从ZooKeeper加载集群的完整状态。随着数据量的增加，此加载过程的时间也随之增加。
最后，将数据存储在外部会增加controller的内存与外部状态不同步的可能性。
（zookeeper是可靠的！不容易挂的）
kafka已经取消了依赖zookeeper
Apache启动了一个KIP-500的项目，将Kafka的元数据存储在Kafka本身中，而不是存储在ZooKeeper之类的外部系统中。将controller作为分区的负责人。
KIP-500将加快topic的创建和删除。当前，创建或删除topic时，controller必须从ZooKeeper重新加载集群中所有topic名称的完整列表，因为当集群中的主题集发生更改时，当ZooKeeper通知我们时，它并不能准确告诉我们添加或删除了哪些主题。在KIP-500的设计中，创建或删除topic将仅涉及在元数据分区中创建新条目，复杂度仅为O(1)。元数据可伸缩性是将来扩展Kafka的关键部分。Apache期望单个Kafka集群最终将能够支持一百万个分区或更多。
最新版的Kafka 2.8.0，移除了对Zookeeper的依赖，通过KRaft进行自己的集群管理。
2.8以上版本是怎么做的？
https://cloud.tencent.com/developer/article/1820099
概述：Kafka使用内嵌的KRaft替代了ZooKeeper，是一个非常大的进步，因为像ES之类的分布式系统，这种集群meta信息的同步，都是自循环的。
KRaft，我们就想到了Raft协议。Raft协议是当今最流行的分布式协调算法，Etcd、Consul等系统的基础，就来自于此。现在Kafka也有了。
由于这个功能太新了，所以2.8.0版本默认还是要用ZooKeeper的，但并不妨碍我们尝尝鲜。
kafka又加了一个内部主题，叫做@metadata，用来存这些元信息。
为什么要干掉ZK？（这也是kafka的主要缺点）
Kafka作为一个消息队列，竟然要依赖一个重量级的协调系统ZooKeeper，不得不说是一个笑话。同样作为消息队列，人家RabbitMQ早早的就实现了自我管理。
Zookeeper非常笨重，还要求奇数个节点的集群配置，扩容和缩容也不方便。Zk的配置方式，也和kafka的完全不一样，要按照调优Kafka，竟然还要兼顾另外一个系统。
Kafka要想往轻量级，开箱即用的方向发展，就不得不干掉Zk。
另外，由于Zk和Kafka毕竟不是在一个存储体系里面，当Topic和Partition的数量上了规模，数据同步问题就变的显著起来。Zk是可靠，但是它慢啊，完全不如放在Kafka的日志存储体系里面，这对标榜速度的Kafka来说，是不得不绕过的一环。
Kafka-admin，它需要先从zk上转一圈，获取一些元数据信息，然后再从Kafka的JMX接口中拉取数据。
（熟悉kafka的大哥说，kakfa主要的缺点就是扩容和锁绒不方便）
kafka的controller是什么？
控制器组件（Controller），是 Apache Kafka 的核心组件。它的主要作用是在 Apache ZooKeeper 的帮助下管理和协调整个 Kafka 集群。集群中任意一台 Broker 都能充当控制器的角色，但是，在运行过程中，只能有一个 Broker 成为控制器，行使其管理和协调的职责。
1. 什么是Controller Broker
在分布式系统中，通常需要有一个协调者，该协调者会在分布式系统发生异常时发挥特殊的作用。在Kafka中该协调者称之为控制器(Controller),其实该控制器并没有什么特殊之处，它本身也是一个普通的Broker，只不过需要负责一些额外的工作(追踪集群中的其他Broker，并在合适的时候处理新加入的和失败的Broker节点、Rebalance分区、分配新的leader分区等)。值得注意的是：Kafka集群中始终只有一个Controller Broker。
（这边的reblance 还是需要好好看看的，记个todo）
2. Controller Broker是如何被选出来的
当集群启动后，Kafka 怎么确认控制器位于哪台 Broker 呢？
实际上，Broker 在启动时，会尝试去 ZooKeeper 中创建 /controller 节点。Kafka 当前选举控制器的规则是：第一个成功创建 /controller 节点的 Broker 会被指定为控制器。
3. Controller Broker的具体作用是什么
Controller Broker的主要职责有很多，主要是一些管理行为，主要包括以下几个方面：
- 创建、删除主题，增加分区并分配leader分区
- 集群Broker管理（新增 Broker、Broker 主动关闭、Broker 故障)
- preferred leader选举
- 分区重分配
3.1 处理集群中下线的Broker
当某个Broker节点由于故障离开Kafka群集时，则存在于该Broker的leader分区将不可用(由于客户端仅对leader分区进行读写操作)。为了最大程度地减少停机时间，需要快速找到替代的leader分区。（副本是不会进行读写的，知识作为备份）
Controller Broker可以对失败的Broker做出响应，Controller Broker可以从Zookeeper监听(zookeeper watch)中获取通知信息，ZooKeeper 赋予客户端监控 znode 变更的能力，即所谓的 Watch 通知功能。一旦 znode 节点被创建、删除，子节点数量发生变化，或是 znode 所存的数据本身变更，ZooKeeper 会通过节点变更监听器 (ChangeHandler) 的方式显式通知客户端。
每个 Broker 启动后，会在zookeeper的 /Brokers/ids 下创建一个临时 znode。当 Broker 宕机或主动关闭后，该 Broker 与 ZooKeeper 的会话结束，这个 znode 会被自动删除。同理，ZooKeeper 的 Watch 机制将这一变更推送给控制器，这样控制器就能知道有 Broker 关闭或宕机了，从而进行后续的协调操作。
Controller将收到通知并对此采取行动，决定哪些Broker上的分区成为leader分区（我印象中，kafka的副本机制都是很分散的，所以选择别的broker分区上面的副本当成主leader），然后，它会通知每个相关的Broker，要么将Broker上的主题分区变成leader，要么通过LeaderAndIsr请求从新的leader分区中复制数据。
3.2 处理新加入到集群中的Broker
正因为：
通过将Leader分区副本均匀地分布在集群的不同Broker上，可以保障集群的负载均衡。
（kafka的负载均衡是很均衡的~）
在Broker发生故障时，某些Broker上的分区副本会被选举为leader，会造成一个Broker上存在多个leader分区副本的情况，由于客户端只与leader分区副本交互，所以这会给Broker增加额外的负担，并损害集群的性能和运行状况。因此，尽快恢复平衡对集群的健康运行是有益的。
（虽然可以这样，但是还是尽量均衡读写，都在一个broker上面进行读写压力很大~）
Kafka认为leader分区副本最初的分配（每个节点都处于活跃状态）是均衡的。这些被最初选中的分区副本就是所谓的首选领导者(preferred leaders)。由于Kafka还支持机架感知的leader选举(rack-aware leader election) ,即尝试将leader分区和follower分区放置在不同的机架上，以增加对机架故障的容错能力。因此，leader分区副本的存在位置会对集群的可靠性产生影响。
默认情况下auto.leader.rebalance.enabled为true，表示允许 Kafka 定期地对一些 Topic 分区进行
Leader 重选举。大部分情况下，Broker的失败很短暂，这意味着Broker通常会在短时间内恢复。所以当节点离开群集时，与其相关联的元数据并不会被立即删除。
当Controller注意到Broker已加入集群时，它将使用Broker ID来检查该Broker上是否存在分区，如果存在，则Controller通知新加入的Broker和现有的Broker，新的Broker上面的follower分区再次开始复制现有leader分区的消息。为了保证负载均衡，Controller会将新加入的Broker上的follower分区选举为leader分区。
注意：上面提到的选Leader分区，严格意义上是换Leader分区，为了达到负载均衡，可能会造成原来正常的Leader分区被强行变为follower分区。换一次 Leader 代价是很高的，原本向 Leader分区A(原Leader分区) 发送请求的所有客户端都要切换成向 B (新的Leader分区)发送请求，建议你在生产环境中把这个参数设置成 false。
3.3 同步副本(in-sync replica?,ISR)列表
ISR中的副本都是与Leader进行同步的副本，所以不在该列表的follower会被认为与Leader是不同步的.
那么，ISR中存在是什么副本呢？首先可以明确的是：Leader副本总是存在于ISR中。而follower副本是否在ISR中，取决于该follower副本是否与Leader副本保持了“同步”。
始终保证拥有足够数量的同步副本是非常重要的。要将follower提升为Leader，它必须存在于同步副本列表中。每个分区都有一个同步副本列表，该列表由Leader分区和Controller进行更新。
选择一个同步副本列表中的分区作为leader 分区的过程称为clean leader election。注意，这里要与在非同步副本中选一个分区作为leader分区的过程区分开，在非同步副本中选一个分区作为leader的过程称之为unclean leader election。
（上面这句话怎么理解？ 就是下面的，因为isr有可能为空）
由于ISR是动态调整的，所以会存在ISR列表为空的情况，通常来说，非同步副本落后 Leader 太多，因此，如果选择这些副本作为新 Leader，就可能出现数据的丢失。毕竟，这些副本中保存的消息远远落后于老 Leader 中的消息。在 Kafka 中，选举这种副本的过程可以通过Broker 端参数 **unclean.leader.election.enable **控制是否允许 Unclean 领导者选举。开启 Unclean 领导者选举可能会造成数据丢失，但好处是，它使得分区 Leader 副本一直存在，不至于停止对外提供服务，因此提升了高可用性。反之，禁止 Unclean Leader 选举的好处在于维护了数据的一致性，避免了消息丢失，但牺牲了高可用性。分布式系统的CAP理论说的就是这种情况。
不幸的是，unclean leader election的选举过程仍可能会造成数据的不一致，因为同步副本并不是完全同步的。由于复制是异步完成的，因此无法保证follower可以获取最新消息。比如Leader分区的最后一条消息的offset是100，此时副本的offset可能不是100，这受到两个参数的影响：
- replica.lag.time.max.ms：同步副本滞后与leader副本的时间
- zookeeper.session.timeout.ms：与zookeeper会话超时时间
3.4 脑裂
如果controller Broker 挂掉了，Kafka集群必须找到可以替代的controller，集群将不能正常运转。这里面存在一个问题，很难确定Broker是挂掉了，还是仅仅只是短暂性的故障。但是，集群为了正常运转，必须选出新的controller。如果之前被取代的controller又正常了，他并不知道自己已经被取代了，那么此时集群中会出现两台controller。
broker不知道它暂停了，它充当当前的controller，但是集群又选了新的controller。这种叫做脑裂。
假如，处于活跃状态的controller进入了长时间的GC暂停。它的ZooKeeper会话过期了，之前注册的/controller节点被删除。集群中其他Broker会收到zookeeper的这一通知。
有点意思啊：
由于集群中必须存在一个controller Broker，所以现在每个Broker都试图尝试成为新的controller。假设Broker 2速度比较快，成为了最新的controller Broker。此时，每个Broker会收到Broker2成为新的controller的通知，由于Broker3正在进行"stop the world"的GC，可能不会收到Broker2成为最新的controller的通知。
等到Broker3的GC完成之后，仍会认为自己是集群的controller，在Broker3的眼中好像什么都没有发生一样。
现在，集群中出现了两个controller，它们可能一起发出具有冲突的命令，就会出现脑裂的现象。如果对这种情况不加以处理，可能会导致严重的不一致。所以需要一种方法来区分谁是集群当前最新的Controller。
Kafka是通过使用epoch number（纪元编号，也称为隔离令牌）来完成的。epoch number只是单调递增的数字，第一次选出Controller时，epoch number值为1，如果再次选出新的Controller，则epoch number将为2，依次单调递增。
每个新选出的controller通过Zookeeper 的条件递增操作获得一个全新的、数值更大的epoch number 。其他Broker 在知道当前epoch number 后，如果收到由controller发出的包含较旧(较小)epoch number的消息，就会忽略它们，即Broker根据最大的epoch number来区分当前最新的controller。
可以区分最新的controller~
kafka一般没怎么听说有脑裂的问题，因为做了优化吧（问的大哥）
所以：
上图，Broker3向Broker1发出命令:让Broker1上的某个分区副本成为leader，该消息的epoch number值为1。于此同时，Broker2也向Broker1发送了相同的命令，不同的是，该消息的epoch number值为2，此时Broker1只听从Broker2的命令(由于其epoch number较大)，会忽略Broker3的命令，从而避免脑裂的发生。
kafka 的reblance的意义？
为了让消费端更加均衡（后面单独刷一下）
参考：
Kafka即将移除Zookeeper依赖?：?https://zhuanlan.zhihu.com/p/147578138
帅呆了！Kafka移除了Zookeeper！：https://cloud.tencent.com/developer/article/1820099
Kafka的Controller Broker是什么?：https://zhuanlan.zhihu.com/p/165989024
以上如果有侵权，请私信我进行删除。
本文仅用于学习&笔记目的，不用于任何商业用途。