JAVA消息中间件/消息队列

一、什么是消息中间件：

1、消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。

2、通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。当下主流的消息中间件有RabbitMQ、Kafka、ActiveMQ、RocketMQ等。其能在不同平台之间进行通信，常用来屏蔽各种平台协议之间的特性，实现应用程序之间的协同。

3、其优点在于能够在客户端和服务器之间进行同步和异步的连接，并且在任何时刻都可以将消息进行传送和转发，是分布式系统中非常重要的组件。主要用来解决应用耦合、异步通信、流量削峰等问题。

二、消息中间件的作用：

1、解耦
降低工程间的强依赖程度，针对异构系统进行适配。在项目启动之初来预测将来项目会碰到什么需求，是极其困难的。通过消息系统在处理过程中间插入了一个隐含的、基于数据的接口层，两边的处理过程都要实现这一接口，当应用发生变化时，可以独立的扩展或修改两边的处理过程，只要确保它们遵守同样的接口约束。

2、冗余(存储)
有些情况下，处理数据的过程会失败。除非数据被持久化，否则将造成丢失。消息队列把数据进行持久化直到它们已经被完全处理，通过这一方式规避了数据丢失风险。许多消息队列所采用的”插入-获取-删除”范式中，在把一个消息从队列中删除之前，需要你的处理系统明确的指出该消息已经被处理完毕，从而确保你的数据被安全的保存直到你使用完毕。

3、扩展性
因为消息队列解耦了你的处理过程，所以增大消息入队和处理的频率是很容易的，只要另外增加处理过程即可。不需要改变代码、不需要调节参数。便于分布式扩容。

4、削峰
在访问量剧增的情况下，应用仍然需要继续发挥作用，但是这样的突发流量无法提前预知；如果以为了能处理这类瞬间峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住突发的访问压力，而不会因为突发的超负荷的请求而完全崩溃。

5、可恢复性
系统的一部分组件失效时，不会影响到整个系统。消息队列降低了进程间的耦合度，所以即使一个处理消息的进程挂掉，加入队列中的消息仍然可以在系统恢复后被处理。

6、顺序保证
在大多使用场景下，数据处理的顺序都很重要。大部分消息队列本来就是排序的，并且能保证数据会按照特定的顺序来处理。

7、缓冲
在任何重要的系统中，都会有需要不同的处理时间的元素。消息队列通过一个缓冲层来帮助任务最高效率的执行，该缓冲有助于控制和优化数据流经过系统的速度。以调节系统响应时间。

8、异步通信
有些业务不想也不需要立即处理消息。消息队列提供了异步处理机制，允许用户把一个消息放入队列，但并不立即处理它。想向队列中放入多少消息就放多少，然后在需要的时候再去处理它们。

9、三大主要问题的解决原理：

1.解耦

系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦。

2.异步

将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度。

3.削峰

并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常。

（1）异步通信（缩短响应时间，提高效率）
场景说明：用户在注册后，需要发注册邮件和注册短信,传统的做法有两种：1.串行; 2.并行

1.串行方式:将注册信息写入数据库后,发送注册邮件,再发送注册短信,以上三个任务全部完成后才返回给客户端。 这有一个问题是,邮件,短信并不是必须的,它只是一个通知,而这种做法让客户端等待没有必要等待的东西。

2.并行方式:将注册信息写入数据库后,发送邮件的同时,发送短信,以上三个任务完成后,返回给客户端,并行的方式能提高处理的时间。

假设三个业务节点分别使用50ms,串行方式使用时间150ms,并行使用时间100ms。虽然并行已经提高的处理时间,但是,前面说过,邮件和短信对我正常的使用网站没有任何影响，客户端没有必要等着其发送完成才显示注册成功,应该是写入数据库后就返回.

3.消息队列
引入消息队列后，把发送邮件,短信不是必须的业务逻辑异步处理

 由此可以看出,引入消息队列后，用户的响应时间就等于写入数据库的时间+写入消息队列的时间(可以忽略不计),引入消息队列后处理后,响应时间是串行的3倍,是并行的2倍。

（2）应用解耦

这是一个高耦合度系统的例子

应用解耦
这是一个高耦合度系统的例子

先是来一个人找他要求发送数据给一个新的系统H，系统A的同学要修改代码然后在那个代码里加入调用新系统H的流程。

