消息队列


1. 什么是消息队列

核心 3 个优点: 解耦、异步、削峰

  1. 解耦

    场景:A 系统发送数据到 BCD 三个系统,如果 E 系统也要这个数据呢?那如果 D 系统现在不需要了呢?

    ![image]()

    在这个场景中,A 系统跟其它各种乱七八糟的系统严重耦合。A 系统产生数据,发送到 MQ 中,哪个系统需要去 MQ 里面消费,如不需要就取消消费即可。A 不需要考虑给谁发数据,不需要维护代码,也不需要考虑是否调用成功、失败超时等情况。

  2. 异步

    场景:,A 系统接收一个请求,需要在自己本地写库,还需要在 BCD 三个系统写库,自己本地写库要 3ms,BCD 三个系统分别写库要 300ms、450ms、200ms,最终请求总延时是 3 + 300 + 450 + 200 = 953ms,接近 1s。用户通过浏览器发起请求,等待个 1s,这几乎是不可接受的。

    ![image]()

    将 A 系统连续发送 3 个MQ 队列中,异步执行,假如耗时 5ms,A 系统从接受一个请求到返回响应给用户,总时长是 3 + 5 = 8ms

  3. 削峰

    场景:如MySQL每秒可以接收2K请求, 在某一时间段内达到5K时,导致系统崩溃。

    将每秒5K请求写入 MQ 中,A 系统从 MQ 中慢慢拉取请求,每秒拉取2K个请求。不要超过自己每秒能处理的最大请求数量

新加进来的 MQ ,怎么保证不重复消费。

搞一个唯一约束,当前消息不可重复消费,消费不了的信息,记录日志以后处理

如何保证信息可靠传输

生产者丢失数据开启事务,开启 confirm 维护一个ID值

MQ 丢失数据开启持久化

消费端丢失数据开启ACK机制

参考连接

![image]()

声明:该文章系转载,转载该文章的目的在于更广泛的传递信息,并不代表本网站赞同其观点,文章内容仅供参考。

本站是一个个人学习和交流平台,网站上部分文章为网站管理员和网友从相关媒体转载而来,并不用于任何商业目的,内容为作者个人观点, 并不代表本网站赞同其观点和对其真实性负责。

我们已经尽可能的对作者和来源进行了通告,但是可能由于能力有限或疏忽,导致作者和来源有误,亦可能您并不期望您的作品在我们的网站上发布。我们为这些问题向您致歉,如果您在我站上发现此类问题,请及时联系我们,我们将根据您的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。