RocketMQ——补充

以后有需要注意的小知识点，就随时在这里补充……

多Master多Slave

由于在之前的博客（RocketMQ（二）——集群部署）中已经搭建了双Master，其实多Master多Slave大同小异，因此这里并不会一步步的演示搭建多Master多Slave，而是从思路上，分析下重点应该注意的配置项。

多Master多Slave

1. 这四台机器，对外是一个统一的整体，是一个rocketmq cluster，因此需要brokerClusterName保持统一;
2. 123机器是121的从，124机器是122的从，如何在配置中体现？ 主和从的brokerName需要保持一致，另外brokerId标示了谁是主，谁是从（brokerId=0的就是主，大于0的就是从）;
3. 注意namesrvAddr的地址是4台NameServer;
4. 配置项中brokerRole需要指明 ASYNC_MASTER（异步复制Master） or SYNC_MASTER（同步双写Master） or SLAVE（从）;
5. 和以前的多Master启动方式一致，先启动4台Namesrv，然后用指定配置文件的方式启动Master/Slave即可;
6. 多Master多Slave的好处在于，即便集群中某个broker挂了，也可以继续消费，保证了实时性的高可用，但是并不是说某个master挂了，slave就可以升级master，开源版本的rocketmq是不可以的。也就是说，在这种情况下，slave只能提供读的功能，将失去消息负载的能力。

Queue in Topic

对于RocketMQ而言，Topic只是一个逻辑上的概念，真正的消息存储其实是在Topic中的Queue中。想一想，为什么RocketMQ要这要设计呢？其实是为了消息的顺序消费，其他文中（RocketMQ（六）——Order Message(顺序消息)）有介绍。

queue in topic

默认一个Topic中4个队列

当然可以在上面代码中修改，还有可以从配置文件中指定：

# 在发送消息时，自动创建服务器不存在的topic，默认创建的队列数defaultTopicQueueNums=4

RocketMQ的核心模块

RocketMQ的核心模块

• rocketmq-broker：接受生产者发来的消息并存储（通过调用rocketmq-store），消费者从这里取得消息。
• rocketmq-client：提供发送、接受消息的客户端API。
• rocketmq-namesrv：NameServer，类似于Zookeeper，这里保存着消息的TopicName，队列等运行时的元信息。（有点NameNode的味道）
• rocketmq-common：通用的一些类，方法，数据结构等
• rocketmq-remoting：基于Netty4的client/server + fastjson序列化 + 自定义二进制协议
• rocketmq-store：消息、索引存储等
• rocketmq-filtersrv：消息过滤器Server，需要注意的是，要实现这种过滤，需要上传代码到MQ！【一般而言，我们利用Tag足以满足大部分的过滤需求，如果更灵活更复杂的过滤需求，可以考虑filtersrv组件】
• rocketmq-tools：命令行工具

RocketMQ Filter组件介绍

对于ActiveMQ而言，我们可以通过JMS Selectors机制（就是类似于SQL的语法）来实现过滤，很easy。那么和RocketMQ Filter组件有什么区别呢？
虽然，2者都能实现过滤，但是RocketMQ Filter的性能要更高效些，因为RocketMQ是在broker上将过滤后的数据发往filter，然后消费者直接从filter上取得数据；而ActiveMQ是消费者直接在broker上进行过滤消费！（当然，对于RocketMQ而言，Tag机制已经足够应付日常绝大数的过滤功能，除非你的业务对性能有特别高的要求）

RocketMQ Filter机制

具体怎么做呢？这里我就不演示了，网上有很多例子，这里只说下大致的过程：

• 第一：broker-xxx.properties中指定filter个数
• 第二：上传一段JAVA代码，其实就是一个类