介绍
RocketMQ是一款成熟的分布式消息中间件。
由阿里2012年开源，2017年成为Apache顶级项目。
源码是java写的。
高性能，低延迟，高可靠。历经多次双十一大促，整体很稳定。
RocketMQ对比其他mq的优势
对比kafka和Rabbitmq，RocketMQ优势如下：
1.支持事务型消息。
2.可以支持指定时间的延迟消费，但不能指定任意时间，RocketMQ有18个延迟级别。
3.支持消费失败的重试。
4.consumer可以tag过滤，tag可以理解为比topic更一个细粒度的子主题。
5.支持重复消费，这个kafka也支持。
RocketMQ核心四大组件
NameService，Broker，Producer，Consumer
每个组件可以部署成集群模式水平扩展。
1、Producer负责发消息，有3种发送方式
1.同步发送：重要场景，发一条要等接收方反馈成功，才会继续发。
2.异步发送：对响应时间有要求的场景，发一条后不等反馈，直接再发。
3.单向发送：量大但可靠性要求不高的场景，如日志收集。
同步发送就像打电话，你说一句，听到对面反馈了，再说。
异步发送就像发微信，你只管一直发，对面看到后也会反馈。
单向发送就像写信，写出去就不管了
2、Consumer负责消费消息，有2种消费方式
1.拉取型消费（DefaultMQPushConsumer）：主动拉消息
2.推送型消费（DefaultMQPullConsumer）：先去注册消费监听器，监听器被触发才会消费
3、Broker负责存储消息
接收Producer发的消息，存储，Consumer从这里拉取消息。
Broker有两个角色，Master和Slave。了解分布式协议的，对这两个主从角色肯定不陌生。
Broker集群部署有4种方式：
1.单Master，即都是主
一旦宕机，服务不可用，单机测试用，生产不会用
2.多Master
单个Master宕机，服务还是可用的，但宕机期间该机器的消息不能被实时消费了
3.多Master多Slaver（同步双写）
每个Master都配一个Slaver，写消息的时候，主从都写成功才算成功。
这个是解决了上一个主宕机后消息不能被实时消费的问题，但由于得写两份，性能略受影响
4.多Master多Slaver（异步复制）
每个Master都配一个Slaver，写消息的时候，主成功就成功返回，之后异步复制消息到从。
主从消息延迟是毫秒级。
这个是解决了上一个写两份的性能问题，但在主宕机且不可恢复的情况下，可能会由于消息延迟复制的原因，导致少量消息丢失。
这四种方式，每一种都是为了解决上一种的问题所作出的改进，但同时又会带来新的问题。
但慢慢的，可以将问题降到一个可人为控制并且可接受的范围内。
所以，在不考虑成本的情况下，第四种是最优的，但往往企业都会将成本放在比较高的位置，所以鱼与熊掌不可兼得。
4、NameServer负责保存Broker相关元信息并给生产者和消费者查找Broker信息
每个Broker启动的时候都会在NameServer注册，生产者在发送消息前也会根据Topic到这里获取Broker的路由信息。消费者也会定时获取topic的路由信息。
完全可以将NameServer理解成一个注册中心，因为早期没有NameServer的时候，这个位置是用Zookeeper代替的。
RocketMQ的消息Message
topic：
一条消息必须要有一个主题topic，这个和大部分消息中间件一样。
tag：
此外Message还有一个标签的概念，可以理解为子主题，可用可不用。
同一个topic下，当消息还有更细粒度的区分时，就可以通过tag标签来标记。
RocketMQ的消费模式
集群消费
默认是集群消费。
一个消费者集群共同消费一个主题。
广播消费
消息会发给消费组中的每一个消费者消费。