Zookeeper 与 Kafka (4) : Kafka

1. Overview

1.1 Kafka

• 使用Scala 语言编写, 同时没有遵从JMS 标准

1.2 特性:

• 持久化消息.
• 使用Zookeeper 来构建和管理服务器节点的集群.
  • 节点被分为三种角色: producer, consumer, broker.

1.2 设计理念:

• 自动化的producer 负载均衡.
• 使用文件系统缓存.
• 简化的消息存储机制
  • 存储机制并不会细分到每个consumer 的每条消息的级别上.
• producer 并不会等待broker 的ACK.
  • 所以producer 可以以broker 最大的消息接收速度来发送消息.
• 更高效的消息存储格式.
  • 比JMS 更少的消息头负载, 同时没有index.

2. Architecture

2.1 消息(Message)

• 消息 = 主题(topic) + 字节组的负载(payload of bytes).
• Producer 可以选择特定的序列化方法来对消息内容进行编码.

2.2 消息存储

• 已发布的消息会被存储在被称为Broker 的服务器集群(或者称为Cluster)中.
• 消息被消费(读取)后, 并不会立刻被销毁, 而会被保存至retention 期间.
• 消息可能会在消费失败后, 被consumer 重新消费(读取).

2.3 消息获取

• Consumer 从broker 中拉取消息.
• 为一个主题创建若干个消息stream.
• 发布到主题上的消息, 最终会被分配到该主题的stream 中.
• 消息stream 基于连续的被消费的流模型, 提供了迭代器接口
  • 消息流迭代器不会终止.
  • 当没有消息可以被消费时, 迭代器会阻塞, 直至有新的消息被发布.
• Consumer 使用offset 来迭代流中的每个消息, 来处理消息的负载(payload).
• 点对点发布模型(point-to-point delivery model)
  • 多个Consumer 同时消费同一个消息的副本.
• 发布订阅模型(publish-subscribe model)
  • 多个Consumer 获取各自的消息副本.

3. Implementation

3.1 总览

• 负载均衡
  • 一个主题被切分为多个partitions, 每个broker 存储若干个partitions.
• 同步读写
  • 多个producer 和consumer 可以在同一时间进行消息的发布和读取.

3.2 存储

• 每个partition 对应一个逻辑日志.
  • 物理上, 一个日志是相同尺寸的段文件的集合.
• 当发布消息到partition 时, broker 将消息追加到最新的段文件中.
• 段文件在回写到磁盘后, 对Consumer 可用.
• 消息并没有ID 字段, 通过其在日志中的逻辑offset 来唯一指定.

3.3 无状态的Broker

• Consumer 需要自己维护其消费状态.
• 使用一个基于时间的SLA(service-layer-agreement) 算法作为retention 策略.
• Consumer 可以回退到旧offset 来重新消费数据.
• Broker 上并不会产生磁盘写操作.
• 通过使用sendfile API, 减少了传送负载.

3.4 Zookeeper 与Kafka

• Kafka 使用Zookeeper 来管理和协调Brokers.

4. 主题和分区

• 主题注册在Zookeeper 上.
  • 过多的主题, 可能会造成问题.
  • Producer 会被追加到尾部(类似于文件).
  • Consumer 使用"offset 指针(partition+topic)" 来追踪和管理读取进程.
  • 主题被切分为partition, partition 会有副本.
• Partition 是并行化消费消息的手段.
  • partition 的数目, 不能少于一个Consumer Group 中Consumer 的数目.
  • 每个partition 会有一个leader.
• Producer 可以选择发布的主题和partition.
  • 具有相同消息键的消息会被记录到相同partition 上.
• Consumer 可以指定Consumer Group.
  • 每个消息会被发送到每个订阅的Consumer Group 中的一个Consumer 上.
• Replica: partition 的备份
  • 存在的意义是防止数据丢失, 从来不会被用于处理客户端的读写.