一、Broker集群部署方式：

1、单Master：这种方式风险较大，一旦 BrokerBroker Broker 重启或者宕机时，会导致整个服务不可用 ，不建议线上使用

2、多Master,无Slave：

优点：配置简单，性能最高

缺点：单台机器宕机期间，这台机器上未被消费的消息在恢复之前不可订阅，消息实时性会受到影响。多master多slave方式一台master宕机后，在回复之前可以从slave里消费，master恢复后再同步slave

3、多Master多Slave，异步复制   主备有短暂消息延迟，毫秒级

优点：性能同多Master几乎一样，实时性高，主备间切换对应用透明，不需人工干预

缺点：Master宕机或磁盘损坏时会有少量消息丢失

4、多Master多Slave，同步双写  主备都写成功，向应用返回成功

优点：服务可用性与数据可用性非常高
缺点：性能比异步集群略低，当前版本主宕备不能自动切换为主

二、RocketMq消息永远持久化，即producer发送的消息，consumer未消费，关机后重启仍然存在。

三、启动顺序先启consumer,再启producer。否则会产生重复消费的问题

四、consumer消息的消费方式是一条一条消费的，虽然api上定义的是list，即使设置了批量消费size

consumer.setConsumeMessageBatchMaxSize(10);
consumer.registerMessageListener(new MessageListenerConcurrently() {
            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
                ConsumeConcurrentlyContext context) {
                System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
});

 先启动producer,再启动consumer消费消息时setConsumeMessageBatchMaxSize会起作用，进行批量消费

五、消息重试机制，包含producer的重试和consumer的重试

producer重试指生产者发送消息队列超时的重试，有默认配置，隔多久重试，会一直循环重试

consumer重试包含超时重试和exception重试

超时重试指消息队列发送consumer消息超时的重试，同producer重试机制，间隔一定时间重试，无限循环重试

exception重试指consumer消费代码抛出了异常返回ConsumeConcurrentlyStatus.RECONSUME_LATER;

可通过如下机制处理：

consumer.registerMessageListener(new MessageListenerConcurrently() {
            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs,
                ConsumeConcurrentlyContext context) {
                System.out.print("message size:" + msgs.size() + "  ");
                MessageExt message = msgs.get(0);
                try {
                    if(message != null) {
                        String topic = message.getTopic();
                        String tags = message.getTags();
                        String body = new String(message.getBody(),"UTF-8");
                        System.out.println("topic:" + topic +",tags:" + tags + ",body:" + body);
                        if("Hello RocketMQ 5".equals(body)) {
                            System.out.print(",msg:" + message);
                            int a = 5/0;
                        }
                    }
                } catch (Throwable e) {
                    e.printStackTrace();
                    if(message.getReconsumeTimes() > 2) {  //超过两次，记录日志，返回成功
                        //TODO logger.error("...");
                        System.out.println("重试次数超过2次...");
                        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
                    }
                    return ConsumeConcurrentlyStatus.RECONSUME_LATER;
                }
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });

 六、消费模式:广播和负载均衡,默认负载均衡方式

consumer.setMessageModel(MessageModel.BROADCASTING);  //广播

七、broker配置storePathCommitLog和storePathConsumeQueue作用

storePathCommitLog=/usr/local/rocketmq/store/commitlog  持久化存储消息

storePathConsumeQueue存储消息在commitLog中的位置信息，方便consumer快速查找消费

八、双consumer c1 c2消费，其中一个宕机再重启后可能产生重复消费问题，消费端代码需做幂等性控制

九、RocketMq里的一个很重要的概念就是GroupName。无论生产端还是消费端都必须指定一个groupname,主要用于负责均衡用的，制定了groupname，生产端或消费端一台宕机后，broker就会找groupname的另一台进行生产或消费。groupName在jvm维度上必须唯一。生产端和消费端的groupName可以不同。groupname维护在应用系统级别上，一类producer集合的名称，通常会发送一类消息，且发送逻辑一致。消费端也是如此。

 十、每个topic主题表示一个逻辑上存储的概念。而在其MQ上有与之对应的多个Queue队列，这是物理存储的概念