经过近一个多月的迭代，万众期待的Apach RocketMQ 4.7.0 版终于发布啦！该版本不仅对原有的功能进行了增强，修复了多个bug。此外对原有的同步双写进行全新升级，极大地提升同步双写的性能。
同步双写极致性能优化
如上图所示，在RocketMQ 4.7.0之前，RocketMQ 同步双写Master broker处理一个发送消息的请求主要分为四步：
将消息写入commitlong
提交一个GroupCommitRequest 到同步复制服务HAService
等待HAService通知GroupCommitRequest被完成（复制位点大于等于该消息的写入位点）
返回写入结果并响应客户端
在这种阻塞模式下，Master broker的发送消息处理器SendMessageProcessor线程需要等待消息被同步到Slave才能处理新的请求。假设SendMessageProcessor包含四个线程，如果四个线程都在等待，则系统在这一瞬间无法处理新发送消息请求，造成CPU资源无法被充分利用。
为了解决这一问题，RocketMQ 4.7.0重新升级了同步双写的架构。SendMessageProcessor线程不再等待消息复制到Slave节点后再处理新请求，而是提前生成CompletableFuture并返回，并马上处理新的请求。而HAService中的线程在Slave的复制位点超过消息的写入位点后去完成对应的CompletableFuture，并通知remoting模块响应客户端。通过上述方式我们对消息的写入过程进行切分并将其流水线化，减少了线程等待，提高性能。
下图展示社区对吞吐量和延迟的测试情况，其中async表示异步复制，wait表示优化前的同步双写，pipeline表示优化后的同步双写。可以看出，优化后的同步双写吞吐量提升非常明显，相比优化前提升十倍，基本与异步复制吞吐量持平。在延迟方面，优化之后的同步双写也比优化之前有明显的降低。 
据不完全统计，有近十位RocketMQ社区的contributor参与了该版本的贡献，感谢大家的积极参与。其中来自ByteDance的同学对此次同步双写性能优化做了重要贡献，并已经在生产使用。非常期待更多的用户、厂商参与到RocketMQ建设中来，共同打造新一代云原生消息数据处理平台。
