【Kafka中的leader选举】

Kafak 集群中leader选举

一、Kafka介绍

———— Kafka是最初由Linkedin公司开发，是一个分布式、支持分区的（partition）、多副本的 （replica），基于zookeeper协调的分布式消息系统，它的最大的特性就是可以实时的处理 大量数据以满足各种需求场景：比如基于hadoop的批处理系统、低延迟的实时系统、 Storm/Spark流式处理引擎，web/nginx日志、访问日志，消息服务等等，用scala语言编 写，Linkedin于 2010 年贡献给了Apache基金会并成为顶级开源 项目。

1.Kafka的使用场景

————-日志收集：一个公司可以用Kafka收集各种服务的log，通过kafka以统一接口服务的方式 开放给各种consumer，例如hadoop、Hbase、Solr等。 消息系统：解耦和生产者和消费者、缓存消息等。 用户活动跟踪：Kafka经常被用来记录web用户或者app用户的各种活动，如浏览网⻚、 搜索、点击等活动，这些活动信息被各个服务器发布到kafka的topic中，然后订阅者通过 订阅这些topic来做实时的监控分析，或者装载到hadoop、数据仓库中做离线分析和挖 掘。 运营指标：Kafka也经常用来记录运营监控数据。包括收集各种分布式应用的数据，生产 各种操作的集中反馈，比如报警和报告。

2.Kafka基本概念

kafka是一个分布式的，分区的消息(官方称之为commit log)服务。它提供一个消息系统应该 具备的功能，但是确有着独特的设计。可以这样来说，Kafka借鉴了JMS规范的思想，但是确并没有完全遵循JMS规范。

二.Kafka安装教程

链接: https://github.com/weiweiwait/Kafka

三.Kafka集群中leader节点的选举机制

broker的leader

————我们知道Zookeeper集群中也有选举机制，是通过Paxos算法，通过不同节点向其他节点发送信息来投票选举出leader，但是Kafka的leader的选举就没有这么复杂了。
Kafka的Leader选举是通过在zookeeper上创建/controller临时节点来实现leader选举，并在该节点中写入当前broker的信息
————{“version”:1,”brokerid”:1,”timestamp”:”1512018424988”}
————利用Zookeeper的强一致性特性，一个节点只能被一个客户端创建成功，创建成功的broker即为leader，即先到先得原则，leader也就是集群中的controller，负责集群中所有大小事务。
当leader和zookeeper失去连接时，临时节点会删除，而其他broker会监听该节点的变化，当节点删除时，其他broker会收到事件通知，重新发起leader选举。

Kafka的Leader是什么

————首先Kafka会将接收到的消息分区（partition），每个主题（topic）的消息有不同的分区。这样一方面消息的存储就不会受到单一服务器存储空间大小的限制，另一方面消息的处理也可以在多个服务器上并行。
  其次为了保证高可用，每个分区都会有一定数量的副本（replica）。这样如果有部分服务器不可用，副本所在的服务器就会接替上来，保证应用的持续性。
  

————但是，为了保证较高的处理效率，消息的读写都是在固定的一个副本上完成。这个副本就是所谓的Leader，而其他副本则是Follower。而Follower则会定期地到Leader上同步数据。

leader选举

————Kafka使用分布式副本机制来提供高可用性和容错性。每个分区在Kafka集群中都有多个副本，其中一个副本被选为领导者（leader），其他副本被称为追随者（followers）。

在Kafka中，领导者负责处理来自生产者和消费者的所有读写请求。追随者则复制领导者的数据，并参与副本同步。当领导者失效或变得不可用时，Kafka需要从追随者中选举出一个新的领导者来接管分区的处理。

Kafka使用一种基于ZooKeeper的选举机制来进行领导者选举。当领导者失效时，副本会参与一个称为"选举"的过程，其中它们通过ZooKeeper协调服务进行通信。

以下是Kafka领导者选举的基本过程：

当领导者失效时，所有追随者都会开始一个选举过程。
每个追随者会在ZooKeeper上创建一个临时节点，表示自己参与选举。
追随者会向其他副本发送选举请求，并等待回复。
接收到选举请求的副本会比较各自的元数据（包括副本的ID和日志的位置等），选择其中最高的副本作为候选领导者。
如果一个追随者收到了来自所有其他副本的回复，并且自己的元数据最高，那么它就会成为新的领导者。
新选举出的领导者会向ZooKeeper注册自己是领导者，并通知其他副本它的身份。
其他副本在收到新领导者的通知后，更新自己的元数据，将其设置为追随者。
需要注意的是，Kafka的选举机制确保在一个分区中只有一个领导者，并且只有领导者负责处理读写请求。其他追随者则负责与领导者保持数据同步。这种机制确保了数据的一致性和可靠性，同时提供了高可用性的服务。
————当旧的leader节点死亡时，Kafka会从剩余的副本节点中选举新的leader节点。新的leader节点会从之前的leader节点以及其他副本节点中复制数据，并将其同步到自己的日志中，确保数据的一致性和完整性。这个过程称为ISR（In-Sync Replica）同步。一旦新的leader节点同步完毕，就会继续处理消费者的请求和生产者的数据，并且集群将恢复正常运行。

为什么不用少数服从多数的方法

少数服从多数是一种比较常见的一致性算法和Leader选举法。
它的含义是只有超过半数的副本同步了，系统才会认为数据已同步；
选择Leader时也是从超过半数的同步的副本中选择。
这种算法需要较高的冗余度。
譬如只允许一台机器失败，需要有三个副本；而如果只容忍两台机器失败，则需要五个副本。
而kafka的ISR集合方法，分别只需要两个和三个副本。

如果所有的ISR副本都失败了怎么办？

此时有两种方法可选，一种是等待ISR集合中的副本复活，一种是选择任何一个立即可用的副本，而这个副本不一定是在ISR集合中。这两种方法各有利弊，实际生产中按需选择。
  如果要等待ISR副本复活，虽然可以保证一致性，但可能需要很长时间。而如果选择立即可用的副本，则很可能该副本并不一致。