INDEX

      • §1 为什么快
      • §2 消息丢失
        • §2.1 消息丢失位置
        • §2.2 如何避免消息丢失
      • §3 顺序消费

§1 为什么快

  • kafka使用的是基于文件的顺序存储
    • 代价是只能通过offset标记消费情况并
    • 总 partition 数越高，性能越下降，可降低一个数量级
      每个 partition 的消息会保存在一个独立文件中，文件内都是顺序读写，跨文件就变成随机 io 了
  • kafka使用 0 复制技术进行网络传输，速度快，底层依赖sendFile
  • kafka默认开启消息压缩
    消息是在客户端压缩后再传输，服务端只保存，客户端消费时也是先传输后解压然后才能真的消费

§2 消息丢失

§2.1 消息丢失位置

  • 1：producer 向 kafka 投递消息时
  • 2：kafka-topic 中 leader 已经写入了消息，向副本写入消息前挂了时
  • 3：消费者从 kafka 拉取了消息，提交了 offset 但没有真实消费时
§2.2 如何避免消息丢失

发送时：

  • 启动独立消息服务，持久化所有需要发送的消息
    • 不是所有消息都需要持久化，没有可靠性要求的消息可以直接发送
    • 先持久化消息数据，再投递消息，消息收到 ACK 后需要更新消息状态
  • 开启定时任务，轮询持久化的消息，长期没有变更状态的消息需要回查

复制时

  • ACK 机制的选择
    • 可以保持默认的 all 级别
    • 但因为有独立消息服务在，可以置为 1（写入 leader 即返回）
  • 指定合适 ISR
    • ISR 即 In-Sync Replica set，是与 leader 正常通信的 broker 的集合
    • leader 包含在这个集合中
    • 通过 max.insync.replica 可以确定 ACK 返回的时机
      • 必须在 ACK == all/-1 时，此配置才有效
      • 通常配置为 副本数/2
      • 默认值 1，但这样配置 ACK 的 ALL 与 1 等价，都是只写入 leader 就 ACK

消费时：

  • 需要正确的提交 offset
  • offset 可以漏提交，但不能空提交（还没消费就提交了）
  • 消费端必须补全幂等

§3 顺序消费

  • 业务没有要求的情况下不用保证顺序消费
  • 局部顺序消费由 partition 保证，partition 中的消息是有序的，会顺序消费
  • 如果希望全局顺序消费，需要 topic 只有一个 partition
  • 不能保证顺序消费的场景
    • 消息加入到死信队列(重试队列) 中
      已经脱离了原来的顺序
    • 消费端开了并发消费，比如监听到的消息扔到线程池里处理