RocketMQ

RocketMQ简介

RocketMQ是阿里开源的消息中间件，它是纯java开发，具有低延迟、高吞吐量、高可用性和适合大规模分布式系统应用的特点。从名字可以看出Rocket火箭，代表RocketMQ主打速度。RocketMQ思路起源于Kafka，它对消息的可靠传输及事务性做了优化。

学习MQ必须知道的几个专业术语：

Producer

消息生产者，生产者的作用就是将消息发送到 MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到 MQ。 （Producer Group生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。）

Consumer

消息消费者，简单来说，消费 MQ 上的消息的应用程序就是消费者，至于消息是否进行逻辑处理，还是直接存储到数据库等取决于业务需要。(Consumer Group消费者组，和生产者组类似，消费同一类消息的多个 consumer 实例组成一个消费者组。)

Topic

Topic 是一种消息的逻辑分类，比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单 Topic 存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。

Message

Message 是消息的载体。一个 Message 必须指定 topic，相当于寄信的地址。Message 还有一个可选的 tag 设置，以便消费端可以基于 tag 进行过滤消息。也可以添加额外的键值对，例如你需要一个业务 key 来查找 broker 上的消息，方便在开发过程中诊断问题。

Tag

标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。

Broker

Broker 是 RocketMQ 系统的主要角色，其实就是前面一直说的 MQ。Broker 接收来自生产者的消息，储存以及为消费者拉取消息的请求做好准备。

Name Server

Name Server 为 producer 和 consumer 提供路由信息。

RocketMQ架构图：

为什么使用消息队列MQ

使用消息队列主要是为了解决三个问题：松耦合、异步和削峰。下面简单介绍一下这三种作用的应用场景：

松耦合

传统的系统间耦合性太强，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦，使用MQ将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改。

异步

一些非必要的业务逻辑以同步的方式运行，太耗费时间。 将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快响应速度。

削峰

在高并发分布式环境下，在高峰请求的时候，由于来不及处理，请求往往发生堵塞，比如大量的update、insert操作同时到达mysql，直接导致大量的行锁和表锁，甚至触发too many connections错误。通过使用消息队列，我们可以异步处理请求，按照数据处理能力从消息队列中慢慢的拉取消息，在生产中，这个短暂的高峰期积压是允许的。

缺点：

引入MQ也会有一些缺点，比如系统的可用性降低，因为多加了一个系统就要保证MQ不出问题，一旦MQ挂了，整个系统也就挂了。

还有就是系统的复杂性提高了，加入MQ之后要考虑很多问题，比如一致性问题，如何保证消息不被重复消费，如何保证消息可靠性传输。