原文出处： 阿凡卢

简介

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的消费信息。