rabbitmq、kafka、rocketMQ区别和选择

╰半夏微凉° 2023-01-19 14:51 7阅读 0赞

### 文章目录 ###

*  rabbitMQ和kafka
 *  kafka和rocketMQ
 *  rabbitMq和rocketMQ
 *  MQ选型
 *  消息队列常使用的注意事项
 *   *  如何保证系统的高可用
     *  如何保证消息不会丢失
     *   *  rabbitmq
         *  rocketMq

# rabbitMQ和kafka #

*  语言  
    kafka使用scala写的，rabbitmq使用erlang写的，rocketMQ使用java写的
 *  消费模型  
    RabbitMQ中pull和push都有实现，kafka和rocketMQ中只有pull
 *  架构组成  
    rabbtmq是基于AMQP协议开发，broker由exchange、binding、queue组成  
    kafka采用mq结构，broker有分区的概念。所以可以更好的伸缩性，支持横向扩展。
 *  吞吐量  
    kafka具有更高的吞吐量，内部采用消息的批量处理机制，使用的零拷贝机制，消息处理效率高。
 *  集群  
    kafka的集群可以通过zk来管理。rabbitmq要通过第三方的haproxy和keeplive来实现
 *  延迟队列  
    rabbitmq支持延迟消息，kafka不支持。
 *  路由分发  
    路由的分发上，rabbit有通配符更加灵活。  
    消息的留存上，kafka消费完了消息会保留，rabbitmq消费完了就回删除。kafka可以设置retention，清理消息。
 *  Kafka功能比较的单一, 主要的就是支持收发消息，没有延迟消息实现
 *  选择上  
    选择rabbitMQ情况，高级灵活的路由规则，需要延迟队列的支持。更简单的消费者实现。高级容错能力，保证消息不丢失，消费消息可以手动返回basicACK，保证消息正确消费。  
    选择kafka情况：严格的消息顺序（同一个partition的消息时有序的），延长消息的留存时间，需要高伸缩的能力。

# kafka和rocketMQ #

*  消息保存  
    rocketmq每个broker的消息是统一存储在一个commitlog文件中，kafka是每个分区partition保存一定量的消息。
 *  注册中心  
    kafka可以用使用zk统一管理broker，rocketmq使用的是一个namesever.

>  *  引申 nameserver工作原理？ 每个节点启动会遍历namesever，注册自己的信息，每个30秒发送心跳到到nameserver，nameserver每隔10秒检查一下，各个broker的心跳发送时间，超过120没有心跳，就认为挂掉，从路由消息里面移除
>  *  rockemq引申为什么不用zk呢? rocketmq早期也用了zk，后面为了去掉zk依赖，采用了自己的nameserver，使服务更加轻量级，也减少了维护成本。

*  主从同步机制  
    kafka的消息同步是基于binlog实现，向主服务器发送同步时间，主服务器将binlog文件返回从服务器，从服务器执行binlog文件里面的指令，达到消息同步  
    rocketmq主从同步是，slave向master发送当前commitlog文件中的最大偏移量，master开始准备还未同步的数据，返回给slave，slave将数据同步，同时更新最大偏移量。
 *  刷盘持久化  
    rocketMQ支持同步刷盘，每次消息写入都同步刷盘，保证数据可靠性，但是影响吞吐量。一般采用异步刷盘，同步双写。同步双写是指，消息同时写入master和slave的缓存中，才返回客户端成功，接着再异步刷盘持久化 ，可以保证数据不丢失（不然master故障后，有可能造成数据丢失）。  
    kafka都是异步刷盘。返回的ack有三种，0-生产者不等待broker的ack，继续发送消息 1- 等待leader落盘返回 -1-主从全部落盘才返回ack
 *  吞吐量  
    kafka的吞吐量更大
 *  延迟消息  
    rocketmq支持延迟消息。
 *  消费消息  
    rocketMQ查询更加灵活，除了queue的offset外，还可以指定key，查询适配的消息
 *  消费实时性  
    kafka是通过轮询拉取消息，实时性取决轮询间隔。  
    rocketmq是通过长连接方式，当有新消息时候，就立即拉取，实时性比较高。

# rabbitMq和rocketMQ #

*  rabbitMQ吞吐量很低，一秒只有几万的样子，横向扩展比较麻烦。采用erlang语言开发，不便于查找问题和维护。如果流量比较平稳，没有特别高的并发量，选择rabbitMQ足够。
 *  rocketMQ吞吐量更高，采用了类似分片思想message queue，支持容量的横向扩展。如果公司发展迅猛，流量爆发式增加，又想使用一些高级功能，比如延迟消息，可以使用rocketMQ。
 *  rabbitMQ和rocketMQ都可以保证消息不丢失  
    rabbitMQ通过开启手动ACK、发送者确认模式保证消息不丢失。  
    rocketMQ通过开启同步双写、同步刷盘的形式实现消息不丢失，但是同步刷盘性能较低。一般是采用的同步双写，异步刷盘（异步刷盘可能在broker宕机情况下，消息丢失）

# MQ选型 #

1.  如果我们业务只是做一些收发消息的单一需求，允许丢失消息的可能，但是又要求极高的吞吐量和高性能的话，就采用kafka，就比如日志收集，数据监控
2.  如果公司业务平稳，没有巨大的并发量，也没有改源码的需求，可以选择用rabbitMQ
3.  如果公司发展迅猛，经常搞一些秒杀活动，可以直接一步到位使用RocketMQ。  
    [参考][Link 1]

# 消息队列常使用的注意事项 #

## 如何保证系统的高可用 ##

*  就rabbitMq而言，有镜像模式概念，就是用户在发送数据时候，发送到mq机器上，并且持久化磁盘，然后通过设置镜像的queue，把数的持久化地址对应表同步到另外mq机器上。这种就有效防止一台mq挂了以后，另外的mq可以直接对外提供消费功能。
 *  就rocketMq而言，分为多主集群结构，多主多备异步复制结构，多主多备同步复制结构。

## 如何保证消息不会丢失 ##

### rabbitmq ###

*  就rabbitmq而言，从生产者，消费者，消息队列角度分析。生产者而言，发送消息如果失败，则定义重试次数，一般设置成五次。两种解决方式1.通过设置事务模式，进行事务回滚重试。2.通过发送者异步确认确认模式开启。  
    就mq本身而言，需要做队列的持久化到磁盘的操作
 *  对于exchange，还可以发送到备份交换机，或者将失败消息返回给生产者
 *  开启消费者手动确认模式，保证成功消费了，再删除消息
 *  总结就是一句话：发送者确认模式开启，消息持久化默认开启，消费者消费开启手动ack

### rocketMq ###

*  rocketMq而言，就是开始同步双写（master和slave同时写入缓存成功然后返回ack），异步刷盘（极端情况服务器突然宕机的情况，会丢失数据。如果要保证消息绝对不丢失，就开启同步刷盘，但是吞吐量会降低）
 *  消费阶段，消费成功返回ConsumeConcurrentlyStatus.CONSUME\_SUCCESS 状态给 Broker。没有返回的就可以继续消费。
 *  这里要注意实现消息的幂等性，可以给消息定义唯一键，防止消息重复

[Link 1]: https://zhuanlan.zhihu.com/p/94661785