一会那个系统B是个陈旧老系统要下线了，告诉系统A的同学：别给我发送数据了，接着系统A再次修改代码不再给这个系统B。

然后如果要是某个下游系统突然宕机了呢？

系统A的调用代码里是不是会抛异常？那系统A的同学会收到报警说异常了，结果他还要去care是下游哪个系统宕机了。

所以在实际的系统架构设计中，如果全部采取这种系统耦合的方式，在某些场景下绝对是不合适的，系统耦合度太严重。

并且互相耦合起来并不是核心链路的调用，而是一些非核心的场景（比如上述的数据消费）导致了系统耦合，这样会严重的影响上下游系统的开发和维护效率。

因此在上述系统架构中，就可以采用MQ中间件来实现系统解耦。

系统A就把自己的一份核心数据发到MQ里，下游哪个系统感兴趣自己去消费即可，不需要了就取消数据的消费，如下图所示：

（3） 流量削峰

场景1
假设你有一个系统，平时正常的时候每秒可能就几百个请求，每秒几百请求是可以轻松抗住的，但是偶尔在高峰期一下子来了每秒钟几千请求，弹指一挥间出现了流量高峰，为了抗住这个高峰，可能会选择扩充机器，增加到10台，但是高峰过后，每秒就几百个请求，这不是有点浪费机器资源吗？但是如果你就部署一台机器，那会导致瞬时高峰时，一下子压垮你的系统，因为绝对无法抗住每秒几千的请求高峰。此时我们就可以用MQ中间件来进行流量削峰。所有机器前面部署一层MQ，平时每秒几百请求大家都可以轻松接收消息。一旦到了瞬时高峰期，一下涌入每秒几千的请求，就可以积压在MQ里面，然后那一台机器慢慢的处理和消费。等高峰期过了，再消费一段时间，MQ里积压的数据就消费完毕了。这个就是很典型的一个MQ的用法，用有限的机器资源承载高并发请求，如果业务场景允许异步削峰，高峰期积压一些请求在MQ里，然后高峰期过了，后台系统在一定时间内消费完毕不再积压的话，那就很适合用这种技术方案。

场景2
秒杀活动，一般会因为流量过大，导致应用挂掉,为了解决这个问题，一般在应用前端加入消息队列。作用:1.可以控制活动人数，超过此一定阀值的订单直接丢弃2.可以缓解短时间的高流量压垮应用(应用程序按自己的最大处理能力获取订单)

三、消息中间件的两种模式： 

1、P2P模式 （点对点）使用Queue作为通信载体

P2P模式包含三个角色：消息队列（Queue），发送者(Sender)，接收者(Receiver)。每个消息都被发送到一个特定的队列，接收者从队列中获取消息。队列保留着消息，直到他们被消费或超时。

P2P的特点:

每个消息只有一个消费者（Consumer）(即一旦被消费，消息就不再在消息队列中)
发送者和接收者之间在时间上没有依赖性，也就是说当发送者发送了消息之后，不管接收者有没有正在运行它不会影响到消息被发送到队列
接收者在成功接收消息之后需向队列应答成功
如果希望发送的每个消息都会被成功处理的话，那么需要P2P模式

2、Pub/Sub模式 （发布/订阅 广播）使用Topic作为通信载体

消息生产者（发布）将消息发布到topic中，同时有多个消息消费者（订阅）消费该消息。和点对点方式不同，发布到topic的消息会被所有订阅者消费。
queue实现了负载均衡，将producer生产的消息发送到消息队列中，由多个消费者消费。但一个消息只能被一个消费者接受，当没有消费者可用时，这个消息会被保存直到有一个可用的消费者。
topic实现了发布和订阅，当你发布一个消息，所有订阅这个topic的服务都能得到这个消息，所以从1到N个订阅者都能得到一个消息的拷贝

Pub/Sub的特点

每个消息可以有多个消费者
发布者和订阅者之间有时间上的依赖性。针对某个主题（Topic）的订阅者，它必须创建一个订阅者之后，才能消费发布者的消息。
为了消费消息，订阅者必须保持运行的状态。
如果希望发送的消息可以不被做任何处理、或者只被一个消息者处理、或者可以被多个消费者处理的话，那么可以采用Pub/Sub模型。
 

四、常用中间件的比较：

 五、RabbitMQ

1、RabbitMQ的四大核心：

生产者：发送消息到的RabbitMQ客户端为生产者

