消息队列

使用场景

解耦、异步、削峰

相比串行处理,适用于点对多的广播场景
(开店成功 -> 通知商户、通知市场经理、创建审核工作流)
(下单 -> 扣商品库存、发红包、发短信通知)
(订单流程状态更新 -> 核对金额、状态信息)
(无效订单 -> 补偿退款、券等资源状态回退)
(秒杀、设置队列大小,顺序处理,队列满了,让前端进行排队,避免服务器被瞬间大流量冲垮)

如何保证消息队列的高可用

消费模式:

  • 点对点

    每个消息只有一个消费者,保证了消息的顺序消费。

  • 发布/订阅

    • pull模式

      客户端主动拉消息。按需消费,但有可能造成消息堆积。

  • push模式

    服务的主动推消息。实时性高,但需要管理消息的消费状态,做数据备份。

常见问题:

  1. 如何保证消息不被重复消费,保证消费的时候是幂等的

一个消费者 顺序消费。幂等:依赖redis Set(存放消费过的taskId)、建立数据库唯一键约束

  1. 保证消息传输的可靠性,消息丢失了的补偿措施?

  2. 消息堆积解决方案

  • 伸缩性
  • 可靠性
  • 可用性

各个队列的优缺点:

RabbitMQ ActiveMQ RocketMQ Kafka
所属社区/公司 Mozilia Publice License Apache Ali Apache
开发语言 Erlang Java Java Scala & Java
客户端支持语言 大多数的主流语言 大多数的主流语言 Java 大多数的主流语言
协议支持 多协议支持:AMQP,XMPP、SMTP、STOMP AMQP,XMPP、SMTP、STOMP 自定义,社区提供 JMS(不成熟) 自有协议,社区封装了HTTP协议支持
消息的批量操作 ✔️ ✔️ ✔️
消息推拉模式 PULL / PUSH PULL / PUSH PULL / PUSH PULL
高可用 master/slave模式,master提供服务,slave仅做备份 支持replica机制,leader宕掉后,备份自动顶替,并重新选举leader(基于Zookeeper)
数据可靠性 数据可靠,有slave做备份 数据可看到,有replica机制,有容错容灾能力
单机吞吐量

关注可靠性,AMQP协议支持点对点的订阅(路由)。

起源于Kafka,阿里对可靠性做了优化。ack机制

关注吞吐量,不支持事物。适用于高吞吐量的(ELK)日志收集。

本文标题:消息队列

文章作者:NibNait  

发布时间:2019年06月21日 - 21:06

最后更新:2019年08月25日 - 22:08

原始链接:https://tianbin.org/learning/mq/

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

0%