架构设计：系统间通信（29）——Kafka及场景应用（中2）

作者简介：大家好，我是smart哥，前中兴通讯、美团架构师，现某互联网公司CTO

联系qq：184480602，加我进群，大家一起学习，一起进步，一起对抗互联网寒冬

学习必须往深处挖，挖的越深，基础越扎实！

阶段1、深入多线程

阶段2、深入多线程设计模式

阶段3、深入juc源码解析

阶段4、深入jdk其余源码解析

阶段5、深入jvm源码解析

码哥源码部分

码哥讲源码-原理源码篇【2024年最新大厂关于线程池使用的场景题】

码哥讲源码【炸雷啦！炸雷啦！黄光头他终于跑路啦！】

码哥讲源码-【jvm课程前置知识及c/c++调试环境搭建】

​​​​​​码哥讲源码-原理源码篇【揭秘join方法的唤醒本质上决定于jvm的底层析构函数】

码哥源码-原理源码篇【Doug Lea为什么要将成员变量赋值给局部变量后再操作？】

码哥讲源码【你水不是你的错,但是你胡说八道就是你不对了！】

码哥讲源码【谁再说Spring不支持多线程事务，你给我抽他！】

终结B站没人能讲清楚红黑树的历史，不服等你来踢馆！

打脸系列【020-3小时讲解MESI协议和volatile之间的关系，那些将x86下的验证结果当作最终结果的水货们请闭嘴】

4-3、复制功能

我们在上文中已经讨论了Kafka使用分区的概念存储消息，一个topic可以有多个分区它们分布在整个Kafka集群的多个Broker服务节点中，并且一条消息只会按照消息生产者的要求进入topic的某一个分区。那么问题来了：如果某个分区中的消息在被消费端Pull之前，承载该分区的Broker服务节点就因为各种异常原因崩溃了，那么在这个Broker重新启动前，消费者就无法收到消息了。

为了解决这个问题，Apache Kafka在V 0.8+版本中加入了复制功能：让topic下的每一个分区存储到多个Broker服务节点上，并由Zookeeper统一管理它们的状态。

请注意 Kafka中Partition（分区）和replication（复制）是两个完全不同的概念 ，很多读者容易将这两个概念混淆——虽然它们都和“如何存储消息”这件事情有关：前者是说将若干条消息按照一定的规则分别存放在不同的区域，一条消息只存入一个区域（且 Topic下多个分区可以存在于同一个Broker上 ）；后者是说，为了保证消息在被消费前不会丢失，需要将某一个区域中的消息集合复制出多个副本（ 同一个分区的多个副本不能存放在同一个Broker上 ）。

Kafka将分区的多个副本分为两种角色：Leader和Follower，Leader Broker是主要服务节点，消息只会从消息生产者发送给Leader Broker，消息消费者也只会从Leader Broker中Pull消息。Follower Broker为副本服务节点，正常情况下不会公布给生产者或者消费者直接进行操作。Follower Broker服务节点将会主动从Leader Broker上Pull消息。

在这种工作机制下，Follower和Leader的消息复制过程由于Follower服务节点的性能、压力、网络等原因，它们和Leader服务节点会有一个消息差异性。当这个差异性扩大到一定的范围，Leader节点就会认为这个Follower节点再也跟不上自己的节奏，导致的结果就是Leader节点会将这个Follower节点移出“待同步副本集”ISR（in-sync replicas），不再关注这个Follower节点的同步问题。

只有当ISR中所有分区副本全部完成了某一条消息的同步过程，这条消息才算真正完成了“记录”操作 。只有这样的消息才会发送给消息消费者。至于这个真正完成“记录”操作的通知是否能返回给消息生产者，完全取决于消息生产者采用的acks模式（后文会讲到）。

现在我们可以回过头看看上文中4-1-3-5小节给出的“查看Topic状态”命令以及命令结果：

    # 脚本命令范例
    kafka-topics.sh --describe --zookeeper 192.168.61.139:2181 --topic my_topic2
    
    # 显示的结果
    Topic:my_topic2 PartitionCount:4        ReplicationFactor:2     Conf