温馨提示:TPS只是众多性能指标中的一个,我们在做技术选型方面要从多方面考虑,本文并不打算就消息中间件选型方面投入太多笔墨,重点想尝试剖析两者在性能方面的设计思想。
1.1 Kafka 文件布局
Kafka 文件在宏观上的布局如下图所示:
正如上图所示,Kafka 文件布局的主要特征如下:
文件的组织以 topic + 分区进行组织,每一个 topic 可以创建多个分区,每一个分区包含单独的文件夹,并且是多副本机制,即 topic 的每一个分区会有 Leader 与 Follow,并且 Kafka 内部有机制保证 topic 的某一个分区的 Leader 与 follow 不会存在在同一台机器,并且每一台 broker 会尽量均衡的承担各个分区的 Leader,当然在运行过程中如果不均衡,可以执行命令进行手动重平衡。Leader 节点承担一个分区的读写,follow 节点只负责数据备份。
Kafka 的负载均衡主要依靠分区 Leader 节点的分布情况。
分区的 Leader 节点负责读写,而从节点负责数据同步,如果Leader分区所在的Broker节点发生宕机,会触发主从节点的切换,会在剩下的 follow 节点中选举一个新的 Leader 节点,其数据的流入流程如下图所示:
分区 Leader 收到客户端的消息发送请求时,是写入到 Leader 节点后就返回还是要等到它的从节点全部写入后再返回,这里非常关键,会直接影响消息发送端的时延,故 Kafka 提供了 ack 这个参数来进行策略选择:
- ack = 0
不等broker端确认就直接返回,即客户端将消息发送到网络中就返回发送成功。
- ack = 1
Leader 节点接受并存储后向客户端返回成功。
- ack = -1
Leader节点和所有的Follow节点接受并成功存储再向客户端返回成功。
1.2 RocketMQ 文件布局
RocketMQ 的文件布局如下图所示:
RocketMQ 所有主题的消息都会写入到 commitlog 文件中,然后基于 commitlog 文件构建消息消费队列文件(Consumequeue),消息消费队列的组织结构按照 /topic/{queue} 进行组织。从集群的视角来看如下图所示:
RocketMQ 默认采取的是主从同步,当然从RocketMQ4.5引入了多副本机制,但其副本的粒度为 Commitlog 文件,上图中不同 master 节点之间的数据完成不一样(数据分片),而主从节点节点数据一致。
1.3 文件布局对比
Kafka 中文件的布局是以 Topic/partition ,每一个分区一个物理文件夹,在分区文件级别实现文件顺序写,如果一个Kafka集群中拥有成百上千个主题,每一个主题拥有上百个分区,消息在高并发写入时,其IO操作就会显得零散,其操作相当于随机IO,即 Kafka 在消息写入时的IO性能会随着 topic 、分区数量的增长,其写入性能会先上升,然后下降。
而 RocketMQ在消息写入时追求极致的顺序写,所有的消息不分主题一律顺序写入 commitlog 文件,并不会随着 topic 和 分区数量的增加而影响其顺序性。但通过笔者的实践来看一台物理机并使用SSD盘,但一个文件无法充分利用磁盘IO的性能。
两者文件组织方式,除了在磁盘的顺序写方面有所区别后,由于其粒度的问题,Kafka 的 topic 扩容分区会涉及分区在各个 Broker 的移动,其扩容操作比较重,而 RocketMQ 数据存储是基于 commitlog 文件的,扩容时不会产生数据移动,只会对新的数据产生影响,RocketMQ 的运维成本对 Kafka 更低。
最后 Kafka 的 ack 参数可以类比 RocketMQ 的同步复制、异步复制。
Kafka 的 ack 参数为 1 时,对比 RocketMQ 的异步复制; -1 对标 RocketMQ 的 同步复制,而 -1 则对标 RocketMQ 消息发送方式的 oneway 模式。
2.1 Kafka 消息写入方式
Kafka 的消息写入使用的是 FileChannel,其代码截图如下:
并且在消息写入时使用了 transferTo 方法,根据网上的资料说 NIO 中网络读写真正是零拷贝的就是需要调用 FileChannel 的 transferTo或者 transferFrom 方法,其内部机制是利用了 sendfile 系统调用。
2.2 RocketMQ 消息写入方式
RocketMQ 的消息写入支持 内存映射 与 FileChannel 写入两种方式, 示例如下图所示:
2.3 消息写入方式对比
尽管 RocketMQ 与 Kafka 都支持 FileChannel 方式写入,但 RocketMQ 基于 FileChannel 写入时调用的 API 却并不是 transferTo,而是先调用 writer,然后定时 flush 刷写到磁盘,其代码截图如下:
为什么 RocketMQ 不调用 transerTo 方法呢,个人觉得和 RocketMQ 需要在 Broker 组装 MQ 消息格式有关,需要从网络中解码请求,传输到堆内存,然后对消息进行加工,最终持久化到磁盘相关。
自我介绍一下,小编13年上海交大毕业,曾经在小公司待过,也去过华为、OPPO等大厂,18年进入阿里一直到现在。
深知大多数Java工程师,想要提升技能,往往是自己摸索成长或者是报班学习,但对于培训机构动则几千的学费,着实压力不小。自己不成体系的自学效果低效又漫长,而且极易碰到天花板技术停滞不前!
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,真正体系化!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
如果你觉得这些内容对你有帮助,可以扫码获取!!(备注Java获取)
![img](https://i-blog.csdnimg.cn/blog_migrate/3a0fbe50a2e78f2bc8cc9028b2a8bcf9.jpeg)
最后
作为过来人,小编是整理了很多进阶架构视频资料、面试文档以及PDF的学习资料,针对上面一套系统大纲小编也有对应的相关进阶架构视频资料
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!
)]
[外链图片转存中…(img-uh0MnSt0-1712643207806)]
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取!