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