这是我参与8月更文挑战的第8天，活动详情查看：8月更文挑战

RocketMQ

前面介绍消息队列、协议。从本章开始正式进入中间件的学习。在学习之前补充一些前面漏掉的知识——MQ缺点：

1.系统可用性降低：当系统引入过多的外部依赖，系统的稳定性就会变差。一旦MQ宕机，就会对线上业务产生影响，所有要保证MQ的高可用；

2.系统复杂度增加：服务器之间从同步服务调用变为异步调用，数据链路复杂，会带来很多不确定因素，这个之前有谈到；

3.消息一致性：同样是因为增加了MQ后，系统相互之间不可见，只能通过MQ“通话”，至于说什么，很可能因为这种“阻碍”，最终导致系统和系统之间的消息“驴头不对马嘴”；

背景

RocketMQ发展时间线：

1.阿里的消息中间件源于2001的五彩石项目，期间诞生了Notify消息中间件(PS：淘宝自研的一套消息引擎)；

2.2010年，B2B开始大规模使用ActiveMQ作为消息内核，但是并不满足阿里业务此时对中间件的要求：支持顺序消息，拥有海量消息堆积能力的消息中间件，MetaQ 1.0在2011年诞生；

3.随着MetaQ的不断更新迭代，在3.0版本后，阿里从中抽象出了通用的消息引擎RocketMQ，随后就将其开源；

4.2015年经过战与火的洗礼——“双十一”；RocketMQ的可靠性、稳定性等方面都有很出色的表现；（PS：可用性存疑？？）。随着云计算的潮流，阿里基于RocketMQ推出了Aliware MQ 1.0，为各大企业提供消息服务；

5.2016年，阿里将RocketMQ进入Apache孵化；

小结：可以通过这个链接详细了解一下RocketMQ：RocketMQ的前世今生

RocketMQ特点

1.具有灵活的可扩展性。天然支持集群，其核心四大组件的每一个都可以在没有单点故障的情况下进行水平扩展；

2.海量消息堆积能力。保证超大量的消息堆积的同时，依然保持写入低延时；

3.支持顺序消息，保证按照消费者发送消息的顺序进行消费。顺序消息分为全局有序和局部有序消息，一般推荐使用局部有序消息，即生产者通过将某一类消息按顺序发送至同一个队列实现；

4.消息存储是MQ的另一个重要功能。存储一般从下面两个纬度考量：

4.1.消息堆积能力：为了追求消息存储的高性能，引入内存映射机制，所有主题消息按顺序存储在同一个文件中；

4.2.消息存储：为了避免消息无限在消息存储服务器中积累，还需要设定过期时间，以及空间告警机制；

5.支持多种消息过滤方式。消息过滤分为在服务器端过滤和在消费端过滤。在服务器端过滤时可以按照消息消费者的要求进行过滤，优点时减少了不必要的传输，缺点时增加了服务器的负担，实现相对复杂。消费端过滤则完全由具体应用自定义实现，这种方式更加灵活。缺点是很多无用的消息会被传输给消息消费者；

6.支持事物消息。

7.支持回朔消费。指的是对于已经消费成功的消息，由于业务需求需要重新消费。RocketMQ支持按照时间回溯消费，时间精确到毫秒，可以向前回溯、也可以向后回溯；

RocketMQ四大核心组件

前面已经说过，RocketMQ的四大核心组件每一个都可以水平扩展，避免单点故障。如图所示：

1.Produce(生产者)：负责生产发送消息更准确来说是传递应用程序产生的消息到Broker。RocketMQ提供了三种方式发送消息：

1.1.同步发送：即消息发送发出消息后会阻塞等待消息服务回应确认收到消息的相应，才会接着发送下一条数据。一般用于重要的消息通知场景。如重要通知邮件、营销短信等。

1.2.异步发送：发消息不用阻塞等待服务器响应，就可以接着发送下一个数据包。一般用于链路可能耗时较长而对响应不敏感的业务场景。如视频转码等通知；

