消息中间件种类
- 消息是一种在应用间传送的数据。消息类型可以随意。
- 消息是 指不同系统之间进行交互作用与通讯利用的一种方式。
- 它只关注于数据的发送和接收，并且利用高效的异步机制进行数据平台无关的数据传输(交流)，并基于数据集群集成分布式系统。
通俗易懂的说 消息中间件是将系统和系统之间的交互方式进行存储和管理的一种技术。类似于容器。
先了解什么是同步？借鉴前辈
看图先知 两个系统 如果有互相调用接口的业务需求，如果没有引入消息中间件技术，是怎么实现的？
通讯特征 一个系统发送请求，其他系统也会跟着依次进行处理，所有系统处理完毕后对于用户才是进行了一次请求。只要其他系统出现故障，就会给出不友好的错误提示。 用户体验不佳 数据一致性
使用中间件后，如何做到异步调用呢？
看图先知
通讯特征 用户发起请求给系统A，此时系统A发送消息给MQ，然后就返回结果给用户，不去管系统B了。然后系统B根据自己的情况，去MQ中获取消息，获取到消息的时候可能已经过了1分钟甚至1小时，再根据消息的指示执行相应的操作。 系统间解耦 各尽其职
系统A和系统B互相之间是否有通信？这种调用方式是同步调用吗？
系统A发送消息给中间件后，完成了工作，不再去管系统B什么时候完成工作。 而系统B拉取消息后，自己也不会告诉A执行结果，所有整个通讯过程是异步的调用。 异步通信调用
消息中间件其实可以理解为一个独立部署的系统，可以实现各个系统的异步调用，
它的作用也远不止这些，它可以解决大量的业务场景所带来的问题和痛点。
消息中间件作用 借鉴前辈
- 异步化提升性能
- 降低系统耦合度
- 流量削峰
异步化提升性能
看图先知 未使用中间件
图文解答 用户发起请求到系统A，系统A耗时50ms，接下来系统A调用系统B，系统B耗时500ms， 带给用户的体验就是，一个操作全部结束一共耗时550ms 耗时 系统耦合高
看图先知 使用中间件
图文解答 用户发起请求到系统A，系统A耗时50ms，发送消息到MQ耗时5ms，返回结果一共用了55ms，用户体验一个操作只用了55ms，而不用管系统B什么时候去获取消息执行对应操作，这样比较下来，性能自然大大提高 优化系统间消息传输与消费
降低系统耦合度
看图先知 未使用中间件
图文解答 那么系统A调用系统B的时候，系统B出现故障，导致调用失败，那么系统A就会接到异常信息，接到异常信息后肯定要再处理一下，返回给用户失败请稍后再试，这时候就得等待系统B的工程师解决问题，一切都解决好后再告知用户可以了，再重新操作一次 用户体验极差 高耦合
看图先知 使用中间件
图文解答 系统A发送消息后直接返回结果，不再管系统B后边怎么操作。而系统B故障恢复后重新到MQ中拉取消息，重新执行未完成的操作，这样一个流程，系统之间没有影响，也就实现了解耦。 系统间解耦 无须再重复操作
流量削峰
看图先知 未使用中间件
图文解答 假如我们的系统A是一个集群，不连接数据库，这个集群本身可以抗下2万QPS 系统B操作的是数据库，这个数据库只能抗下8000QPS，这就导致无论系统B如何扩容集群，都只能抗下8000QPS，它的瓶颈在于数据库。 了解 吞吐量（TPS）、QPS、并发数、响应时间（RT） 扩充集群无效数据库QPS瓶颈
看图先知使用中间件
图文解答 引入消息中间件后，对于系统A没有什么影响，给中间件发送消息可以直接发送2万QPS。 此时对于系统B，可以自己控制获取消息的速度，保持在8000QPS一下，以一个数据库能够承受的速度执行操作。这样就可以保证数据库不会被压垮。 当然，这种情况MQ中可能会积压大量消息。但对于MQ来说，是允许消息积压的，等到系统A峰值过去，恢复成1000QPS时，系统B还是在以8000QPS的速度去拉取消息，自然MQ中的消息就慢慢被释放掉了。 利用MQ消息积压解决数据库压力部分MQ支持大量积压消息数
引入消息中间件带来的问题
- 系统可用性降低
- 系统稳定性降低
- 分布式事务一致性问题
资料
系统可用性降低
首先是你的系统整体可用性绝对会降低，给你举个例子，我们就拿之前的一幅图来说明。比如说一个核心链路里面，系统A -> 系统B -> 系统C，然后系统C是通过MQ异步调用系统D的。
图文解答 MQ异步化的手段解决了一个核心链路执行性能过差的问题，但ＭＱ中间件挂掉了，就导致系统业务流程中断了，就会导致可用性降低。 考虑ＭＱ如何部署 如何保证高可用 ＭＱ挂掉后保障方案
系统稳定性降低 图上引下
这个链路除了MQ中间件挂掉这个可能存在的隐患之外，可能还有一些其他的技术问题？
- 莫名其妙的，系统C发了一个消息到MQ，结果那个消息因为网络故障等问题，就丢失了。这就导致系统D没有收到那条消息。
- 这样会导致系统D没完成自己该做的任务，此时可能整个系统会出现业务错乱，数据丢失，严重的bug，用户体验很差等各种问题。
- 万一说系统C给MQ发送消息，不小心一抽风重复发了一条一模一样的，导致消息重复了，这个时候该怎么办。
- 可能会导致系统D一下子把一条数据插入了两次，导致数据错误，脏数据的产生，最后一样会导致各种问题。
- 如果系统D突然宕机了几个小时，导致无法消费消息，结果大量的消息在MQ中间件里积压了很久，这个时候怎么办？
- 即使系统D恢复了，也需要慢慢的消费数据来进行处理。
引入MQ中间件的第二个大问题，系统稳定性可能会下降，故障会增多，各种各样乱七八糟的问题都可能产生。
了解决各种MQ引发的技术问题，采取很多的技术方案
- 消息高可靠传递（0丢失）
- 消息幂等性传递（绝对不重复）
- 百万消息积压的线上故障处理
分布式一致性(事务)问题 图上引下
引入消息中间件，还有分布式一致性的问题。
举个例子，比如说系统C现在处理自己本地数据库成功了，然后发送了一个消息给MQ，系统D也确实是消费到了。
但是结果不幸的是，系统D操作自己本地数据库失败了，那这个时候咋办？
系统C成功了，系统D失败了，会导致系统整体数据不一致了啊。
所以此时又需要使用可靠消息最终一致性的分布式事务方案来保障。
参考之前的一篇文章：《最终一致性分布式事务的99.99%高可用保障生产实践》
若有收获，就点个赞吧
0 人点赞
