这两块我可以参与一起开发吗？ 我对这两块挺感兴趣的，我本来也是要计划把整个nameserver用paxos协议重写，对整个集群做服务发现和流量调度
在 2018年3月13日 下午3:43，Jixiang Jin <[email protected]>写道： > > Hi，RocketMQ目前版本中的多副本方案从主备复制模式上分为同步双写和异步双写模式；同时在落盘方式上也分为同步和异步方式；通过这两者的配置， > 可以让整个系统在可用性以及消息的可靠性上有所侧重，具体可以参考： > org.apache.rocketmq.store.config.MessageStoreConfig#flushDiskType > org.apache.rocketmq.store.config.MessageStoreConfig#brokerRole > > 两个配置项。 > > 同时我们也正在基于Raft、Paxos分布式一致性协议设计新一代的多副本方案，后续可以关注下。如果对这方便有兴趣，欢迎邮件交流。 > > On 2018/03/13 03:56:08, 李煜洲 <[email protected]> wrote: > > hi，大家好。我是美团基础架构部的李煜洲，最近在对rocketmq做一些性能方面的测试，在阅读代码的时候发现两个问题，希望和大家讨论一下 > > 1、AppendMessageResult > > doAppend函数，作用是把具体的消息格式化并刷到Commitlog的bytebuffer里面，但是感觉处理逻辑有些性能损耗， > 我看代码是先把message的消息内容以及等等一些信息统一写到名为msgStoreItemMemory的bytebuffer里面， > 然后再把msgStoreItemMemory刷到底层commitLog的bytebuffer里面，感觉如果我的单条消息的body非常大的话， > 反复拷贝来拷贝去带来的性能开销还是蛮大的 > > 2、发送消息后处理落盘方式和主从同步的代码部分，感觉这部分完全可以异步化的，但是我看代码使用了wait和notify的方式进行了， > rocketmq也是用的reactor网络模型，在真实网络环境下，主从同步不及时是比较容易出现的问题，一旦用了wait+notify > > 意味着上面的处理线程会被堵住，整体的吞吐就上不去了，周末对rocketmq做性能测试，主要耗时点有一个就是加锁解锁，感觉和这个有很大关系 > > >
