ActiveMQ学习——为什么要引入MQ

目录

为什么要引入MQ？

系统之间直接调用实际工程落地和存在的问题

系统之间接口耦合比较严重

面对大流量并发时，容易被冲垮。

等待同步存在性能问题

解决问题需要在设计系统时达到的目标

为什么要引入MQ？

解耦、削峰、异步

        从生活例子来看，如当一个班上的学生去问老师问题时，没有MQ的情况下，问问题需要排队进行，当为第一个学生解答完后才能解答后面同学的问题，才能为第二个同学解答问题，这个过程中，在后面排队的同学都处于等待的状态，因此效率很低；同时当一个班的学生很多时，老师不可能一直处于为学生解答问题的状态，老师也会劳累。当有MQ之后，相当于班上选出了一个班长，班长负责将同学的问题收集起来，而同学只需要将问题按照规定的格式写在纸上交给班长，最后由班长一张张地把问题交给老师，这样学生不用因为问题没有解决而一直处于等待状态，当人数很多，问题很多时也可以先暂时存储起来，不会因为老师要不停地处理而劳累，最后上午没解答完的问题可以下午再解答，实现了异步操作，学生的问题也不用直接交给老师，降低了耦合，这就是MQ的好处，简记为解耦、削峰、异步。

系统之间直接调用实际工程落地和存在的问题

        微服务架构后，链式调用是我们写程序时的一般流程，为了完成一个整体功能我们会将其拆分为多个函数或者子模块，比如模块A去调用模块B，模块B再去调用模块C，以此类推，但在大型分布式应用中，系统之间的RPC交互繁杂，这样会有很多问题。

系统之间接口耦合比较严重

        每新增一个下游功能，都要对上游的相关接口进行改造。例如：系统A要将数据给系统B和C，因为发给每个系统的数据可能会有差异，因此系统A需要对发送给每个系统的数据进行一次组装，然后逐一发送。当代码上线后新增需求系统D也要接收A系统的数据，此时又需要修改A系统中的代码，这样开发连调的效率很低。

面对大流量并发时，容易被冲垮。

        每个接口模块的吞吐能力是有限的，在大流量来临时可能会被冲垮。比如说秒杀业务操作，对于上游只有一个发起下单购买的操作，而下游系统需要完成的秒杀业务逻辑有：读取订单、库存检查、库存冻结、余额检查、余额冻结、订单生成、余额扣减、库存扣减、生成流水、余额解冻、库存解冻。

等待同步存在性能问题

        RPC接口基本上是同步调用，整体的服务性能遵循“木桶理论”，即整体系统的耗时取决于链路中最慢的那个接口，比如A调用B/C/D都是50ms，但此时B又调用了B1，花费2000ms，那么久直接拖累了整个服务性能。

解决问题需要在设计系统时达到的目标

1.要做到系统解耦，在新模块接进来时，可以做到代码改动很小，能够解耦
2.设置流量缓冲池，可以让后代系统按照自身吞吐能力进行消费，不被冲垮，能够削峰。
3.强调依赖梳理能将非关键调用链路的操作异步化并提升整体系统的吞吐能力，能够异步。

这篇好文章是转载于：学新通技术网