1. Kafka 写入

1. Kafka 是基于磁盘的吗？Kafka 机器不需要消耗内存？

  • Kafka 也是用内存，使用的是操作系统的 page cache 内存。

    2. page cache vs JVM 进程内 cache

  1. JVM 对象存储松散，通常使数据所占内存加倍，通过 OS 缓存二进制数据更紧凑。
  2. 用 JVM 内存 cache 数据，容易导致 GC，使用 page cache 缓存，不存在 GC 问题。
  3. 若 JVM 维护了进程内 cache，若要写磁盘，page cache 会再缓存一份，导致内存折半。
  4. 使用 JVM 进程内 cache，重启 broker 时需要重新加载数据（加载 10G 的数据，可能需要 10min），page cache 不需要重新加载。

    2. Kafka 接收

push、pull 方式比较

方式 优点 缺点
push 实时性 客户端的压力是被动的(不能自己控制可以承受的压力大小)，服务端有性能瓶颈(元信息数据保存在服务端)
pull 客户端自己控制进度 实时性不好

3. kafka 分段存储

image.png

  • .index 为索引文件，.log 为数据文件
  • .index 文件中，第一个值表示 partition offset，第二个值表示 file offset。
  • 根据客户端传入的 offset，从 .index 文件中查找到对应的 file offset 范围，在 .log 文件中查询对应的数据。

    4. Kafka 查询速度快的原因

1. 通过 page cache 实现

image.png

  • 当读取文件 1，此时 page cache 会将数据加载到 3 个 page 中去(哪怕此时可能只用到其中一个 page 的数据)。
  • 假如 100ms 之后又来读取文件 1，此时数据在 page 中已经存在，我们称为命中，此时会直接返回 page 中的数据。
  • 返回数据之后，会加载更多的数据到 page 中去。

  • 假如第三次又读取文件 1，我们从 page 中返回数据，并且加载更多的数据到 page 中，此操作称为预读。

    2. Kafka zero copy

    image.png

  • 图 1：数据会在 page cache、JVM 进程、socket 缓冲区进行三次数据拷贝。

  • 图 2：只会在 page cache 进行一次拷贝。
  • Kafka 通过 netty 实现 zero copy。

    5. Kafka 在 PROD 的方案之：网卡流量激增方案

image.png

  • 如果将 Kafka 机器放到了业务区，当大批量从 Kafka 集群抽取数据时，可能会把交换机的网卡带宽直接打满，此时业务区的其他系统将处于不可用状态。
  • 解决方案：使用多个网卡，业务系统和 Kafka 所使用网卡分离。
  • Kafka 的 server.properties 文件中不对 host.name、advertised.host.name 做配置，Kafka server 实例就会监听所有网卡。

    6. Kafka 优化

producer

  • 写入数据：从以下几条考虑：
    • ack(0、1、All)
    • buffer(压测)
    • 数据类型(binary)

  • reties 参数：假如数据发送不成功，重试。 >= 2

    broker

  • 从 topic partition 个数 / replication 个数 考虑。

  • 写非常多的情况：

    • 看数据重要程度，replication 减少不了；如果不重要，考虑减少 replication 的个数。(reolication 个数增加，会降低写数据的效率，读不会受到影响)
    • 数据重要，增加 partition 个数。(不一定能起作用，假如机器数据固定，此时每台机器的效率已经达到最高，此时增加 partition 的个数也无法提高效率)
    • 增加机器。(多做测试)

      consumer

  • consumer group：

    • 主要优化点在于 consumer 的个数(并发度)，<= partition 个数。
    • timeout 时间、拉取数据的大小(吞吐量)。吞吐量越大，相对来说延迟越大，但消费能力越强。

      数据消费 exactly-once

  • producer

    • ack=all
  • broker
    • replication：>=2
    • IRS: >=2 (Kafka 允许 follower 跟不上 leader 节奏，IRS 表示至少有多少个 follower 跟上了 leader 的节奏，假如设置为2，表示至少有一个 follower 跟上了 leader 的节奏。)
  • consumer
    • 使用 offset info 记录 partition、offset 的信息，保证了数据落地和 offset commit 的原子性。
    • 为了预防 producer 重复发送数据，导致数据重复消费，业务层添加唯一标识 message_id 进行重复过滤。