RocketMQ

集群的搭建：
双主双从集群搭建：
Host添加信息：集群的端口映射
防火墙配置
配置环境变量
创建消息存储路径
broker配置文件 conf下的2m2s-sync

nameServer的地址，分号分割
namesrvAddr = nameserver：9876；
Broker 的角色
ASYNC_MASTER 异步复制Master
SYNC_MASTER 同步双写Master
SLAVE
brokerRole = SYNC_MASTER

刷盘方式
ASYNC_FLUSH异步刷盘
SYNC_FLUSH同步刷盘
flushDiskType=SYNC FLUSH

消费：广播模式，负载均衡模式
顺序消费
保证顺序消费：
保证生产者顺序
保证同一订单消息生产到同一队列（取模）
保证消费者顺序
注册顺序消息监听器：MessageListenerOrderly，保证同一队列只有一个线程消费

消息丢失
0x01. 生产阶段
消息发送成功后，等待broker返回SendStatus.SEND_OK状态
我们可以设置合理的重试次数，当出现网络问题，可以自动重试。
0x02. Broker 存储阶段
若想保证 Broker 端不丢消息，保证消息的可靠性，我们需要将消息保存机制修改为同步刷盘方式，即消息存储磁盘成功，才会返回响应。
集群部署
为了进一步提高消息的可靠性，我们可以采用同步的复制方式，master节点将会同步等待 slave 节点复制完成，才会返回确认响应。
推荐：异步刷盘保证吞吐量，同步复制保证消息不丢失
0x03. 消费阶段
我们需要注意返回消息状态。只有当业务逻辑真正执行成功，我们才能返回 ConsumeConcurrentlyStatus.CONSUME_SUCCESS。否则我们需要返回 ConsumeConcurrentlyStatus.RECONSUME_LATER，稍后再重试。
消息重试
消息重试分为两种：Producer发送消息的重试和 Consumer消息消费的重试。
消费者和生产者的重试还是有区别的，主要有两点
1、默认重试次数：Product默认是2次，而Consumer默认是16次。
2、重试时间间隔：Product是立刻重试，而Consumer是有一定时间间隔的。它照1S,5S,10S,30S,1M,2M····2H进行重试。
3、Product在异步情况重试失效，而对于Consumer在广播情况下重试失效。
重复消费问题
消息系统，对于未确认的消息，采用按规则重新投递的方式进行处理。
方案一： 分布式锁
方案二：数据库约束或者redis约束
方案三：查询消息系统验证消息是否重复（较为负责，不予采纳）