＜Kafka核心技术与实战＞学习笔记 -- 深入Kafka内核
Kafka副本机制详解
副本机制（Replication），备份机制，通常是指分布式系统在多台网络互联的机器上保存有相同的数据拷贝
副本机制的好处:
- 提供数据冗余。即使系统部分组件失效，系统依然能够继续运转，因而增加了整体可用性以及数据持久性
- 提供高伸缩性。支持横向扩展，能够通过增加机器的方式来提升读性能，进而提高读操作吞吐量
- 改善数据局部性。允许将数据放入与用户地理位置相近的地方，从而降低系统延时
目前Kafka只能享受到副本机制带来的第 1 个好处，也就是提供数据冗余实现高可用性和高持久性
副本定义
Kafka 是有主题概念的，而每个主题又进一步划分成若干个分区
副本的概念实际上是在分区层级下定义的，每个分区配置有若干个副本
副本（Replica），本质就是一个只能追加写消息的提交日志
同一个分区下的所有副本保存有相同的消息序列，这些副本分散保存在不同的 Broker 上，从而能够对抗部分 Broker 宕机带来的数据不可用
在实际生产环境中，每台 Broker 都可能保存有各个主题下不同分区的不同副本，因此，单个 Broker 上存有成百上千个副本的现象是非常正常的
如图展示的是一个有 3 台 Broker 的 Kafka 集群上的副本分布情况。主题 1 分区 0 的 3 个副本分散在 3 台 Broker 上，其他主题分区的副本也都散落在不同的 Broker 上，从而实现数据冗余
副本角色
如何确保副本中所有的数据都是一致的呢?
基于领导者（Leader-based）的副本机制
工作原理:
- 每个分区在创建时都要选举一个副本，称为
领导者副本（Leader Replica），其余的副本自动称为追随者副本（Follower Replica） - 在 Kafka 中，追随者副本是不对外提供服务的
所有的读写请求都必须发往领导者副本所在的 Broker，由该 Broker 负责处理
追随者副本不处理客户端请求，它唯一的任务就是从领导者副本异步拉取消息，并写入到自己的提交日志中，从而实现与领导者副本的同步
这就是 Kafka 副本没有提供高伸缩性和改善数据局部性的原因 - 当领导者副本挂掉了，或者说领导者副本所在的 Broker 宕机时，Kafka 依托于 ZooKeeper 提供的监控功能能够实时感知到，并立即开启
新一轮的领导者选举，从追随者副本中选一个作为新的领导者。老 Leader 副本重启回来后，只能作为追随者副本加入到集群中
对于客户端用户而言，Kafka 的追随者副本没有任何作用，它既不能像 MySQL 那样帮助领导者副本“抗读”，也不能实现将某些副本放到离客户端近的地方来改善数据局部性
Kafka副本机制的好处:
- 方便实现“Read-your-writes”
当你使用生产者 API 向 Kafka 成功写入消息后，马上使用消费者 API 去读取刚才生产的消息