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, 李煜洲 <iamzhou...@gmail.com> wrote: 
> hi,大家好。我是美团基础架构部的李ç…
> œæ´²ï¼Œæœ€è¿‘在对rocketmq做一些性能方面的测试,在阅读代ç 
> çš„时候发现两个问题,希望和大家讨论一下
> 1、AppendMessageResult
> doAppend函数,作用是把具体的消息æ 
> ¼å¼åŒ–并刷到Commitlog的bytebuffer里面,但是感觉处理逻辑有些性能损耗,我看代ç
>  æ˜¯å…ˆæŠŠmessage的消息内
> 容以及等等一些信息统一写到名为msgStoreItemMemory的bytebuffer里面,然后再把msgStoreItemMemory刷到底层commitLog的bytebuffer里面,感觉如果我的单条消息的body非常大的话,反复拷贝来拷贝去带来的性能开销还是蛮大的
> 2、发送消息后处理落盘方式和主从同步的代ç 
> éƒ¨åˆ†ï¼Œæ„Ÿè§‰è¿™éƒ¨åˆ†å®Œå…¨å¯ä»¥å¼‚步化的,但是我看代ç 
> ä½¿ç”¨äº†wait和notify的方式进行了,rocketmq也是用的reactor网络模型,在真实网络环境下,主从同步不及时是比较容易出现的问题,一旦用了wait+notify
> 意味着上面的处理线程会被å 
> µä½ï¼Œæ•´ä½“的吞吐就上不去了,周末对rocketmq做性能测试,主要耗时点有一个就是åŠ
>  é”è§£é”ï¼Œæ„Ÿè§‰å’Œè¿™ä¸ªæœ‰å¾ˆå¤§å…³ç³»
> 

Reply via email to