点一下关注吧！！！非常感谢！！持续更新！！！
目前已经更新到了：
- Hadoop（已更完）
- HDFS（已更完）
- MapReduce（已更完）
- Hive（已更完）
- Flume（已更完）
- Sqoop（已更完）
- Zookeeper（已更完）
- HBase（已更完）
- Redis （已更完）
- Kafka（正在更新…）
章节内容
上节我们完成了如下的内容，基本都是特性概念相关的：
- kafka-topics.sh 的基本参数和基本使用，涉及到创建、查看、修改、主题，增加分区等。
- KafkaAdminClient
- Kafka偏移量管理
副本机制
Kafka在一定数量的服务器上对主题分区进行复制，当集群中一个Broker宕机之后们可以自动故障转移到其他可用的副本上，不会造成数据丢失。
- 将复制因子为1的未复制主题称为复制主题
- 主题的分区是复制的最小单元
- 在非故障的情况下，Kafka中的每个分区都由1个Leader副本，0个或N个Follower副本。
- 包括Leader副本在内的副本总数构成复制因子
- 所有读取和写入都是由Leader副本负责
- 通常分区比Broker多，并且Leader分区在Broker之间平均分配
Follower分区像普通的Kafka消费者一样，消费者来自Leader分区的消息，并将其持久化到自己的日志中，允许Follower对日志条目拉取进行批处理。
同步节点
- 节点必须能够维持ZooKeeper的会话（通过ZooKeeper的心跳机制）
- 对于Follower副本分区，它复制在Leader分区上的写入，并且不要延迟太多
Kafka提供的保证是：只要至少有一个同步副本处于活动状态，提交的消息就不会丢失。
宕机恢复
少副本宕机
当Leader宕机了，会从Follower选择一个作为Leader，当宕机重新恢复时，会把之前的commit清空，重新从Leader中Pull数据。
全副本宕机
- 恢复方式1：等待ISR中的一个恢复后，选为Leader（时间久，可用性低）
- 恢复方式2：选择一个恢复的副本作为新的Leader，无论是否在ISR中（可能未包含提交commit，会丢失数据）
Leader选举
- 3个分区
- 3个Broker
基础概念
生产者和消费者的请求都由Leader副本处理，Follower副本只负责Leader副本的数据和Leader保持同步。
Leader副本和Follower副本之间的关系并不是固定不变的，在Leader所在的Broker发生故障的时候，就需要进行分区的Leader副本和Follower副本之间的切换，需要选举Leader副本。
如何选举
如果某个分区所在的服务器出了问题导致不可用，Kafka会从该分区的其他副本中选择一个成为新的Leader，之后所有的读写就会转移到这个新的Leader上。
那么如何选择Leader呢？
- 只有那些跟Leader保持同步的Follower才应该被选择为新的Leader
- Kafka会在ZooKeeper上针对每个Topic维护一个成为ISR（in-sync replica，已同步的副本）的集合，该集合中是一些分区的副本。
- 只有当这些副本都跟Leader中的副本同步了之后，Kafka才会认为消息已提交，并反馈给消息的生产者
- 如果这个集合有增有减，Kafka会更新ZOoKeeper上的记录
- 如果某个分区的Leader不可用，Kakfa就会从ISR集合中选择一个副本作为新的Leader
显然通过ISR，Kafka需要的冗余度是较低的，可以容忍的失败度较高。
假设某个Topic有N+1个副本，Kafka可以容忍N个服务器不可用。
为何不用少数服从多数
- 少数服从多数是一种比较常见的一致性算法和Leader选举法
- 它的含义是只有超过半数的副本同步了，系统才会认为数据已经同步
- 选择Leader时也是超过半数的同步副本中选择
- 这种算法需要较高的冗余度，更Kafka比起来，浪费资源
- 譬如：允许一台机器失败，则要三个副本。允许两台机器失败，则需要五个副本
而在Kafka的ISR集合中，允许一台机器失败，要两个副本。允许三台机器失败，需要五个副本。
若ISR全部失败
此时有两种方案可以选择：
- 等待ISR集合中的副本复活
- 选择任何一个立即可用的副本，而这个副本不一定是在ISR集合中（需要设置：unclean.leader.election.enable=true）
这两种方法各有利弊，实际生产中按需选择即可。
- 如果要等待ISR副本复活，虽然保证一致性，但可能需要很长的时间。
- 如果选择立即可用的副本，虽然保证可用性，但是数据可能会丢失。
