RocketMQ4.8.0 dledger模式初体验——尚存在严重BUG

RocketMQ 4.7.1时期就尝试了dledger集群，但是当时dledger集群有严重的性能问题。

同样服务器配置，master-slave模式测试TPS最高可以超过10万，dledger模式最高只有13000。

   盼了几个月，终于盼来了据说会改善dledger性能的4.8.0版本。

   测试了一下，性能果然有很大提升，完全不比master-slave模式差了。TPS随随便便也达到了八九万。但是测了一会发现，我高兴的太早了。因为master经常会莫名其妙的发生切换。

1，经过几次测试，发现消息堆积接近三千万(0.5k消息体，三千万可以占内存20G+，虽然从系统层面只是cached的内存）时必定发生切换，因此怀疑是本地内存满造成的切换。

2，切换之后原来的master 变为slave，因为要同步数据，TPS一直低于另外两个节点（数据领先的两个节点TPS8万，追同步的节点不到三万），造成数据与其他两个节点始终不同步。

By the way，试过master-slave模式下，数据同步的速率要高的多。

3，这时发送消息，返回结果是send_ok，说明三个节点只要两个节点数据一致就可以返回send_ok。因为无法保证三个节点数据强一致，机房级的灾备不能单靠dledger集群实现了。

4，停止与master同步的那个slave节点，发现master与slave不同步之后，master会禁写，slave节点会继续同步。

5，如果是master宕，另外两个slave之间数据不同步，则不会发生选主，同步会继续，同步完成后才会选主。

6，master存在，数据不同步时，消费不受影响，但如果没有master，则消费也不会进行。

7,  同步完成后，可以正常写入。

结论：

1，可以看出dledger是有一些机制保证数据一致性的。但是消息堆积后切主和不同步的节点tps低属于严重的BUG，生产环境完全不能使用。   

补充：

另外还发现了两个小问题。

1，如果不设置storePathCommitLog，会有如下的报错

2021-01-07 16:04:32 ERROR DiskCheckScheduledThread1 - Error when measuring disk space usage, file doesn't exist on this path: /rocketmq/store/commitlog

如果设置storePathCommitLog，设置的路径还是不存在

这是个bug。我看社区说下个版本会解决。

2，还有就是注意集群任何一个成员停止或者启动时，其他两个节点的TPS都会降为0再增加，影响几十秒，会造成不少消息生产失败。因此启动宕机的节点时最好通知用户这个影响。