下一代分布式消息系统Apache Kafka
一、开篇思考
消息语义：
持久性 安全 淘汰 交付 路由 批量 消息过滤 排队标准 已收通知
IO：
机械磁盘慢
现代操作系统优化
- 使用read-ahead和write-behind技术，预读取成块数据，将微小琐碎的逻辑写入组织成一次较大的物理写入
- 常用空闲内存用作磁盘缓存
- 线性的访问磁盘，很多时候比随机的内存访问快得多
JVM 2个事实
- Java对象占用空间非常大，差不多要存储的数据的两倍甚至更高
- 随着堆中数据量的增加，GC（垃圾回收)变得越来越困难
JVM 1个假设
- 在64G内存的机器上,不得不使用到50G~56G的内存空间
- 当系统重启的时候,又必须要将数据刷到内存中(每分钟1GB内存),即使冷刷新(在使用数据的时候发现没有再刷到内存)也会导致最初的时候性能非常慢
图解 零拷贝
设计 常量复杂度 的磁盘操纵
B树的复杂度是O(logN),通常被认为就是常量复杂度
但对于磁盘操作来说并非如此:磁盘进行一次搜索需要10ms,每个磁盘在同一时间只能进行一次搜索,并发处理困难 对树结构的性能的观察结果表明:其性能往往随着数据的增长而线性下降,数据增长一倍,速度就会降低一倍
- 线性访问减小磁盘寻道
- 压缩数据减小IO压力
- 使用零拷贝(zero copy)技术
二、Kafka特性 & 原理
一个高性能分布式（Distribution），可分区（Partitioned），可备份(Replicated),基于Zookeeper协调的发布/订阅消息队列系统快速持久化
以时间复杂度为O(1)的方式提供消息持久化能力高吞吐率
在一台普通的服务器上可以达到10W/s级的消息处理分布式负载均衡
Broker/Producer/Consumer 都支持分布式和负载均衡水平扩展
支持在线平滑水平扩展
kafka名词解释：
- Broker & Controller & Producer & Consumer & Consumer Group 2. Topic & Partition & Segment & Offset
- Replication & Replication Leader & Replication Follower
- Assigned Replications & Preferred Replication
- Message & Message Set
主题解析
部分文件实现
Broker & Topic Partition
消息交付
同步语义
- 每一个Broker节点必须维护和Zookeeper的连接Session,Zookeeper通过心跳机 制检查每个结点的连接
- Follower Broker节点必须及时同步Leader Broker节点,不能落后Leader Broker 节点太多
副本和提交log
- 当且仅当Message被所有的Replication写入到Log中,才算"Committed"
- 只有Committed的Message,才会被Consumer读取
Persistence & Efficiency
- 每一个Follower都只从Leader Pull数据
- 每一个Follower收到数据后,立即向Leader发送ACK,而非等到数据写入Log后
Consumer & Partition
- 同一Consumer Group中Consumer竞争Partition,即队列语义
- 不同Consumer Group中Consumer共享Partition,即主题语义
消息传递语义
- At most once - 消息可能会丢,但绝不会重复传输
- At least once - 消息绝不会丢,但可能会重复传输
- Exactly once - 每一条消息肯定会被传输一次且仅传输一次,理想状态
Leader Election算法
- Leader Election
- In-Sync Replicas Approach VS. Majority Vote
- 某一个Partition所有Replication不工作
Controller思考
- 选举Broker Leader最简单最直观的方案
- 该选举Broker Leader的方案引入了哪些问题
Partition 思考
- Partition的数据结构,逻辑上/物理上的存储结构
- Broker&Topic&Partition关系
- Partition&Consumer&Consumer Group关系
Producer思考
- Load balancing
- Asynchronous send
Consumer思考
- Push VS. Pull
- Offset归属,存储
- 触发Partition Rebalance的条件及问题
- 减轻了Broker设计的复杂度
三、Kafka设计 & 实现
Broker内部
Broker故障转移
插件删除Topic
LeaderAndIsrRequest 响应
Partition重新分配案例
Replication工具
- 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分布
手动停止Broker 1/2/4,Partition/Replica分布
手动启动Broker 1，Partition/Replica分布
运行该工具后，Partition/Replica分布
手动启动Broker 2/4，Partition/Replica分布
运行该工具后，Partition/Replica分布
将Topic的所有Partition重新分配到Broker 4/5/6/7上，初始Partition/Replica分布
将Topic的所有Partition重新分配到Broker 4/5/6/7上，最终Partition/Replica分布
分享作者：王先明
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
