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。