下一代分布式消息系统Apache Kafka

[attach]923[/attach]

一、开篇思考

[attach]924[/attach] 消息语义：

持久性 安全 淘汰 交付 路由 批量 消息过滤 排队标准 已收通知

[attach]925[/attach] IO： [attach]926[/attach] 机械磁盘慢 现代操作系统优化 

[]使用read-ahead和write-behind技术，预读取成块数据，将微小琐碎的逻辑写入组织成一次较大的物理写入[/][]常用空闲内存用作磁盘缓存[/][]线性的访问磁盘，很多时候比随机的内存访问快得多[/]

JVM 2个事实

[]Java对象占用空间非常大，差不多要存储的数据的两倍甚至更高[/][]随着堆中数据量的增加，GC（垃圾回收)变得越来越困难[/]

JVM 1个假设

[]在64G内存的机器上,不得不使用到50G~56G的内存空间[/][]当系统重启的时候,又必须要将数据刷到内存中(每分钟1GB内存),即使冷刷新(在使用数据的时候发现没有再刷到内存)也会导致最初的时候性能非常慢[/]

图解零拷贝[attach]927[/attach][attach]928[/attach][attach]929[/attach]设计常量复杂度的磁盘操纵B树的复杂度是O(logN),通常被认为就是常量复杂度但对于磁盘操作来说并非如此:磁盘进行一次搜索需要10ms,每个磁盘在同一时间只能进行一次搜索,并发处理困难 对树结构的性能的观察结果表明:其性能往往随着数据的增长而线性下降,数据增长一倍,速度就会降低一倍[list=1][] 线性访问减小磁盘寻道[/][] 压缩数据减小IO压力[/][] 使用零拷贝(zero copy)技术[/]

二、Kafka特性 & 原理

一个高性能分布式（Distribution），可分区（Partitioned），可备份(Replicated),基于Zookeeper协调的发布/订阅消息队列系统

快速持久化

以时间复杂度为O(1)的方式提供消息持久化能力

高吞吐率

在一台普通的服务器上可以达到10W/s级的消息处理

分布式负载均衡

Broker/Producer/Consumer 都支持分布式和负载均衡

水平扩展

支持在线平滑水平扩展

kafka名词解释：[list=1][]Broker & Controller & Producer & Consumer & Consumer Group 2. Topic & Partition & Segment & Offset[/][]Replication & Replication Leader & Replication Follower[/][]Assigned Replications & Preferred Replication[/][]Message & Message Set[/][attach]930[/attach]主题解析[attach]931[/attach]部分文件实现[attach]932[/attach]Broker & Topic Partition[attach]933[/attach]消息交付[attach]934[/attach][attach]935[/attach]同步语义[list=1][]每一个Broker节点必须维护和Zookeeper的连接Session,Zookeeper通过心跳机 制检查每个结点的连接 [/][]Follower Broker节点必须及时同步Leader Broker节点,不能落后Leader Broker 节点太多 [/]副本和提交log[list=1][]当且仅当Message被所有的Replication写入到Log中,才算"Committed"[/][]只有Committed的Message,才会被Consumer读取  [/]Persistence & Efficiency [list=1][]每一个Follower都只从Leader Pull数据[/][]每一个Follower收到数据后,立即向Leader发送ACK,而非等到数据写入Log后[/]Consumer  & Partition [list=1][]同一Consumer Group中Consumer竞争Partition,即队列语义 [/][]不同Consumer Group中Consumer共享Partition,即主题语义 [/]消息传递语义[list=1][]At most once - 消息可能会丢,但绝不会重复传输[/][]At least once - 消息绝不会丢,但可能会重复传输[/][]Exactly once - 每一条消息肯定会被传输一次且仅传输一次,理想状态 [/]Leader Election算法 [list=1][]Leader Election[/][]In-Sync Replicas Approach VS. Majority Vote[/][]某一个Partition所有Replication不工作[/]Controller思考 [list=1][]选举Broker Leader最简单最直观的方案[/][]该选举Broker Leader的方案引入了哪些问题 [/]Partition 思考[list=1][]Partition的数据结构,逻辑上/物理上的存储结构[/][]Broker&Topic&Partition关系[/][]Partition&Consumer&Consumer Group关系 [/]Producer思考[list=1][]Load balancing[/][]Asynchronous send[/]Consumer思考[list=1][]Push VS. Pull[/][]Offset归属,存储[/][]触发Partition Rebalance的条件及问题 [/][]减轻了Broker设计的复杂度[/]

三、Kafka设计 & 实现

Broker内部[attach]936[/attach]Broker故障转移[attach]937[/attach]插件删除Topic[attach]938[/attach]LeaderAndIsrRequest 响应[attach]939[/attach]Partition重新分配案例[attach]940[/attach]Replication工具[list=1][]Topic Tool[/][]Replica verification Tool[/][]Preferred Replica Leader Election Tool[/][]Kafka Reassign Partitions Tool[/][]State Change Log Merge Tool[/] Preferred Replica Leader Election Tool 在8个Broker的kafka集群上，创建topic为my_topic,replication-factor为3，partition-factor为8，Partition/Replica分布 [attach]941[/attach] 手动停止Broker 1/2/4,Partition/Replica分布 [attach]942[/attach] 手动启动Broker 1，Partition/Replica分布 [attach]943[/attach] 运行该工具后，Partition/Replica分布 [attach]944[/attach] 手动启动Broker 2/4，Partition/Replica分布 [attach]945[/attach] 运行该工具后，Partition/Replica分布 [attach]946[/attach] 将Topic的所有Partition重新分配到Broker 4/5/6/7上，初始Partition/Replica分布 [attach]947[/attach] 将Topic的所有Partition重新分配到Broker 4/5/6/7上，最终Partition/Replica分布 [attach]948[/attach]

分享作者：王先明