RocketMQ

消息中间件的作用：异步解耦、挡住前段数据洪峰（保证后端系统稳定性）
RocketMQ 通信组件使用了Netty-4.0.9.Final，在之上做了简单的协议封装
单机支持1 万以上持久化队列

MQ面临哪些问题？
1、最基本功能：发布和订阅
2、优先级问题：一个队列中，消息按优先级排序，优先级高的消息优先投递；
rocketMQ中的所有消息都是持久化的，排序会带来性能损耗，所以暂不支持优先级，但是可以建立多个不同队列，每个队列代表不同优先级。
4、消息的顺序：按照消息的发送顺序来消费，rocketMQ与两个不同的顺序级别解决该问题
5、消息过滤：Broker端和Consumer端消息过滤两种，前者可以减少对consumer无用消息的网络传输
6、持久化：有多种持久化方式，如数据库，文件系统，对内存的镜像等。rocketMQ采用文件系统kafka
7、消息的可靠性：
(1). BrokerBroker Broker 正常关闭
(2). BrokerBroker Broker 异常Crash
(3). OS Crash
(4). 机器掉电，但是能立即恢复供情况。
(5). 机器无法开（可能是 cpu cpu、主板内存等关键设备损坏）
(6). 磁盘设备损坏。

    1-4：属于硬件资源可以恢复，rocketMQ可以保证数据不丢或者少量丢失（依赖刷盘方式是同步还是异步）
    5-6：属于无法恢复，通过“异步复制“，可以实现99%的消息不会丢失，也可以用“同步双写”来完全避免，但会影响性能（rocketMQ3.0后支持）

8、消息的延迟：在消息不堆积的情况下，消息到达broker后，是否能立刻到达consumer
rocketMQ使用长轮询pull的方式，保证消息的非常实时，实时性不低于push
9、每个消息必须投递一次：
rocketMQ通过pull将消息推送到本地，本地消费完后，向服务器返回ack
10、发送/接收重复数据：
rocketMQ没有严格实现这两点，需要consumer自己去校验
该问题产生的场景：网络调用存在不确定性，即不知道消费者的最终接收状态，所以才产生重复发送/消费
11、broker的buffer满了怎么办
buffer指一个队列的内存大小，这个内存大小通常有大小限制，如果buffer满了怎么办？
规范要求通常情况下两种方案，第一拒绝新来的消息；第二按不同策略丢弃已有消息
rocketMQ没有buffer的概念，队列都是持久化磁盘，数据定期清理
12、回溯消费：
即被consumer消费成功得消息，该消息仍需要保留。一般重新消费是按时间维度，如consumer系统故障，回复后，需要重新消费1小时之前的数据
rocketMQ支持按时间回溯，可以向前，也可以向后
13、消息堆积
14、分布式事务
15、定时消息：
消息不能立刻被消费，需要特点时间点或特定时间后
rocketMQ支持后者
16、消息重试：
两种场景：一、消息非法，导致接收端不能正常处理，可以跳过该消息，10s后重试；二、接收端服务器停掉，此时再怎么重试也不行，此时建议应用停止30s后再发送下一条

数据结构：所有数据单独存储到一个Commit Log，完全顺序写，随机读；
对最终用户展现的队列实际只存储消息在Commit Log 的位置信息，并且串行方式刷盘
这样做的好处如下：
队列轻量化，单个数据非常少。
对磁盘的访问串行化，避免磁盘竞争
缺点
读一条消息要先读consumer queue，再度commit log
刷盘策略：
RocketMQ 的所有消息都是持丽化的，先写入系统PAGECACHE，然后刷盘，可以保证内存不磁盘都有一份数据，
访问时，直接从内存读叏。
不会出现内存溢出！！！
两种策略：一、异步，消息写入pagecache，异步线程同步内存数据到磁盘；二、同步，消息写入pagechache后，通知写磁盘线程执行，执行完后，通知前端等待线程向用户返回成功
长轮询Pull：
RocketMQ 的Consumer 都是从Broker 拉消息来消费，但是为了能做到【实时收消息】，RocketMQ 使用长轮询方
式，可以保证消息实时性同Push 方式一致。返种长轮询方式类似亍Web QQ 收収消息机制。
顺序消息缺陷
事务消息
发送消息负载均衡
订阅消息负载均衡
同步双写\异步复制：
异步复制的实现思路非常简单，Slave 启劢一个线程，丌断从Master 拉叏Commit Log 中的数据，然后在异步
build 出Consume Queue 数据结构。整个实现过程基本同Mysql 主从同步类似。同步性能低于异步10%左右
RocketMQ消息过滤：
consumer.subscribe(“TopicTest1”, “TagA || TagC || TagD”);
如以上代码所示，简单消息过滤通过挃定多个Tag 来过滤消息，过滤劢作在服务器迕行
高级过滤：
1、Broker 所在的机器会启劢多个FilterServer 过滤迕程
2. Consumer 启劢后，会向FilterServer 上传一个过滤的Java 类
3. Consumer 从FilterServer 拉消息，FilterServer 将请求转収给Broker，FilterServer 从Broker 收到消息后，挄照
4、Consumer 上传的Java 过滤程序做过滤，过滤完成后迒回给Consumer。