前言
开门见山的说，MQ肯定是有用的，不然这么多人用它干嘛(当然可能有人觉得可以装逼用2333）
不过这次我们要说的RocketMQ可不是美国进口的技术，是阿里巴巴捐赠给apache，让apache孵化用的。
阿里巴巴官方给出的RocketMQ的特点
- 是一个队列模型的消息中间件，具有高性能、高可靠、高实时、分布式特点。
- Producer、Consumer、队列都可以分布式。
- Producer向一些队列轮流发送消息，队列集合称为Topic，Consumer如果做广播消费，则一个consumer实例消费这个Topic对应的所有队列，如果做集群消费，则多个Consumer实例平均消费这个topic对应的队列集合。
- 能够保证严格的消息顺序
- 提供丰富的消息拉取模式
- 高效的订阅者水平扩展能力
- 实时的消息订阅机制
- 亿级消息堆积能力
- 较少的依赖
先说说MQ的作用：
- 解耦
假如现在两个系统，当B系统crash掉，A系统也就凉了，这就是耦合带来的问题。
假如我现在用消息队列，就是这样子的。
即使B系统crash，A系统照常运行，A只需要把消息给到消息队列就可以。 - 异步
假如现在有这么个业务场景，分别有三个系统，用户支付成功后，支付系统调用生成订单系统来生成订单，再继续调用通知用户业务系统，最后返回给支付系统，是不是支付系统要等半天？
用户就想了，我tm等半天才能下个单，以后不在你这买了，这就损失了一名客户
加上消息队列会咋样？
依然是一个链式调用，不同的是，这次支付系统把任务信息告诉消息队列就可以了，剩下的事情，他就不管了，而是又消息队列和其他系统合作去完成。
- 削峰
RocketMQ可是阿里巴巴拿来抗双十一的中间件，你说刚不刚？
我们都知道，如果同时给服务器本不该承受的压力，它就会宕机。
而消息队列在削峰方面的思想就是，把大量的订单都放到消息队列里，挨个去处理，这样的结果可能是有的用户下单要等的久一些才能成功，但是好处就在于服
务器不会凉凉鸭，如果凉了，还卖啥？
一、 RocketMQ的组成
-
Message : 消息
-
Broker: RocketMQ的核心模块，负责接收并存储消息。
-
NameServer: RocketMQ的注册中心，集群的Topic-Queue的路由配置；Broker的实时配置信息。其它模块通过Nameservr提供的接口获取最新的Topic配置和路由信息。
-
Topic ：用于将消息按主题做划分，Producer将消息发往指定的Topic，Consumer订阅该Topic就可以收到这条消息。Topic跟发送方和消费方都没有强关联关系，发送方可以同时往多个Topic投放消息，消费方也可以订阅多个Topic的消息。在RocketMQ中，Topic是一个上逻辑概念。消息存储不会按Topic分开。
-
Tag： 标签可以被认为是对 Topic 进一步细化。一般在相同业务模块中通过引入标签来标记不同用途的消息。
-
Producer：消息的生产者
-
Consumer：消息的消费者
二、RocketMQ的整体架构
从上面抽象来看，RocketMQ的原理在于：
- 生产者将消息给到队列(Broker)
- 队列中的消息在逻辑上是以Topic来分类的，进一步还可以通过Tag来过滤
- 消费者消费消息
从下面这个图，可以看到Rocket MQ天生就是分布式的，Broker作为存储消息的核心组件，支持主从机制，一个挂了，我还有备用呢。
无论是Broker还是Name Server 都可以做分布式，从而让整个系统变得高可用
- 每个Broker与Name Server集群中的所有节点建立长连接，定时注册Topic信息到所有Name Server。
- Producer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息。
- Consumer与Name Server集群中的其中一个节点（随机选择）建立长连接，定期从Name Server取Topic路由信息。
参考
https://www.cnblogs.com/qdhxhz/p/11094624.html
http://jm.taobao.org/2017/01/12/rocketmq-quick-start-in-10-minutes/
本人水平有限，希望各位不吝赐教。
