共计 3566 个字符，预计需要花费 9 分钟才能阅读完成。
起源：阿凡卢，
www.cnblogs.com/luxiaoxun/p/5492646.html
简介
Apache Kafka 是分布式公布 - 订阅音讯零碎。它最后由 LinkedIn 公司开发，之后成为 Apache 我的项目的一部分。Kafka 是一种疾速、可扩大的、设计外在就是分布式的，分区的和可复制的提交日志服务。
Kafka 架构
它的架构包含以下组件：
- 话题（Topic）：是特定类型的音讯流。音讯是字节的无效负载（Payload），话题是音讯的分类名或种子（Feed）名。
- 生产者（Producer）：是可能公布音讯到话题的任何对象。
- 服务代理（Broker）：已公布的音讯保留在一组服务器中，它们被称为代理（Broker）或 Kafka 集群。
- 消费者（Consumer）：能够订阅一个或多个话题，并从 Broker 拉数据，从而生产这些已公布的音讯。
Kafka 存储策略
1）kafka 以 topic 来进行音讯治理，每个 topic 蕴含多个 partition，每个 partition 对应一个逻辑 log，有多个 segment 组成。
2）每个 segment 中存储多条音讯（见下图），音讯 id 由其逻辑地位决定，即从音讯 id 可间接定位到音讯的存储地位，防止 id 到地位的额定映射。
3）每个 part 在内存中对应一个 index，记录每个 segment 中的第一条音讯偏移。
4）发布者发到某个 topic 的音讯会被平均的散布到多个 partition 上（或依据用户指定的路由规定进行散布），broker 收到公布音讯往对应 partition 的最初一个 segment 上增加该音讯，当某个 segment 上的音讯条数达到配置值或音讯公布工夫超过阈值时，segment 上的音讯会被 flush 到磁盘，只有 flush 到磁盘上的音讯订阅者能力订阅到，segment 达到肯定的大小后将不会再往该 segment 写数据，broker 会创立新的 segment。
Kafka 删除策略
1）N 天前的删除。
2）保留最近的 MGB 数据。
Kafka broker
与其它音讯零碎不同，Kafka broker 是无状态的。这意味着消费者必须保护已生产的状态信息。这些信息由消费者本人保护，broker 齐全不论（有 offset managerbroker 治理）。
- 从代理删除音讯变得很辣手，因为代理并不知道消费者是否曾经应用了该音讯。Kafka 创新性地解决了这个问题，它将一个简略的基于工夫的 SLA 利用于保留策略。当音讯在代理中超过肯定工夫后，将会被主动删除。
- 这种翻新设计有很大的益处，消费者能够成心倒回到老的偏移量再次生产数据。这违反了队列的常见约定，但被证实是许多消费者的基本特征。
以下摘抄自 kafka 官网文档：
Kafka Design
指标
1) 高吞吐量来反对高容量的事件流解决
2) 反对从离线零碎加载数据
3) 低提早的音讯零碎
长久化
1) 依赖文件系统，长久化到本地
2) 数据长久化到 log
效率
1) 解决”small IO problem“：
应用”message set“组合音讯。
server 应用”chunks of messages“写到 log。
consumer 一次获取大的音讯块。
2）解决”byte copying“：
在 producer、broker 和 consumer 之间应用对立的 binary message format。
应用零碎的 pagecache。
应用 sendfile 传输 log，防止拷贝。
端到端的批量压缩（End-to-end Batch Compression）
Kafka 反对 GZIP 和 Snappy 压缩协定。
The Producer
负载平衡
1）producer 能够自定义发送到哪个 partition 的路由规定。默认路由规定：hash(key)%numPartitions，如果 key 为 null 则随机抉择一个 partition。
2）自定义路由：如果 key 是一个 user id，能够把同一个 user 的音讯发送到同一个 partition，这时 consumer 就能够从同一个 partition 读取同一个 user 的音讯。
异步批量发送
批量发送：配置不多于固定音讯数目一起发送并且等待时间小于一个固定提早的数据。
The Consumer
consumer 管制音讯的读取。
Push vs Pull
1)producer push data to broker，consumer pull data from broker
2)consumer pull 的长处：consumer 本人管制音讯的读取速度和数量。
3)consumer pull 的毛病：如果 broker 没有数据，则可能要 pull 屡次忙期待，Kafka 能够配置 consumer long pull 始终等到有数据。
Consumer Position
1) 大部分音讯零碎由 broker 记录哪些音讯被生产了，但 Kafka 不是。
2)Kafka 由 consumer 管制音讯的生产，consumer 甚至能够回到一个 old offset 的地位再次生产音讯。
Message Delivery Semantics
三种：
At most once—Messages may be lost but are never redelivered.
At least once—Messages are never lost but may be redelivered.
Exactly once—this is what people actually want, each message is delivered once and only once.
Producer：有个”acks“配置能够管制接管的 leader 的在什么状况下就回应 producer 音讯写入胜利。
Consumer：
* 读取音讯，写 log，解决音讯。如果解决音讯失败，log 曾经写入，则无奈再次解决失败的音讯，对应”At most once“。
* 读取音讯，解决音讯，写 log。如果音讯解决胜利，写 log 失败，则音讯会被解决两次，对应”At least once“。
* 读取音讯，同时解决音讯并把 result 和 log 同时写入。这样保障 result 和 log 同时更新或同时失败，对应”Exactly once“。
Kafka 默认保障 at-least-once delivery，答应用户实现 at-most-once 语义，exactly-once 的实现取决于目标存储系统，kafka 提供了读取 offset，实现也没有问题。
复制（Replication）
1）一个 partition 的复制个数（replication factor）包含这个 partition 的 leader 自身。
2）所有对 partition 的读和写都通过 leader。
3）Followers 通过 pull 获取 leader 上 log（message 和 offset）
4）如果一个 follower 挂掉、卡住或者同步太慢，leader 会把这个 follower 从”in sync replicas“（ISR）列表中删除。
5）当所有的”in sync replicas“的 follower 把一个音讯写入到本人的 log 中时，这个音讯才被认为是”committed“的。
6）如果针对某个 partition 的所有复制节点都挂了，Kafka 抉择最先复活的那个节点作为 leader（这个节点不肯定在 ISR 里）。
日志压缩（Log Compaction）
1）针对一个 topic 的 partition，压缩使得 Kafka 至多晓得每个 key 对应的最初一个值。
2）压缩不会重排序音讯。
3）音讯的 offset 是不会变的。
4）音讯的 offset 是程序的。
Distribution
Consumer Offset Tracking
1）High-level consumer 记录每个 partition 所生产的 maximum offset，并定期 commit 到 offset manager（broker）。
2）Simple consumer 须要手动治理 offset。当初的 Simple consumer Java API 只反对 commit offset 到 zookeeper。
Consumers and Consumer Groups
1）consumer 注册到 zookeeper
2）属于同一个 group 的 consumer（group id 一样）平均分配 partition，每个 partition 只会被一个 consumer 生产。
3）当 broker 或同一个 group 的其余 consumer 的状态发生变化的时候，consumer rebalance 就会产生。
Zookeeper 协调控制
1）治理 broker 与 consumer 的动静退出与来到。
2）触发负载平衡，当 broker 或 consumer 退出或来到时会触发负载平衡算法，使得一个 consumer group 内的多个 consumer 的订阅负载平衡。
3）保护生产关系及每个 partition 的生产信息。
