rabbitmq实战_RabbitMQ 实战系列之：消息传递

一、场景引入，问题初现

很多读者期待的是先讲段理论、原理啥的，然而我的写文章的逻辑习惯性的是想将问题的背景引入，用真实的案例来寻寻渐进。

我的老上家是一家创业型的B2B方向建材互联网企业，从 0 到 1 组建了一支10 人的小型研发团队。在入职的第二天被告知要在一个半月内上线WEB网站和APP两个端项目，项目启动的时候我们就两个JAVA，我们商量着如何启动项目，如何快速进入开发，快速完成任务。最终我们选用了SpringBoot + Dubbo 架构来进行开发。一段时间没日没夜的加班，好不容易核心业务系统给做出来了，平时正常QA测试没发现什么大毛病，感觉性能还不错，一切都很完美。

然后系统就这么上线了，一开始业务复杂度低，用户规模小，系统上线一段时间，注册用户量 5万+，日活平均 1 千用户。

每天都有新的数据进入数据库的表中，就这么日积月累的，没想到数据规模居然慢慢吞吞增长到了单表几百万。

这个时候呢，看起来也没太大的毛病，就是有运营人员反应，文章推送功能反应比较慢，页面上的 loading 要转个 10 来分钟才消失。

这是为啥呢？

• 推送的业务场景多样，多表关联。
• 项目数据库还没有设计好索引，或者是设计了索引，但无奈负责该模块的小弟采用串行编码，导致整方法执行完，等待时间过长。

二、扬汤止沸，饮鸩止渴

一般碰到这种事情，一大堆代码性能问题，80%的工程师首先想到的大多是采用多线程进行编码。

后来仔细梳理现有业务场景，很多场景需要做消息的传递工作，这个时候就想着有什么方式能进行消息的传递工作，自然而然选择引入消息队列。

三、追本溯源，治标治本

考虑消息中间件的引入主要是保证系统的可用性，所以消息队列的引入很好的解决了系统的性能问题。

引入消息队列后，整体流程如图所示。
同样的功能，将业务逻辑分到三个系统处理：

• 文章推送服务只需要对文章进行保存，然后将文章ID Provider 到 MQ 的 new_article 队列中。
• 业务查询服务主要是 Consumerr MQ 中 new_article 队列中各种条件进行筛选聚合，并叫结果 Provider 到 MQ 的 push_article 队列中。
• 消息推送服务主要是 Consumer MQ 中 push_article 队列中用户集合进行push。

终于系统上线，运营人员反馈该功能体验很好，为他们节省了大量时间。

四、总结全文，回眸再看

本文主要是针对实战业务中场景出现的实际问题，从系统架构上进行优化，引入MQ帮助系统进行消息的传输功能， 从而让各个服务只关注各自的实现，达到系统解耦的功效；另一方面主要是提高了系统性能，保证系统的稳定运行，让用户体验更好。