开发者

RabbitMQ交换机使用场景和消息可靠性总结分析

目录
  • Rabbithttp://www.devze.comMQ的一些基本组件
  • 各种类型交换机的使用场景
    • 扇形交换机(Fanout)
    • 使用场景
    • 直连交换机(Direct)
    • 使用场景
    • 主题交换机(Topic)
  • 关于延时队列
    • 消息监听
      • 如何保证消息不重复消费
        • 消息可靠性如何保证

          RabbitMQ的一些基本组件

          • Producer:消息的生产者
          • Consumer:消息的消费者
          • Broker:MQ服务器,管理队列、消息
          • Message:消息,程序间通讯的数据
          • Queue:队列,消息存放的容器,消息先进先出
          • Exchange:交换机,用于分发消息

          各种类型交换机的使用场景

          扇形交换机(Fanout)

          发布/订阅模式,类似于广播,交换机将收到的消息发给多个队列,消费者如果订阅了这个队列的话,就可以收到生产者的消息。生产者不直接与编程队列绑定,而且将数据发送至交换机Exchange。

          扇形交换机不需要路由键,设置了也没有作用。

          使用场景

          如天气预报信息,生产者将天气预报信息发送到交换机,网易、新浪等门户通过各自队列绑定到该交换机,来获取推送的消息。

          扇形交换机发布一次可以让所有消费者收到,但有时候我们需要进行一些数据集筛选,比如我只想接收关于广东省的天气预报,其他省份的忽略,那么我们就需要用到路由js或者主题交换机模式。

          直连交换机(Direct)

          路由模式,通过路由键进行匹配,Exchange交换机会根据路由键(RoutingKey)有条件的将数据筛选后发送给队列

          使用场景

          日志收集系统,收集了info、warn、error三种类型日志,要发送给对应的队列做处理,如info队列做记录,warn和error队列在info队列基础上还要发送邮件给运维人员,那么可以创建一个直连交换机(Direct),然后绑定三个路由键:INFO、WARN、ERROR到三个队列。

          路由模式是一种精准匹配,只有设置了RoutingKey才可以分发消息,在实际应用中可能会有一些模糊匹配的情况,这时候我们可以用主题交换机来实现。

          主题交换机(Topic)

          在路由模式上增加了通配符,可以进行路由键的模糊匹配,更加灵活的进行消息分发

          通配符:*和#,*代表单个关键字,#代表多个关键字

          在实际使用场景中,路由模式的效率高于主题模式,所以可以使用路由模式的时候优先使用路由模式。

          关于延时队列

          在Rabbit MQ中实现延时队列有两种方式:

          使用官方提供的延时插件

          具体操作可以看我的这篇文章:docker-compose安装RabbitMQ及插件

          注意:这个插件的使用还是有一定的限制性,官方说:

          Current design of this plugin doesn't really fit scenarIOS w开发者_JAVA入门ith a high number of delayed messages (e.g. 100s of thousands or millions). See #72 for details.

          这个插件目前的设计并不适合有大量延迟消息的场景(例如10万或数百万)。详见第72条。

          所以在大消息场景下可以改用Kafka来实现。

          通过死信队列来实现

          如订单超时功能,创建两个交换机队列,一个订单超时消息,一个订单消息,订单超时消息不设置消费者,仅设置过期时间,这样在到期后会转发给一个交换机Exchange(我们设置为订单消息交换机),订单队列收到这个转发就会发送消息,由此曲线救国的来做到延时消息。

          但是死信队列有个大问题:当往队列放入一条过期时间是10秒的A消息,再放入一条过期时间是5秒的B消息,等待5秒后B消息并不会优先进入死信队列被消费,而是遵循队列先进先出规则,在10秒后A消息过期,A和B一起进入死信队列被消费。

          不过这个问题也好解决,就是固定这个死信队列的延时时间就好了,比如订单15分钟后超时,就全部订单都是15分钟后超时,不要有A订单10分钟超时,B订单5分钟超时的情况,

          消息监听

          通过监听消息,我们可以实现消息的确认,是一种实现消息可靠性的方案。

          如何保证消息不重复消费

          • 接口 做防重和幂等性保证
          • 保存唯一索引到Redis中,设置一个短一点的过期时间,消费消息前判断缓存中是否有数据,有就说明刚刚已经处理过了,这是一条重复消费

          消息可靠性如何保证

          • 生产者提供消息给消费者时使用消息确认机制
          • 消息服务器的队列、交换机都进行持久化,保证数据不丢失

          在消息可靠性上,没有方法可以保证完全绝对的可靠,所以必要的日志收集一定要做好,实时监控,在运维上也要下一些功夫。

          参考资料

          RabbitMQ六种工作模式与应用场景

          以上就是RabbitM编程Q交换机使用场景和消息可靠性总结分析的javascript详细内容,更多关于RabbitMQ交换机消息可靠性的资料请关注我们其它相关文章!

          0

          上一篇:

          下一篇:

          精彩评论

          暂无评论...
          验证码 换一张
          取 消

          最新开发

          开发排行榜