redis发布订阅模式下实现消息队列和rabbitmq的对比

 redisrabbitmq
可靠性没有相应的机制保证消息的可靠消费,如果发布者发布一条消息,而没有对应的订阅者的话,这条消息将丢失,不会存在内存中具有消息消费确认机制,如果发布一条消息,还没有消费者消费该队列,那么这条消息将一直存放在队列中,直到有消费者消费了该条消息,以此可以保证消息的可靠消费
实时性redis作为高效的缓存服务器,所有数据都存在在服务器中,所以它具有更高的实时性 
消费者负载均衡发布订阅模式,一个队列可以被多个消费者同时订阅,当有消息到达时,会将该消息依次发送给每个订阅者队列可以被多个消费者同时监控消费,但是每一条消息只能被消费一次,由于rabbitmq的消费确认机制,因此它能够根据消费者的消费能力而调整它的负载
持久性redis的持久化是针对于整个redis缓存的内容,它有RDB和AOF两种持久化方式(redis持久化方式,后续更新),可以将整个redis实例持久化到磁盘,以此来做数据备份,防止异常情况下导致数据丢失。队列消息都可以选择性持久化,持久化粒度更小,更灵活;
队列监控redis没有所谓的监控平台。rabbitmq实现了后台监控平台,可以在该平台上看到所有创建的队列的详细情况,良好的后台管理平台可以方面我们更好的使用;

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

  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 2
    评论
#秒杀技术重新梳理 ##redis分布式锁 >首先要了解的乐观锁是什么? > 数据库乐观锁,数据库增加一个版本标识 >redis乐观锁通过watch命令监视给定的key,当exec时候如果监视的key从调用watch后发生过变化,则整个事务失败。也可以调用watch多次监听 >多个Key。 > >Redis事务是一组命令的集合。主要用到两个multi和exec命令。事务开始时向redis服务器发送multi命令,然后依次发送需要在本次事务中处理 >的命令 >1.multi,开启redis的事务 >2.exec,提交事务,执行从multi到此命令前的命令队列 >3.discard,取消事务 >4.watch,监视键值对 ##rabbitmq与kafka的区别 - 为什么要使用消息队列 >解耦:将消息写入消息队列,需要消息的系统从消息队列订阅 >异步:非必要的业务逻辑以异步方式进行,加快速度 >削峰:不直接访问数据库 - 消息队列的缺点 >系统可用性降低:消息队列可能会挂掉 >系统复杂性增加:加入了消息队列,要考虑一致性问题,如何保证消息不被重复消费,如何保证消息可靠性传输 - rabbitmq >建议中小型公司使用,这种公司数据量不是很大,管理界面很方便,功能完善,社区活跃 - redis >它的pub-sub模式是快产快消的的,全都是因为redis是使用内存来做存取,所有一旦被消费就会丢弃 > >这样的场景可以考虑使用redis:对速度十分看重,允许出现消息丢失的场景,数据量不是很大,不需要保存消息 - kafka >稳定,可以保存,不会丢失数据,速度不需要很快,需要处理的数据量很大,可以进行日志采集 - rocketMq >是java语言开发的,和kafka一样支持分布式架构,可用性和单机吞吐量很高 - 消息不被重复消费(保证消息幂等性) > 正常情况下,消费者在消费完毕时,会发送一个确认消息给消息队列消息队列就知道消息被消费了,就会将该消息从消息队列中 >删除。不同的消息队列发出的确认消息形式不同,rabbitmq发送的是一个ack确认消息,rocketmq是返回的一个consume_success成功 >标志,kafka则是有个offet的概念。 > >造成重复消息的原因是因为网络传输的故障导致确认消息没有传送到消息队列,导致消息队列不知道自己已经消费这个消息,会再次将 >这个消息发送给消费者 > >解决的思路分为三种情况:第一个是你拿到这个消息做数据库的insert操作,给这个消息做一个唯一的主键; >第二种情况比如你拿这个消息做redis的set操作,那么就不用操作,因为这个操作本身就是幂等的。 >第三种情况可以准备第三方的介质来做消费记录。拿redis举例,给消息分配一个全局id,只要是消费过该记录将<id,message>以k-v键值对的形式写入redis。在消费者开始消费 >消息之前,查看是否存在消费记录。 - 如何保证消费的可靠性传输 >换种说法就是保证消费不能丢失,无法做到可靠性传输会造成上千万损失? > >要保证可靠性传输需要从三个角度来考虑:第一是生产者弄丢了数据,第二是消息队列弄丢了数据,第三是消费者弄丢了数据 > >第一种情况rabbitmq提供了transaction和confirm模式来确保生产者不会丢失消息 >transaction机制是说发送消息前,开启事务(channel.txSelect()),然后再发送消息,如果发送消息的过程中出现什么异常就回滚 >(channel.txRollback()),如果发送成功就提交事务。这种发送的一个缺点是吞吐量下降. >一般使用的是confirm模式居多,所有在信道上发送的消息都会被指派一个唯一的id,一旦消息被投递到指定的消息队列中去就会发送一个 >ack给生产者,如果没有则发送nack给生产者 > >第二种情况是持久化磁盘,具体是将queue的持久化标识durable设置为true,则代表是一个持久的队列,发送消息的时候讲deliveryMode=2 > >第三是主要消费者采取的是自动确认消息模式?可以改成手动确定的模式,但是这样会造成消息重复消费的情况,主要是看guide的文章发现的 >下面评论的大神解决方案是手动维护偏移量,处理完业务逻辑在提交偏移量,为了保证不造成重复消费,可以将处理业务逻辑和提交偏移量绑定一个事务 > ##redis资源池必须及时关闭

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值