点一下关注吧！！！非常感谢！！持续更新！！！
目前已经更新到了：
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副本复活，虽然保证一致性，但可能需要很长的时间。
如果选择立即可用的副本，虽然保证可用性，但是数据可能会丢失。
