1. 为什么需要mq，mq的意义和必须性
主要原因是由于在高并发环境下，由于来不及同步处理，请求往往会发生堵塞；
比如说：
大量的insert，update之类的请求同时到达MySQL，直接导致无数的行锁表锁，甚至最后请求会堆积过多，从而触发too many connections错误；
该业务场景具有如下特征：
l 在一些特定情形下，可能会集中发生批量的替换删除操作，使得操作的并发量达到高峰；例如FDA要求召回一些违规药品时，就需要删除药品库中该药品的信息；
l 操作结果不要求实时性，但需要保证操作的可靠性，不能因为异常失败而导致某些操作无法进行；
l 自动操作的过程是不可逆转的，因此需要记录操作历史；
l 基于性能考虑，大多数操作需要调用数据库的存储过程；
l 操作的数据需要具备一定的安全性，避免被非法用户对数据造成破坏；
l 与操作相关的功能以组件形式封装，保证组件的可重用性、可扩展性与可测试性；
l 数据量可能随着最终用户的增多而逐渐增大；
针对如上的业务需求，我们决定从以下几个方面对各种技术方案进行横向的比较与考量。
l 并发：选择的消息队列一定要很好地支持用户访问的并发性；
l 安全：消息队列是否提供了足够的安全机制；
l 性能伸缩：不能让消息队列成为整个系统的单一性能瓶颈；
l 部署：尽可能让消息队列的部署更为容易；
l 灾备：不能因为意外的错误、故障或其他因素导致处理数据的丢失；
l API易用性：处理消息的API必须足够简单、并能够很好地支持测试与扩展；
通过使用消息队列，我们可以异步处理请求，从而缓解系统的压力。
2. Mq的基本实现概念
常用的消息模式
消息通道（Message Channel）模式
图1 Message Channel模式
消息通道作为在客户端（消费者，Consumer）与服务（生产者，Producer）之间引入的间接层，可以有效地解除二者之间的耦合。只要实现规定双方需要通信的消息格式，以及处理消息的机制与时机，就可以做到消费者对生产者的“无知”。事实上，该模式可以支持多个生产者与消费者。例如，我们可以让多个生产者向消息通道发送消息，因为消费者对生产者的无知性，它不必考虑究竟是哪个生产者发来的消息。
虽然消息通道解除了生产者与消费者之间的耦合，使得我们可以任意地对生产者与消费者进行扩展，但它又同时引入了各自对消息通道的依赖，因为它们必须知道通道资源的位置。要解除这种对通道的依赖，可以考虑引入Lookup服务来查找该通道资源。例如，在JMS中就可以通过JNDI来获取消息通道Queue。若要做到充分的灵活性，可以将与通道相关的信息存储到配置文件中，Lookup服务首先通过读取配置文件来获得通道。
发布者-订阅者（Publisher-Subscriber）模式
图2 拉模型
图3 推模型
一旦消息通道需要支持多个消费者时，就可能面临两种模型的选择：拉模型与推模型。拉模型是由消息的消费者发起的，主动权把握在消费者手中，它会根据自己的情况对生产者发起调用。如上图所示；
拉模型的另一种体现则由生产者在状态发生变更时，通知消费者其状态发生了改变。但得到通知的消费者却会以回调方式，通过调用传递过来的消费者对象获取更多细节消息。
在基于消息的分布式系统中，拉模型的消费者通常以Batch Job的形式，根据事先设定的时间间隔，定期侦听通道的情况。一旦发现有消息传递进来，就会转而将消息传递给真正的处理器（也可以看做是消费者）处理消息，执行相关的业务。在本文第二部分介绍的医疗卫生系统，正是通过引入Quartz.NET实现了Batch Job，完成对消息通道中消息的处理。
推模型的主动权常常掌握在生产者手中，消费者被动地等待生产者发出的通知，这就要求生产者必须了解消费者的相关信息。
对于推模型而言，消费者无需了解生产者。在生产者通知消费者时，传递的往往是消息（或事件），而非生产者自身。同时，生产者还可以根据不同的情况，注册不同的消费者，又或者在封装的通知逻辑中，根据不同的状态变化，通知不同的消费者。
两种模型各有优势。拉模型的好处在于可以进一步解除消费者对通道的依赖，通过后台任务去定期访问消息通道。坏处是需要引入一个单独的服务进程，以Schedule形式执行。而对于推模型而言，消息通道事实上会作为消费者观察的主体，一旦发现消息进入，就会通知消费者执行对消息的处理。无论推模型，拉模型，对于消息对象而言，都可能采用类似Observer模式的机制，实现消费者对生产者的订阅，因此这种机制通常又被称为Publisher-Subscriber模式
图4 Publisher-Subscriber模式
通常情况下，发布者和订阅者都会被注册到用于传播变更的基础设施（即消息通道）上。发布者会主动地了解消息通道，使其能够将消息发送到通道中；消息通道一旦接收到消息，会主动地调用注册在通道中的订阅者，进而完成对消息内容的消费。
对于订阅者而言，有两种处理消息的方式。一种是广播机制，这时消息通道中的消息在出列的同时，还需要复制消息对象，将消息传递给多个订阅者。例如，有多个子系统都需要获取从CRM系统传来的客户信息，并根据传递过来的客户信息，进行相应的处理。此时的消息通道又被称为Propagation通道。另一种方式则属于抢占机制，它遵循同步方式，在同一时间只能有一个订阅者能够处理该消息。实现Publisher-Subscriber模式的消息通道会选择当前空闲的唯一订阅者，并将消息出列，并传递给订阅者的消息处理方法。
消息路由（Message Router）模式
图5 Message Router模式
无论是Message Channel模式，还是Publisher-Subscriber模式，队列在其中都扮演了举足轻重的角色。然而，在企业应用系统中，当系统变得越来越复杂时，对性能的要求也会越来越高，此时对于系统而言，可能就需要支持同时部署多个队列，并可能要求分布式部署不同的队列。这些队列可以根据定义接收不同的消息，例如订单处理的消息，日志信息，查询任务消息等。这时，对于消息的生产者和消费者而言，并不适宜承担决定消息传递路径的职责。事实上，根据S单一职责原则，这种职责分配也是不合理的，它既不利于业务逻辑的重用，也会造成生产者、消费者与消息队列之间的耦合，从而影响系统的扩展。
既然这三种对象（组件）都不宜承担这样的职责，就有必要引入一个新的对象专门负责传递路径选择的功能，这就是所谓的Message Router模式，如图5所示；
怎么使用？（基于阿里巴巴消息队列MQ整合JAVA使用）
l 名词解释（特别重要）
https://help.aliyun.com/document_detail/29533.html?spm=5176.doc29532.6.544.aJOpay
l 快速入门：
https://help.aliyun.com/document_detail/34411.html?spm=5176.doc29532.6.552.HeNAgf
l 步骤一：开通服务
l 步骤二：申请资源
l 步骤三：发送消息
l 步骤四：订阅消息
（阅读快速入门的四个步骤之后，能对MQ有一个大概的认知和初步的入门）
l MQ 介绍（视频），能有一个清楚的了解：
https://help.aliyun.com/video_detail/52430.html?spm=5176.7843362.2.2.HuHzbS
后面有时间再完善。
扫一扫
844
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
