前提背景
大家都知道,市面上有许多开源的MQ,例如,RocketMQ、Kafka、RabbitMQ等等,现在Pulsar也开始发光,今天我们谈谈笔者最常用的RocketMQ和Kafka,想必大家早就知道二者之间的特点以及区别,但是在实际场景中,二者的选取有可能会范迷惑,那么今天笔者就带领大家分析一下二者之间的区别,以及选取标准吧!
架构对比
RocketMQ的架构
RocketMQ由NameServer、Broker、Consumer、Producer组成,NameServer之间互不通信,Broker会向所有的nameServer注册,通过心跳判断broker是否存活,producer和consumer 通过nameserver就知道broker上有哪些topic。
Kafka的架构
Kafka的元数据信息都是保存在Zookeeper,新版本部分已经存放到了Kafka内部了,由Broker、Zookeeper、Producer、Consumer组成。
Broker对比
主从架构模型差异:
维度不同
- Kafka的master/slave是基于partition(分区)维度的,而RocketMQ是基于Broker维度的;Kafka的master/slave是可以切换的(主要依靠于Zookeeper的主备切换机制)RocketMQ无法实现自动切换,当RocketMQ的Master宕机时,读能被路由到slave上,但写会被路由到此topic的其他Broker上。
刷盘机制
RocketMQ支持同步刷盘,也就是每次消息都等刷入磁盘后再返回,保证消息不丢失,但对吞吐量稍有影响。一般在主从结构下,选择异步双写策略是比较可靠的选择。
消息查询
RocketMQ支持消息查询,除了queue的offset外,还支持自定义key。RocketMQ对offset和key都做了索引,均是独立的索引文件。
消费失败重试与延迟消费
RocketMQ针对每个topic都定义了延迟队列,当消息消费失败时,会发回给Broker存入延迟队列中,每个消费者在启动时默认订阅延迟队列,这样消费失败的消息在一段时候后又能够重新消费。
- 延迟时间与延迟级别一一对应,延迟时间是随失败次数逐渐增加的,最后一次间隔2小时。
- 当然发送消息是也可以指定延迟级别,这样就能主动设置延迟消费,在一些特定场景下还是有作用的。
数据读写速度
- Kafka每个partition独