交换机：是RabbitMQ非常重要的一个部件，用于接收来自生产者的消息，并且也需要将消息推送到队列中，交换机必须确切的知道如何处理接收到的消息，是将这些消息推送到指定队列还是多个队列，或是将消息丢弃都由交换机类型决定

队列：是RabbitMQ中存储消息数据结构，生产者生产的消息最终会存放在队列中，消费者消费消息需要从队列中获取

消费者：并且并且消费队列中的消息为消费者
 

工作原理：

RabbitMQ原理图

2、RabbitMQ的核心概念

1）Broker

Broker，简单来说就是消息队列服务器实体。

2）Exchange

Exchange(消息交换机)，它指定消息按什么规则，路由到哪个队列。

3）Queue

Queue(消息队列载体),每个消息都会被投入到一个或多个队列。

4）Binding

Binding(绑定)，它的作用就是把exchange和queue按照路由规则绑定起来。

5）Routing Key

Routing Key(路由关键字)，exchange根据这个关键字进行消息投递；

6）VHost

vhost 可以理解为虚拟 broker ，即 mini-RabbitMQ server。其内部均含有独立的 queue、exchange 和 binding 等，但最最重要的是，其拥有独立的权限系统，可以做到 vhost 范围的用户控制。当然，从 RabbitMQ 的全局角度，vhost 可以作为不同权限隔离的手段（一个典型的例子就是不同的应用可以跑在不同的 vhost 中）；

7）Producer

Producer(消息生产者)，就是投递消息的程序；

8）Consumer

Consumer(消息消费者)，就是接受消息的程序；

9）Channel

Channel(消息通道)，在客户端的每个连接里，可建立多个channel，每个channel代表一个会话任务。

3、RabbitMQ 的工作模式（消息模式）

RabbitMQ提供了6种模式：（消息模式）

1、简单模式

生产者，一个队列一个或多个消费者，当多个消费者同时监听一个队列时，他们并不能同时消费一条消息，而是随机消费消息，即一个队列中一条消息，只能被一个消费者消费。

2、主题模式(topic)

生产者，一个交换机(topicExchange)，模糊匹配路由规则，多个队列，多个消费者。

3、订阅与发布模式(fanout)

生产者，一个交换机(fanoutExchange)，没有路由规则，多个队列，多个消费者。生产者将消息不是直接发送到队列，而是发送到X交换机，然后由交换机发送给两个队列，两个消费者各自监听一个队列，来消费消息。

4、路由模式(direct)

生产者，一个交换机(directExchange)，路由规则，多个队列，多个消费者。主要根据定义的路由规则决定消息往哪个队列发送。

5、RPC模式

对于RPC请求，客户端发送一条带有两个属性的消息：replyTo,设置为仅为请求创建的匿名独占队列，和correlationId,设置为每个请求的唯一id值。请求被发送到rpc_queue队列。RPC工作进程在队列上等待请求。当一个请求出现时，它执行任务，并使用replyTo字段中的队列将结果发回客户机。客户机在回应消息队列上等待数据。当消息出现时，它检查correlationId属性。如果匹配请求中的值，则向程序返回该响应数据。

6、工作队列

注释：默认情况下，RabbitMQ将按顺序将每条消息发送给下一个消费者，平均而言，每个消费者将获得相同数量的消息，这种分发消息的方式称为循环法。

4、集群

1、普通模式：默认模式，以两个节点（A、B）为例来进行说明：

当消息进入 A 节点的 Queue 后，Consumer 从 B 节点消费时，RabbitMQ 会在 A 和 B 之间创建临时通道进行消息传输，把 A 中的消息实体取出并经过通过交给 B 发送给 Consumer。
当 A 故障后，B 就无法取到 A 节点中未消费的消息实体；如果做了消息持久化，那么得等 A 节点恢复，然后才可被消费；如果没有持久化的话，就会产生消息丢失的现象。

2、镜像模式 ：经典的 Mirror 镜像模式，保证数据不丢失：

高可靠性解决方案，主要就是实现数据的同步，一般来讲是 2 - 3 个节点实现数据同步。
对于 100% 数据可靠性解决方案，一般是采用 3 个节点。
该模式用得最多的，并且实现非常的简单，一般互联网大厂都会构建这种镜像集群模式。

3、 HAProxy 实现镜像队列的负载均衡