一、消息丢失的问题

1. 当你系统需要保证百分百消息不丢失，你可以使用生产者每发送一个消息，Broker 同步返回一个消息发送成功的反馈消息

2. 即每发送一个消息，同步落盘后才返回生产者消息发送成功，这样只要生产者得到了消息发送生成的返回，事后除了硬盘损坏，都可以保证不会消息丢失

3. 但是这同时引入了一个问题，同步落盘怎么才能快？

二、同步落盘怎样才能更快

1、使用 FileChannel + DirectBuffer 池，使用堆外内存，加快内存拷贝

2、使用数据和索引分离，当消息需要写入时，使用 commitlog 文件顺序写，当需要定位某个消息时，查询index 文件来定位，从而减少文件IO随机读写的性能损耗

三、消息堆积的问题

1、后台定时任务每隔72小时，删除旧的没有使用过的消息信息

2、根据不同的业务实现不同的丢弃任务，具体参考线程池的 AbortPolicy，例如FIFO/LRU等（RocketMQ没有此策略）

3、消息定时转移，或者对某些重要的 TAG 型（支付型）消息真正落库

四、消息的定时实现

1、实际 RocketMQ 没有实现任意精度的定时消息，它只支持某些特定的时间精度的定时消息

2、实现定时消息的原理是：创建特定时间精度的 MessageQueue，例如生产者需要定时1s之后被消费者消费，你只需要将此消息发送到特定的 Topic，例如：MessageQueue-1 表示这个 MessageQueue 里面的消息都会延迟一秒被消费，然后 Broker 会在 1s 后发送到消费者消费此消息，使用 newSingleThreadScheduledExecutor 实现