1. 初始RocketMq

         RocketMQ是alibaba公司开源的一个纯java的开源消息中间件。 

1 消息模型（Message Model）

RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer 负责生产消息，Consumer 负责消费消息，Broker 负责存储消息。Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。ConsumerGroup 由多个Consumer 实例构成。

2 消息生产者（Producer）

负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。

3 消息消费者（Consumer）

负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。

4 主题（Topic）

表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。

5 代理服务器（Broker Server）

消息中转角色，负责存储消息、转发消息。代理服务器在RocketMQ系统中负责接收从生产者发送来的消息并存储、同时为消费者的拉取请求作准备。代理服务器也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列消息等。

6 名字服务（Name Server）

名称服务充当路由消息的提供者。生产者或消费者能够通过名字服务查找各主题相应的Broker IP列表。多个Namesrv实例组成集群，但相互独立，没有信息交换。

7 拉取式消费（Pull Consumer）

Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。

8 推动式消费（Push Consumer）

Consumer消费的一种类型，该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高。

9 生产者组（Producer Group）

同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

10 消费者组（Consumer Group）

同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

11 集群消费（Clustering）

集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息。

12 广播消费（Broadcasting）

广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息。

13 普通顺序消息（Normal Ordered Message）

普通顺序消费模式下，消费者通过同一个消费队列收到的消息是有顺序的，不同消息队列收到的消息则可能是无顺序的。

14 严格顺序消息（Strictly Ordered Message）

严格顺序消息模式下，消费者收到的所有消息均是有顺序的。

15 消息（Message）

消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。RocketMQ中每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。系统提供了通过Message ID和Key查询消息的功能。

16 标签（Tag）

为消息设置的标志，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性。

         见解：   随着分布式系统业务的演变，如电商系统同步接口在并发的情况下很容易达到系统瓶颈、造成系统不可用。这个时候中间的诞生处理相关业务痛点，用异步方式、将数据放到队列中进行消费，为分布式应用系统提供异步解耦、削峰填谷的能力，同时具备海量消息堆积、高吞吐、可靠重试等互联网应用所需的特性  下面配图：

 

    选择中间件对比：个人比较推荐RoeketMq毕竟是国产项目，社区活跃度还ok,不过源码里面有块可蛋疼的地方就是发送消息转化数据格式JSON，这块用到ali的fastJSON，想想近些年fastJSON有点搞事情，瞬间呵呵.老子我忍忍.....   不过不能否认RocketMq有自己优秀的地方比如底层数据结构(类似一个Map 数组、链表)、消息过滤自定对象解析、分布式事物支持等。如果你的业务达到一定程度，那就可以考虑下kafka这款中间用着也是很爽，但是kafka一般都要支持高可用，一般都会部署三节点，然后用zookeeper注册中心等等。

       RocketMQ 采用零拷贝原理实现超大的消息的堆积能力，据说单机已可以支持亿级消息堆积，而且在堆积了这么多消息后依然保持写入低延迟。

讯息产品	客户端SDK	协议和规范	订购消息	预定讯息	批处理邮件	广播消息	讯息筛选器	服务器触发的重新交付	讯息储存	消息追溯	邮件优先级	高可用性和故障转移	讯息追踪	组态	管理和操作工具
ActiveMQ	Java，.NET，C ++等	推送模型，支持OpenWire，STOMP，AMQP，MQTT，JMS	排他消费者或排他队列可以确保订购	支持的	不支持	支持的	支持的	不支持	使用JDBC以及高性能日志（例如levelDB，kahaDB）支持非常快速的持久性	支持的	支持的	受支持，取决于存储，如果使用kahadb，则需要ZooKeeper服务器	不支持	默认配置为低级别，用户需要优化配置参数	支持的
卡夫卡	Java，Scala等	拉模型，支持TCP	确保分区内消息的顺序	不支持	受支持，带有异步生成器	不支持	支持，您可以使用Kafka Streams过滤消息	不支持	高性能文件存储	支持的偏移量指示	不支持	受支持，需要ZooKeeper服务器	不支持	Kafka使用键值对格式进行配置。这些值可以从文件或以编程方式提供。	支持，使用终端命令公开核心指标
火箭MQ	Java，C ++，Go	拉模型，支持TCP，JMS，OpenMessaging	确保消息的严格排序，并可以正常扩展	支持的	支持，具有同步模式，可避免消息丢失	支持的	支持的基于SQL92的属性过滤器表达式	支持的	高性能和低延迟文件存储	支持的时间戳和偏移量两个表示	不支持	受支持的主从模式，无需其他套件	支持的	开箱即用，用户只需要注意一些配置	受支持的富Web和终端命令可显示核心指标

 

接下来我们开始学以致用：接着往下看惊喜

下一篇单机RockMq开始干