一、消息丢失的问题
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 实现