消息模型

• Producer：生产消息
• Consumer：消费消息
• Broker：Kafka 服务器，存储消息
• Topic：消息的分类，类似 “文件夹”
• Partition：Topic 分成多个分区，每个分区是有序、不可变的消息日志
• Offset：分区内每条消息的唯一序号

内存结构

topic是逻辑分层，而Partition是真实的物理分层
每个partition就是存储的一个文件夹，里面有三个文件组成

• .log 文件
  真正的消息数据
  消息按顺序存储
• .index 文件
  稀疏索引
  记录 offset → 文件位置（position）
  用于快速定位消息
• .timeindex 文件（可选）
  时间戳索引
  用于按时间查找消息

经典问题

kafka为什么快

• 顺序写磁盘
• 零拷贝
• 批量处理
• 分区并行
• 页缓存（OS cache）

零拷贝是什么

零拷贝是指零CPU拷贝，不需要CPU去操作
一次读取与发送程序都需要经过操作系统去操作磁盘，整体的流程如下：
需要经历四次内存拷贝，可以通过mmap跟sendfile去做到零拷贝

mmap

mmap是操作系统提供的一个方法，可以将内核空间的缓冲区映射到用户空间（在用户区开辟一个空间与内核缓冲区直接映射）
如下图：直接通过mmap将内核缓冲区映射到用户空间.省去了从用户区到内核区写入去发送这一步

sendfile

sendfile是操作系统提供的一个方法.程序调用sendfile会将内核缓冲区直接写入网卡，不需要过用户内存
sendfile不需要CPU参与，而是DMA控制器直接操作就好。CPU还能正常运作

sendfile跟mmap区别

• sendfile返回发送数
• mmap返回发送的具体内容
  
• kafka使用的是sendfile，rocketMQ使用的是mmap，所以kafka更快

为啥rocketMQ不能使用sendfile？

关键点：Consumer 需要的消息在 CommitLog 中不是连续的！
这意味着：
Broker 无法直接把 “磁盘上的一段连续数据” 发给 Consumer
必须在用户态把分散的消息读取、组装成一个完整的响应包
因此无法使用 sendfile

那 RocketMQ 为什么不改成 Kafka 那种结构？

RocketMQ 设计目标不同：
Kafka 更适合大数据吞吐量场景
RocketMQ 更适合金融级可靠性、低延迟、大量 Topic 的业务场景
RocketMQ 的 ConsumeQueue 结构让它能：
支持按 tag 过滤
支持消息重试
支持消息轨迹
支持事务消息

Kafka 的高可用是怎么实现的

• 副本机制
• ISR 列表
• Leader 负责读写
• Follower 同步数据
• 副本故障时从 ISR 中重新选举 Leader

ISR是什么？怎么保障数据高可用？

ISR用一句话讲解就是什么时候去ack成功
有以下几种常见枚举，可根据业务场景，自己去配置

• 写入主Broker则直接返回（无保障）
• 写入一主一备则返回
• 写入一主一半的备份则返回
• 主跟备全写完再返回
  综上，业务测可以自己配置ISR去保障数据不丢失

为什么 Kafka 不支持读写分离？

读写分离是指，读取节点跟写入节点不是同一个（读的是读从节点）

为了保证一致性，Follower 可能落后 Leader，如果允许读 Follower，会出现数据不一致

Kafka 的消息是否会丢失？如何避免？

同ISR原理。可设置ack=all,设置全部写完再返回.

Kafka 的再平衡是什么？为什么会发生？

再平衡是Partition重新分配的过程。
触发条件：

• partition扩缩
  影响：
• 期间消费者无法消费消息

如何保证消息的顺序性？

• 单分区 + 单消费者
• 多分区无法保证全局顺序，但可以保证分区内顺序
• 生产者按 key 发送（相同 key 进入同一分区）（美团saas的支付消息就是这么保障的）

MQ推跟拉的读取方式主要区别是啥？

最大的点如下：
主动权不同
推：Broker 主动推送，broker逻辑更复杂，且可能击垮消费者（需要维护状态、连接、限流）
Pull：消费者 主动拉取 broker逻辑更简单（需要处理轮询、阻塞、消息堆积）