Kafka与RocketMq比较

目录

前言

Kafka与RocketMQ的比较

一.架构设计

二.数据可靠性

三.性能对比

四.消息

投递实时性

五.消费失败重试

六.严格的消息顺序

七.定时消息

八.消息事务

九.故障恢复

十.使用场景

---

前言

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的比较

一.架构设计

二.数据可靠性

三.性能对比

四.消息投递实时性

五.消费失败重试

 六.严格的消息顺序

 七.定时消息

八.消息事务

九.故障恢复

十.使用场景

---

投递实时性

• 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则更适用于流量的削峰处理和更多复杂的业务场景。

如有描述理解错误，请大家指出交流！

最后的最后，觉得文章对你有用的小伙伴，留个关注和点赞吧，谢谢支持！