消息中间件 - RocketMQ基础

• 一个进程内能够创建的线程数量是有限的。 

所有中间件的目的：

1. 性能效率上的一个提升
2. 代理：帮你去完成一些额外的事情

MQ介绍

MQ概述

• MQ全称Message Queue（消息队列），是在消息的传输过程中保存消息的容器，多用于分布式系统之间进行通信。
• 在计算机领域，消息指的就是数据（跟业务整合的）！
• 消息队列是应用程序和应用程序之间的通信方法，主要应用在多个工程之间，相互的传递消息，消息由生产者发送到MQ进行排队，然后按原来的顺序由消费者从MQ当中来拉取消息进行处理。
• 队列：数据结构的一种，特征为"先进先出" - FIFO，意思是有序的。

为什么使用MQ？

• 在项目中，可将一些无需即时返回且耗时的操作提取出来，进行异步处理，而这种异步处理的方式大大的节省了服务器的请求响应时间，从而提高系统的吞吐量。 

Tomcat的并发量大约是500个请求左右/s！（500个请求就意味着有500个线程） 

MQ的优势和劣势

优势：

1. 应用解耦
2. 异步提速
3. 削峰填谷

劣势：

1. 系统的可用性降低
2. 系统复杂度提高
3. 一致性问题 

1. 应用解耦：消费者存活与否不影响生产方

应用解耦意思就是消费者无论挂掉没有，都不影响生产者在这里发消息，MQ就相当于是一个中介，生产者通过MQ与消费者进行交互！

应用解耦 / 使用MQ使得应用间解耦  可以提高系统的容错性和可维护性！

• 一个程序和另一个程序它们的耦合度要降低！（高内聚，低耦合）
• 系统的耦合度越高，容错性就越低，可维护性就越低！

2. 异步提速：生产方发完消息，可以继续进行下一步的业务逻辑  

同步：一个一个来/走，你走完了我才能走 ⇒ 一个动作做完以后才能进行下一个动作。

异步：各来/走各的 ⇒ 两个动作可以同时做。

• 将不需要同步处理并且耗时长的操作由消息队列来通知消息接收方进行异步处理，从而提高应用程序的响应时间，提升系统的吞吐量。
• 异步调用能够提高系统的响应速度以及吞吐量。

3. 削峰填谷

• TPS：每秒事务数 
• 削峰填谷指的是通过消息队列平滑、缓和的处理高峰期突发产生的高并发流量，从而减少对后端服务的冲击，避免因突发流量而导致应用崩溃或系统瘫痪。
• 这种技术的实现方式是将突发的请求放入到消息队列当中，这样一来，高峰期产生的数据就会被积压在MQ当中，高峰就被"削"掉了，然后通过异步或定时任务的方式，从消息队列当中取出消息，并以匀速的方式发送到后端服务中，直到消费完积压的消息，这就叫做"填谷"，这样就可以平滑的处理高并发流量，在避免请求过多、并发过高的同时，保障了后端服务的正常工作。
• 削峰填谷技术在一些高并发的场景下被广泛应用，比如秒杀、抢购等大规模的并发场景。
• 削峰填谷后，可以提高系统的稳定性。
   

MQ的劣势

1. 系统的可用性降低（降低系统的可用性）

• 因为你在系统当中引入了一个MQ这样的组件，你只要引入组件的话，这个组件万一坏了，我们整个系统不就全崩掉了，所以说只要是引入了新的一些组件，那么必然会造成系统的可用性降低！
• 系统引入的外部依赖越多，系统稳定性越差，一旦MQ宕机，就会对业务造成影响。

如何保证MQ的高可用？

2. 系统复杂度提高

• MQ的加入大大增加了系统的复杂度，以前系统间是同步的远程调用，现在是通过MQ进行异步调用。 

如何保证消息没有被重复消费？如何处理消息丢失情况？如何保证消息传递的顺序性呢？

3. 一致性问题 

• A系统处理完业务，通过MQ给B、C、D三个系统发消息数据，B、C、D都要处理完才算事务的一致，如果B系统、C系统处理成功，D系统处理失败，那么整个事务的处理也算是失败的！

所以如何保证消息数据处理的一致性呢？ 

MQ产品介绍

1. ActiveMQ

• 纯Java语言实现，并发量较低，万级数据吞吐量，处理速度比较慢，处理速度达到毫秒ms级，成熟度高

2. RabbitMQ

• 底层由erlang语言实现，erlang语言比较底层，直接和物理硬件进行交互，因此处理速度会非常快，处理速度是微秒us级别的，

3. RocketMQ

• Java语言实现，高吞吐，万亿级吞吐保证，处理速度毫秒级别，分布式架构，功能强大，扩展性强

4. Kafka

• scala语言实现，scala是运行在我们的Java虚拟机上的一门语言，吞吐量高，处理速度也比较快，处理速度达到毫秒级，但是功能比较单一，应用于日志分析、大数据采集较多，所以在大数据的技术当中，用Kafka是最多的。

RocketMQ概述

• RocketMQ是阿里开源的一款非常优秀的中间件产品，脱胎于阿里的另一款队列技术MetaQ，后捐赠给Apache基金会作为一款孵化技术，仅仅经历了一年多的时候就成为了Apache基金会的顶级项目，它现在已经在阿里内部被广泛的应用，并且经受住了多次双十一的这种极致场景的压力！（2017年的双十一，RocketMQ流转的消息量达到了万亿级，峰值TPS达到了5600万） 

RocketMQ解决了MQ的所有缺点~！

RocketMQ的工作原理

• 生产者集群来进行发消息 
• Broker：部署着RocketMQ的机器就叫一台Broker。
• 生产者发消息到RocketMQ当中，然后RocketMQ还能返回一个接收结果。
• 消息的消费者就会从RocketMQ当中来拉取消息。

我们的消息达到了RocketMQ之后，我们的消费者它怎么就知道消息队列当中就有了消息了呢？

有两种模式：

1. 拉取模式（拉取消费）：消费者这里可以起一个线程之类的，每隔一秒钟问一下RocketMQ，队列当中有消息吗？

• 拉取模式很不好，很占用我们消费者的资源，因为每秒钟它都要发一次请求去拉取数据。

2. 监听器模式或推送模式（推送消费 - 常用）：我们的消费者和RocketMQ建立一个长连接，建立好了长连接之后，一旦RocketMQ当中有了消息并且有某一个消费者监听着某一个队列，那么RocketMQ就会把这个消息推送给消息的消费者，这就是一个推送模式或者叫我们的消费者起一个监听器。

这就是最基础的消息的发送与接收！

它就是专门来存储一些元数据。

JMS：就是消息领域的JDBC

 

RocketMQ安装启动

消息发送

消息类别