1.3.单项发送：只负责发消息不用等待服务器响应且没有回调函数触发。一般适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集等；

2.生产者组(Producer Group)是一类生产者的集合，这类生产者通常发送一类消息并且发送逻辑一致。从部署结构上看，生产者通过生产者组的名字来标识自己是一个集群；

3.消费者(Consumer)：负责消费消息。从用户角度来看，消费者有两种类型：拉取型消费者和推送型消费者；

3.1.拉取型消费(Pull Consumer)主动从消息服务器拉取消息，只要批量拉取到消息，用户 应用就会启动消费过程。

3.2.推送型消费(Push Consumer)封装了消息的拉取、消费进度和其他内部维护工作，将消息到达时执行的回调接口留给用户应用程序来实现。所以Push是被动消费。但实际上还是从服务器上拉取消息，不同的是Push多了注册消费监听器的过程，当监听器触发后才开始消费消息；

4.消费者组(Consumer Group)：是一类消费者的集合，这类消费者通常消费同一类消息并且消费逻辑一致，所以将这些消费者分组在一起；

5.消费服务器：消息服务器(Broker)是消息存储中心，主要作用是接收来自生产者的消息，而消费者来这里拉取消息。Broker还存储了与消息相关的元数据，包括用户组、消费进度偏移量、队列信息等。

从上图部署结构可以看出，Broker有master和slave两种类型，其中master既可以写，也可以读；slave可以读。不可以写。

Broker的集群部署有单master、多master、多master多slave等多种方式

5.1.单master：存在单点故障，不推荐使用；

5.2.多master：所有服务器都是master，无slave，优点是配置方式简单，但是存在丢失消息的风险——master上还有消息未处理，突然宕机；

5.3.多master和slave(同步复制)：为每个master配置一个slave，多master-slave，消息采用同步双写机制——主备都写成功才返回。这种方式避免了单点问题，服务与数据可用性高。但是性能较低，同步意味着阻塞，发送消息延迟略高；

5.4.多master和slave(异步复制)：为每个master配置一个slave，采用异步复制方式，主备之间有毫秒级消息延迟。这种方式的优点是丢失的消息非常少，且消息的实时性不会受到影响，缺点同多master几乎一样，只是这种方式在服务宕机后数据丢失极少；

6.名称服务器(NameServer)：用来保存Broker相关元信息并给生产者和消费者查找Broker信息。名称服务器被设计成几乎无状态，每个Broker启动时都会到名称服务器中注册，生产和消费者会根据主题名称到名称服务器获取相关路由信息。

7.消息(Message)：要传输数据的实体。每个消息要对应一个主题，这样才可以被查找到并被消费。主题和消息类似K-V关系；

主题

主题(Topic)可以被看作是消息的归类，它是消息的第一级类型。比如一个电商系统可以分为交易消息、物流消息等。主题与生产者和消费者的关系很松散，一个主题可以有0个、1个、多个生产者向其发送消息，一个生产者也可以同时向不同主题发送消息，一个主题也可以被0个、1个、多个消费者订阅；

标签

标签Tag可以被看作是子主题，它是消息的第二级类型，用于为用户提供额外的灵活性。

队列

主题被划分为一个或多个子主题，即队列(Queue)。在同一个主题下可以设置多个队列，在发送消息时，执行该消息的主题，RocketMQ会轮询该主题下的所有队列，然后将消息发送出去。如图所示：

消息消费模式

消息消费模式有两种：集群消费(Clustering)和广播消费(Broadcasting)。默认是集群消费，在该模式下一个消费者集群共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉了，分组内的其他消费者会接替挂掉的消费者继续消费。而广播消费会将消息发送给消费组中的每一个消费者进行消费。

消息顺序

1.顺序消费：表示消费者消费消息顺序按照生产者发送的消息顺序进行消费；

2.并行消费：不再保证消息顺序，消费的最大并行数量受每个消费者客户指定的线程池限制