Redis和RabbitMQ做消息队列的区别

可靠消费

Redis:没有相应的机制保证消息的消费,当消费者消费失败的时候,消息体丢失,需要手动处理

RabbitMQ:具有消息消费确认,即使消费者消费失败,也会自动使消息体返回原队列,同时可全程持久化,保证消息体被正确消费

可靠发布

Reids:不提供,需自行实现

Redis的消息队列,如果在从队列pop出去的时候,worker处理失败的话,数据不会回到队列中,需要从业务中手动把失败的处理数据push到队列中;

RabbitMQ:具有发布确认功能,保证消息被发布到服务器

RabbitMQ有一个消息确认机制来保证消息的不丢失:客户端从队列中取出消息之后,可能需要一段时间才能处理完成,如果在这个过程中,客户端出错了,异常退出了,而数据还没有处理完成,那么非常不幸,这段数据就丢失了,因为RabbitMQ默认会把此消息标记为已完成,然后从队列中移除。

消息确认是客户端从RabbitMQ中取出消息,并处理完成之后,会发送一个ack告诉RabbitMQ,消息处理完成,当RabbitMQ收到客户端的获取消息请求之后,或标记为处理中,当再次收到ack之后,才会标记为已完成,然后从队列中删除。当RabbitMQ检测到客户端和自己断开链接之后,还没收到ack,则会重新将消息放回消息队列,交给下一个客户端处理,保证消息不丢失,也就是说,RabbitMQ给了客户端足够长的时间来做数据处理。

高可用

Redis:采用主从模式,读写分离,但是故障转移还没有非常完善的官方解决方案

RabbitMQ:集群采用磁盘、内存节点,任意单点故障都不会影响整个队列的操作

持久化

Redis:将整个Redis实例持久化到磁盘

RabbitMQ:队列,消息,都可以选择是否持久化

消费者负载均衡

Redis:不提供,需自行实现

RabbitMQ:根据消费者情况,进行消息的均衡分发

队列监控

Redis:不提供,需自行实现

RabbitMQ:后台可以监控某个队列的所有信息,(内存,磁盘,消费者,生产者,速率等)

流量控制

Redis:不提供,需自行实现

RabbitMQ:服务器过载的情况,对生产者速率会进行限制,保证服务可靠性

总结

redis: 轻量级,低延迟,高并发,低可靠性;
rabbitmq:重量级,高可靠,异步,不保证实时;
rabbitmq是一个专门的AMQP协议队列,他的优势就在于提供可靠的队列服务,并且可做到异步,而redis主要是用于缓存的,redis的发布订阅模块,可用于实现及时性,且可靠性低的功能。

猜你喜欢

转载自blog.csdn.net/qq_43141726/article/details/120560864