RabbitMQ 实战系列博客所写内容均来自于作者多年来中项目的实践，写此系列的初衷源于对自己多年的工作内容进行总结，也希望能给读到本系列文章的您一点点的帮助和启发。
本篇博文讲解的是 RabbitMQ 实战之 消息传递，那么下面我从这四个方面展开讲解：
一、场景引入，问题初现
很多读者期待的是先讲段理论、原理啥的，然而我的写文章的逻辑习惯性的是想将问题的背景引入，用真实的案例来寻寻渐进。
- 我的老上家是一家创业型的B2B方向建材互联网企业，从 0 到 1 组建了一支10 人的小型研发团队。
- 在入职的第二天被告知要在一个半月内上线WEB网站和APP两个端项目，项目启动的时候我们就两个JAVA，我们商量着如何启动项目，如何快速进入开发，快速完成任务。
- 最终我们选用了SpringBoot + Dubbo 架构来进行开发。
- 一段时间没日没夜的加班，好不容易核心业务系统给做出来了，平时正常QA测试没发现什么大毛病，感觉性能还不错，一切都很完美。
然后系统就这么上线了，一开始业务复杂度低，用户规模小，系统上线一段时间，注册用户量 5万+，日活平均 1 千用户。
每天都有新的数据进入数据库的表中，就这么日积月累的，没想到数据规模居然慢慢吞吞增长到了单表几百万。
这个时候呢，看起来也没太大的毛病，就是有运营人员反应，文章推送功能反应比较慢，页面上的 loading 要转个 10 来分钟才消失。
这是为啥呢？
推送的业务场景多样，多表关联。
项目数据库还没有设计好索引，或者是设计了索引，但无奈负责该模块的小弟采用串行编码，导致整方法执行完，等待时间过长。
二、扬汤止沸，饮鸩止渴
一般碰到这种事情，一大堆代码性能问题，80%的工程师首先想到的大多是采用多线程进行编码。
后来仔细梳理现有业务场景，很多场景需要做消息的传递工作，这个时候就想着有什么方式能进行消息的传递工作，自然而然选择引入消息队列。
三、追本溯源，治标治本
考虑消息中间件的引入主要是保证系统的可用性，所以消息队列的引入很好的解决了系统的性能问题。
引入消息队列后，整体流程如图所示。
同样的功能，将业务逻辑分到三个系统处理：
终于系统上线，运营人员反馈该功能体验很好，为他们节省了大量时间。
四、总结全文，回眸再看
本文主要是针对实战业务中场景出现的实际问题，从系统架构上进行优化，引入MQ帮助系统进行消息的传输功能， 从而让各个服务只关注各自的实现，达到系统解耦的功效；另一方面主要是提高了系统性能，保证系统的稳定运行，让用户体验更好。
本文地址：https://blog.csdn.net/talioth/article/details/85935510
如对本文有疑问， 点击进行留言回复！！
我要评论
网友评论