一、使用rocketMq遇到的问题
1、producer:
1）、消息投递失败
2）、需要延迟投递
2、nameserver:
宕机也不会造成消息丢失，单点故障有集群
3、broker:
1）、 消息同步过程中,broker宕机出现丢失
2）、硬件设备损坏
4、consumer:
1）、消费消息失败
2）、重复消费
二、rocketMq的解决方案
1、producer:
1）、发送方式：同步或异步
2）、消息类型：事务消息、延迟消息
事务消息使得本地事务 和 消息投递 一起执行。如工行用户A向建行用户B转账1万。
2.1）、使用同步消息：
2.1.1）、工行系统发送一个同步消息给Mq,给建行用户B增加1万
2.1.2）、Mq返回ACK
2.1.3）、工行用户A扣款
这个流程中工行用户A扣款执行失败，就会造成数据不一致，即建行用户B增加扣款成功，工行用户A没有扣款。
2.2）使用事务消息：
2.2.1）、工行系统发送一个事务消息给Mq,给建行用户B增加1万
2.2.2）、Mq存储half message返回ack
2.2.3）、工行系统通过executeLocalTransaction执行本地事务，扣款用户A的1万，向mq返回ack
2.2.4）、mq收到commit ack时，建行系统可以消费这个消息,如果一直没向mq返回ack，则mq会进行回查
2.2.5）、producer则查看本地事务执行结果，向mq返回确认消息
2.3)、延迟消息：RocketMQ?延迟消息，不支持任意时间精度，支持特定的 level有18个，例如定时 1s,5s，10s，1m 等。该功能由ScheduleMessageService实现?
?
2、nameserver:
宕机也不会造成消息丢失，单点故障有集群
3、broker:
1）、 消息同步过程中,broker宕机出现丢失
修改配置为同步刷盘策略。
broker存储到内存(PageCache)，响应生产者，再同步到磁盘丢失。
虽减少IO次数，但丢失，则可以通过同步刷盘，消息存储到磁盘，再响应。
修改 Broker 端配置：
flushDiskType = SYNC_FLUSH
若 Broker 未在同步刷盘时间内（默认为 5s）完成刷盘，将会返回 SendStatus.FLUSH_DISK_TIMEOUT 状态给生产者
2）、硬件设备损坏
多 Master?多 Slave?模式，同步双写(主从复制)。
硬件设备损坏（主从复制丢失）
为了保证可用性，Broker 通常采用一主（master）多从（slave）部署方式。为了保证消息不丢失，消息还需要复制到 slave 节点。此时master宕机，消息丢失，则应当同步到slave后再返回。
Broker master 节点 同步复制配置：
ASYNC_MASTER brokerRole=SYNC_MASTER
如果 slave节点未在指定时间内同步返回响应，生产者将会收到SendStatus.FLUSH_SLAVE_TIMEOUT 返回状态。
4、consumer:
1）、消费消息失败
重试队列和死信队列。
消费消息失败返回ConsumeConcurrentlyStatus.RECONSUME_LATER，失败小于18次在重试队列中，超过18进入死信队列。
2）、重复消费
message的keys中放入唯一的业务key，业务自己去重。