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 的备份
- 存在的意义是防止数据丢失, 从来不会被用于处理客户端的读写.
