[Delayed Message] Delivered asynchronously to improve the performance of delayed messages #3449
Description
由于延迟消息每个level投递为单线程同步，在DLedger模式下投递性能存在瓶颈（详见下方测试结果）。今天改为延迟消息异步投递的方式验证了一下，性能有非常大的提升，下图为今天优化完后的测试数据，详细测试报告暂未输出。
同步投递模式下，对延迟消息单机部署和DLedger部署测试得到如下结果：
机器配置：
- CPU Silver4210*2
- 内存 DDR4_16G*8[2400]
- 磁盘 SSD_960G12[SATA_2.5_]
- RAID H330Mini_0G*1[LSI_3008]
- 操作系统 CentOS-7.3
参数：
- 默认消息大小 1KB
- 默认pullBatchSize=32
- queue个人为16
- 消费实例线程为16
1. 单机部署
- 单个延迟level（使用Timer，level=1，即1s）
- 边读边写：投递极限为3w+
- 存在消息积压，关闭生产：投递极限为8w+
- 多个延迟level（使用Timer，以3个level为例，level分别为1,2,3，即1s 5s 10s）
- 边写边读：投递极限为3w+
- 存在消息积压，关闭生产：投递极限为9w+
- 多个延迟level（使用ScheduledExecutorService，以3个level为例，level分别为1,2,3，即1s 5s 10s）
- 边写边读：投递极限为6w+
- 只读：投递极限为30w+
2. DLedger集群部署
使用ScheduledExecutorService
- 单个延迟level，开启batchPush（level=1，即1s）
- 边读边写：投递极限为700±
- 存在消息积压，关闭生产：投递极限为900±
- 单个延迟level，关闭batchPush（level=1，即1s）
- 边读边写：投递极限为1.2k~2k
- 存在消息积压，关闭生产：投递极限为3k
- 多个延迟level，开启batchPush（以3个level为例，level分别为1,2,3，即1s 5s 10s）
- 边写边读：投递极限为2k±
- 存在消息积压，关闭生产：投递极限为2.6k±
- 多个延迟level，关闭batchPush（以3个level为例，level分别为1,2,3，即1s 5s 10s）
- 边写边读：投递极限为1.6k~5k
- 只读：投递极限为7.8k±
ps: 写入对投递影响比较大
如需详细测试数据请告知。