为什么要有消息队列
生活中有这样的场景
快递员将包裹送给买家。
我记得在小时候，收快递是需要快递员电话联系上门时间的。这非常不方便，一方面快递员手中可能有多个包裹，另一方面买家可能在上班时间抽不出身。
后来有了驿站，快递员只需要将包裹放入驿站，并通知买家按时取走。这种模式便捷了快递员和买家双方。
驿站的作用类似于“中间件”，它的出现有这些好处
1.解耦系统组件
快递员和收货人无需接触也能完成事件，解放了快递员和收货人的时间。
2.异步处理
异步允许事情独立发生，相互之间不需要等待对方完成。快递员不需要询问收货人是否在家，收货人不需要等待快递员上门。
3.流量削峰
收货人不用面对多个快递同时抵达在不同位置的尴尬情况。
4.失败重试与可靠性
允许收货人因特殊原因当天无法取件（处理失败），驿站可以将包裹保留几日。
消息队列通信的模式
上面的例子中引出了“中间件”的概念，驿站就类似于消息队列，但消息队列有不同模式。
两种模式
1.点对点模式
Producer将Message放于Queue中，Consumer从中拉取信息。该模式下，发送到队列的消息被一个且只有一个消费者进行处理，消费者主动拉取消息的好处是频率可控，弊端是消费者不知是否有未处理的信息。
2.发布-订阅模式
该模式类似于公众号，新消息发送给所有关注的用户。消费者无需考虑是否有未处理的消息。弊端是消费者之间性能的差异带来的木桶效应，如Consumer1的处理速度为10，而Consumer2的处理速度为3，最后的推送速度只能小于3。但这极大浪费了Cinsumer1的性能。
Kafka
Kafka 本质上是一个 基于发布/订阅模型 的消息系统。作为一种高吞吐、可水平扩展、持久化、分布式提交日志服务。要想理解Kafka我们要先知道其基础架构及术语。
基础架构及术语
Broker
Broker是Kafka中的单个服务器节点，一个Kafka可以包含多个Broker，多个Broker组成Kafka集群。每个Broker都可以处理一部分数据（消息的接收、存储、传输）
Topic
消息的逻辑类别或数据流名称。对消息进行分类和组织，可以把它想象成文件夹名称。
Partition
是Topic的分区，一个Topic可能有多个分区。Partition 是 Kafka 实现并行处理和高吞吐的关键。生产者和消费者可以并行地与多个 Partition 交互。
Replica
Partition 的副本。每个 Partition 可以有多个 Replica，分布在不同的Broker上，用于容错。
Leader Replica/Follower Replica
每个 Partition 在某一时刻只有一个 Leader。所有针对该 Partition 的读写请求（生产和消费）都必须由 Leader 处理。
从 Leader Replica 复制数据。如果 Leader 失效，其中一个 Follower 会被选举为新的 Leader。
In-Sync Replica (ISR)
指那些与 Leader Replica 保持足够同步的 Replica 集合（包括 Leader 自身）。只有 ISR 中的 Follower 才有资格在 Leader 失效时被选举为新的 Leader。
Producer
向 Kafka Topic 发布消息的客户端应用程序，即是生产者，是消息的入口。
Consumer
从 Kafka Topic 订阅并读取消息的客户端应用程序，即是消费者，是消息的出口。
Consumer Group
将多个消费组组成一个消费者组。同一个分区的数据只能被消费者组中某一个用户消费，同一个消费者组的消费者可以在同一个Topic上消费不同分区（并行）。
ZooKeeper
Kafka 集群依赖 ZooKeeper 集群来存储和管理关键的元数据。
流程分析
发送数据
写入数据时，Producer先找到Leader，将数据写入Leader。这个过程展开来说如此：
1.将消息发给Leader
2.Leader写入数据
3.Follower同步Leader的消息
4.Follower发送ack表示同步完成
5.Leader收到所有Follwer的ack后向Producer发送ack，表示过程结束
ack是什么？
acks（Acknowledgments）是生产者（Producer）配置的核心参数之一，用于控制消息写入的可靠性级别。 它决定了生产者认为消息“成功发送”之前，需要多少个分区副本（Replica）确认收到该消息。
通常ack有三种配置：0、1、all
0代表不等待确认，生产者发送消息后立即认为成功，不等待Broker回应。可靠性最低但效率最高。
1代表Leader确认，生产者等待Leader将消息写入本地。可靠性和效率都是中等。
all代表全副本确认，等待ISR中所有副本都成功写入消息。可靠性最高但效率最低。
保存数据
Kafka会单独开辟一块磁盘空间，顺序写入数据。
Partition 结构
每个 Partition 是一个 追加写入的日志文件（Append-only Log），存储在磁盘上。Kafka 使用日志文件来持久化消息，每个 Partition 对应一个目录，目录下包含多个日志文件（Segment）。
<topic-name>-<partition-id>/
├── 00000000000000000000.index
├── 00000000000000000000.log
├── 00000000000000000000.timeindex
├── 00000000000000000001.index
├── 00000000000000000001.log
├── 00000000000000000001.timeindex
└── ...
Partition 的选择策略
当生产者发送消息到某个 Topic 时，Kafka 会根据以下策略选择将消息写入哪个 Partition：
1.指定 Partition：生产者可以显式指定 Partition
2.Key Hash：如果消息有 Key，则默认使用 Key 的 Hash 值取模 Partition 数量
3.轮询：没有 Key 时，默认轮询方式分配 Partition
数据保留策略
Kafka可以通过配置来设置数据的保留策略，包括基于时间的保留（如7天）和基于大小的保留（如1GB）。一旦数据超过了这些限制，就会被删除以释放空间。
消费数据
Kafka支持点对点和发布订阅两种模式。当单个消费者时，采取类似点对点模式；消费群组时，采用发布订阅模式。
前文提到过多个消费者组成的消费者组，每个消费者组有其独特的编号，同一个消费者组的消费者可以消费同一Topic下不同分区的数据，但是不会组内多个消费者消费同一分区的数据。
如果消费者数量和分区数量不一致：
消费者数量<分区数量 —— 有的消费者会消费多个分区，效率低于消化单个分区的消费者
消费者数量>分区数量 —— 多出来的消费者不消化数据
查找数据
Kafka 的查找数据过程是其高性能和高吞吐量的核心机制之一。Kafka 通过稀疏索引、日志段（Log Segment） 和 二分查找算法 实现高效的数据检索。
Kafka查找数据过程分为两个主要步骤：
- 定位目标日志段（Log Segment）
- 在日志段中查找具体消息
定位日志段
是 Kafka 存储消息的基本单元，每个 Partition 被划分为多个日志段（00000000000000000000.log 和 00000000000000000099.log）。
第一个日志段的起始偏移量为 0，后续日志段的起始偏移量为上一个日志段的最后一条消息的 offset。
Kafka使用二分查找算法在日志段列表中定位目标。
offset
即是偏移量，用于标识消息在 Kafka 分区（Partition）中的唯一位置。它是 Kafka 实现消息顺序性、消费进度追踪和数据可靠性管理的关键机制。
它有如下作用：
1.标识消息在分区中的位置
2.保证消息在分区内有序性
3.跟踪消费者的消费进度
查找具体消息
Kafka 的每个日志段包含两个关键文件：.log 文件 和.index 文件（稀疏索引）
稀疏索引：每隔一定字节数（默认 4KB）为一条消息创建索引项。如1、2、3、4、5… ——> 1、3、5…
整体流程概括为：稀疏索引 + 二分查找 + 顺序写入 + 内存映射
