一文看懂消息中间件

在了解中间件以前，咱们先了解一下什么是同步？

首先咱们想一下，两个公司之间若是有互相调用接口的业务需求，若是没有引入中间件技术，是怎么实现的呢？

用户发起请求给系统A，系统A接到请求直接调用系统B，系统B返回结果后，系统A才能返回结果给用户，这种模式就是同步调用。

所谓同步调用就是各个系统之间互相依赖，一个系统发送请求，其余系统也会跟着依次进行处理，只有全部系统处理完成后对于用户来说才算完成了一次请求。只要其余系统出现故障，就会报错给用户。

那么引入中间件后，是如何作到异步调用的呢？

用户发起请求给系统A，此时系统A发送消息给MQ，而后就返回结果给用户，不去管系统B了。而后系统B根据本身的状况，去MQ中获取消息，获取到消息的时候可能已通过了1分钟甚至1小时，再根据消息的指示执行相应的操做。

那么想想，系统A和系统B互相之间是否有通讯？这种调用方式是同步调用吗？

系统A发送消息给中间件后，本身的工做已经完成了，不用再去管系统B何时完成操做。而系统B拉去消息后，执行本身的操做也不用告诉系统A执行结果，因此整个的通讯过程是异步调用的。

说到这里，咱们能够作个总结，消息中间件究竟是什么呢？

其实消息中间件就是一个独立部署的系统。能够实现各个系统之间的异步调用。固然它的做用可不止这些，经过它能够解决大量的技术痛点，咱们接下来会进行介绍。

消息中间件，总结起来做用有三个：异步化提高性能、下降耦合度、流量削峰。

异步化提高性能

先来讲说异步化提高性能，上边咱们介绍中间件的时候已经解释了引入中间件后，是如何实现异步化的，但没有解释具体性能是怎么提高的，咱们来看一下下边的图。

没有引入中间件的时候，用户发起请求到系统A，系统A耗时20ms，接下来系统A调用系统B，系统B耗时200ms，带给用户的体验就是，一个操做所有结束一共耗时220ms。

若是引入中间件以后呢？看下边的图。

用户发起请求到系统A，系统A耗时20ms，发送消息到MQ耗时5ms，返回结果一共用了25ms，用户体验一个操做只用了25ms，而不用管系统B何时去获取消息执行对应操做，这样比较下来，性能天然大大提升

下降耦合度

再来聊聊解耦的场景，看下图。

若是没有引入中间件，那么系统A调用系统B的时候，系统B出现故障，致使调用失败，那么系统A就会接到异常信息，接到异常信息后确定要再处理一下，返回给用户失败请稍后再试，这时候就得等待系统B的工程师解决问题，一切都解决好后再告知用户能够了，再从新操做一次吧。

这样的架构，两个系统耦合再一块儿，用户体验极差。

那么咱们引入中间件后是什么样的场景呢，看下面的流程：

对于系统A，发送消息后直接返回结果，再也不管系统B后边怎么操做。而系统B故障恢复后从新到MQ中拉取消息，从新执行未完成的操做，这样一个流程，系统之间没有影响，也就实现了解耦。

流量削峰

下面咱们再聊聊最后一个场景，流量削峰

假如咱们的系统A是一个集群，不链接数据库，这个集群自己能够抗下1万QPS

系统B操做的是数据库，这个数据库只能抗下6000QPS，这就致使不管系统B如何扩容集群，都只能抗下6000QPS，它的瓶颈在于数据库。

假如忽然系统QPS达到1万，就会直接致使数据库崩溃，那么引入MQ后是怎么解决的呢，见下图：

引入MQ后，对于系统A没有什么影响，给MQ发送消息能够直接发送1万QPS。

此时对于系统B，能够本身控制获取消息的速度，保持在6000QPS一下，以一个数据库可以承受的速度执行操做。这样就能够保证数据库不会被压垮。

固然，这种状况MQ中可能会积压大量消息。但对于MQ来讲，是容许消息积压的，等到系统A峰值过去，恢复成1000QPS时，系统B仍是在以6000QPS的速度去拉取消息，天然MQ中的消息就慢慢被释放掉了。

这就是流量削峰的过程。在电商秒杀、抢票等等具备流量峰值的场景下可使用这么一套架构。

最后

感谢你们看到这里，文章有不足，欢迎你们指出；若是你以为写得不错，那就给我一个赞吧。