前言
MQ全称 Message Queue,也就是消息队列,是应用程序之间的通信方法。
MQ使用的业务场景:
- 业务异步解耦
- 解耦微服务
- 流量削峰
- 消息分发
- 分布式事务的数据一致性
Kafka与RocketMQ的比较
一.架构设计
Kafka和RocketMQ都是基于发布/订阅模式的消息系统,但是在架构上有如下不同:
**Kafka: **
- Kafka的架构相对简单,主要有Producer,Consumer和Kafka集群三个组件组成。
- Producer将消息发布到Kafka集群中的Broker节点,然后Consumer从Broker节点中获取消息进行消费。
- 此外Kafka的数据模型是基于Topic和Partition的,每个Topic可以在多个Partition,每个Partition可以在多个Broker节点上复制,保证数据的高可用性。
RocketMQ:
- RocketMq架构相对复杂,主要有NameServer,Broker,Producer,Consumer四个角色组成。
- NameServer主要负责服务注册和发现,Broker节点负责存储和传输消息,Producer负责将消费发送到Broker,Consumer从Broker节点中获取消息进行消费。
- RocketMQ也是基于Topic和Partition的数据模型,但是它采用的是一种主从复制的机制,确保了数据的高可用性和容错性。
二.数据可靠性
RocketMQ支持异步实时刷盘,同步刷盘,同步Replication,异步Replication。
Kafka使用异步刷盘方式,异步Replication
RocketMQ的同步刷盘在单机可靠性上比Kafka更高,因为不会因为操作系统Crash,导致数据丢失。
Kafka和RocketMQ都是高可靠性的消息系统,但是他们在可靠性上还是有一定差异:
在数据可靠性方面,Kafka表现更为出色,主要是因为Kafka在Broker的数据模型存储上采用了多副本机制,每个Partition都有多个副本,当某个Broker节点失效时,可以通过其他的副本来保证数据的可用性。而RocketMQ采用则是主从复制的特性,当主节点失效时,需要进行主节点选举才能保证保证数据的可用性,在这个进行选举的期间就会存在着一定的延迟,而延迟则就可能会导致消息的丢失。
三.性能对比
消息大小都以10个字节为例。
- Kafka单机写入TPS约在百万条/m。
- RocketMQ单机写入TPS单实例约7万条/m,单机部署3个Broker的情况下,可以高达12万/m。
Kafka和RocketMQ都是高吞吐,低延迟的消息系统,以下是他们之间的差异:
在吞吐量方面,Kafka表现更加出色。Kafka的使用顺序写磁盘的方式存储消息,因为这一特性,可以达到非常高的吞吐量,而且在读取方面也能够达到非常高的性能。RocketMQ虽然也使用了顺序写磁盘的方式存储消息,但是其读取性能会不如Kafka,尤其是在批量处理的情况下。
在延迟方面,不得不提及RocketMQ的表现十分出色,RocketMQ通过采用 零 Copy技术和缓存池技术来降低延迟,而Kafka则是通过批量发送和异步处理的方式来提高吞吐量,但相应的会增加一定的延迟。
四.消息
投递实时性
- Kafka使用短轮询方式,实时性取决于轮询间隔时间。
- RocketMQ使用长轮询,同Push方式实时性一致,消息的投递延迟通常在2-5ms之内。
五.消费失败重试
- Kafka消费失败不支持重试。
- RocketMQ消费失败支持定时重试,每次重试间隔时间顺延。
在这里就要提出RocketMQ的强大重试机制,举例这样一个场景:
A服务为下单服务,B服务为积分服务,A服务此时调用下单一系列功能完成后,为了进行流量的削峰处理,此时我们引入MQ的中间件,A服务生产消息,发送至MQ中,B服务去消费消息,进行积分服务一系列功能处理。 但是这个B服务尝试去从MQ去消费这个过程,由于网络或者B服务延迟问题,导致MQ的这条消息消费失败。
此时引用RocketMQ利用MQ的消费失败重试机制,就可以很好的处理这个问题,但是Kafka并不能。
RocketMQ可在broker.conf文件中配置Consumer端的重试次数和重试时间间隔,如下:
messageDelayLevel=1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h
六.严格的消息顺序
- Kafka支持消息顺序,但是一台Broker宕机后,就会发生消费错乱。
- RocketMQ则是严格按照的顺序,即使一台Broker宕机后,消息会发送失败,但是不会错乱。
七.定时消息
- Kafka并不支持定时消息。
- RocketMQ支持定时消息。
八.消息事务
- RocketMQ自身提供了一套完整的消费事务机制,能够确保消息在发送和接收过程中的一致性和可靠性,能够保证消息在发送和接收过程中的一致性和可靠性。
- Kafka的事务官方并没有支持,需要自行去处理。
九.故障恢复
- Kafka支持自动的故障转移和数据复制机制,能够快速的恢复节点的可用性,保证数据的连续性。
- RocketMQ在低版本只能手动去干预,在高版本(4.5)以后,自动切换和手动切换都具备。
十.使用场景
- Kafka更适用于对于海量数据的处理,在日志领域比较成熟。
- RocketMQ则更适用于流量的削峰处理和更多复杂的业务场景。
如有描述理解错误,请大家指出交流!
最后的最后,觉得文章对你有用的小伙伴,留个关注和点赞吧,谢谢支持!
版权归原作者 `不然 所有, 如有侵权,请联系我们删除。