背景
大型互联网系统，业务逻辑较为复杂，或者由于海量、高并发等场景增加了技术架构的复杂性，这时候需要对复杂系统做解耦，这里就要用到消息中间件来给系统做解耦。
内容
消息中间件用法
我们先了解几个概念：
耦合性(Coupling)：也叫耦合度，是对模块间关联程度的一个度量。耦合的强弱取决于模块间接口的复杂性、调用模块的方式以及通过界面传送数据的多少。
模块间的耦合度是指模块之间的依赖关系，包括控制关系、调用关系、数据传递关系。一般来说，模块间联系越多，其耦合性越强，同时表明其独立性越差。
软件设计中通常用耦合度和内聚度，作为衡量模块独立程度的标准。划分模块的一个准则就是高内聚低耦合。
消息中间件：是利用高效可靠的消息传递机制进行平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息排队模型，它可以在分布式环境下扩展进程间的通信。
消息队列主要由以下作用：异步处理、流量削峰、应用解耦。
- 异步处理。生产端不需要等待消费端响应，直接返回，提高了响应时间和吞吐量。
- 流量削峰。打平高峰期的流量，消费端可以根据自己的速度处理，同时也无需在高峰期增加太多资源，提高资源利用率。
- 应用解耦。生产端和消费端不需要相互依赖。
应用场景
1. 异步处理：
场景说明：用户下订单后，需要发邮件和短信进行确认。传统的做法有两种，一是串行的方式，二是并行的方式。
- a.串行方式：将订单信息写入数据库后，发送邮件，再发送短信，以上三个任务全部完成后才返回给客户端。这里有一个问题是，邮件、短信并不是必须的，它只是一个通知，而这种做法让客户端等待没有必要等待的事件。
- b.并行方式：将订单信息写入数据库后，发送邮件的同时，发送短信，以上三个任务完成后，返回给客户端，并行的方式能提高处理的时间。
假设三个业务节点分别使用 50ms，串行方式使用时间 150ms，并行使用时间 100ms。虽然并行已经提高的处理时间，但是，前面说过，邮件和短信对用户正常使用网站没有任何影响，客户端没有必要等待其发送完成才显示下单成功，应该是写入数据库后就返回。
如果采用一般的同步方式处理，系统性能会很慢。
- c.消息队列
引入消息队列后，把发送邮件，短信等不是必须的业务逻辑，所以可以进行异步处理。
由此可以看出：引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间，引入消息队列后处理后，响应时间是串行的 3 倍，是并行的 2 倍。
2. 应用解耦：
场景说明：某宝双 11 购物狂欢节，用户下单后，订单系统需要通知库存系统，做锁库存操作，传统的做法就是订单系统调用库存系统的接口。
这种做法有一个缺点：当库存系统出现故障时，订单就会失败。订单系统和库存系统高耦合，解决的办法是引入消息队列。
- 订单系统：用户下单后，订单系统完成持久化处理，将消息写入消息队列，返回用户订单。
- 下单成功。库存系统订阅下单的消息，获取下单消息，进行库操作。
如果库存系统出现故障，消息队列也能保证消息的可靠投递，不会导致消息丢失。
3. 流量削峰：
流量削峰，一般在秒杀系统中应用广泛。
场景说明：某东购物网站秒杀活动，一般会因为流量过大，导致应用挂掉，为了解决这个问题，可以在应用前端加入消息队列。
作用：
- 可以控制活动人数，超过一定阀值的订单直接丢弃。
- 可以缓解短时间的高流量压垮系统。
改造后的处理流程如下：
用户的请求，服务器收到之后，首先写入消息队列，加入消息队列长度超过最大值，则直接抛弃用户请求或跳转到错误页面。
秒杀业务根据消息队列中的请求信息，再做后续处理。
最后：
以上，介绍了通过消息中间件的方式，给复杂系统解耦，通过消息中间件的引入，还可以帮助系统提升响应能力、提高可用性。
消息中间件是当今架构技术中很常用的一种工具，希望大家能够花时间去研究和实践。
上一章教程
该系列教程
我的专栏
至此，全部介绍就结束了
-------------------------------
-------------------------------
关于我（个人域名，更多我的信息）
期望和大家一起学习，一起成长，共勉，O(∩_∩)O谢谢
欢迎交流问题，可加个人QQ 469580884，
或者，加我的群号 751925591，一起探讨交流问题
不讲虚的，只做实干家
Talk is cheap，show me the code
2420
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
