起源：阿凡卢，
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的生产信息。