是的,我也同意这种观点。我的意思是如果可以提高同步情况下的整体吞吐量是否会更好呢?另外如果对于需要绝对可靠的
业务场景(如金融的一些特殊场景),只能使用同步落盘,而这种模式下,如果让上层的处理线程同步等待刷盘结果,似乎效率也不是很高,假设磁盘IO稍微慢一些,就会出现大量请求无法得到处理。
还有就是第一个问题还请帮忙分析下是否有道理呢?

On 2018/03/13 06:35:52, "KaiYuan Yang" <m...@alibaba-inc.com> wrote:
>
主从之间的同步,支持同步和异步两种方式。异步的吞吐量高,但是Master故障时,可能造成一些消息没及时同步到Slave;有些场景对可靠性要求高而且数据量不大,可以用同步方式。------------------------------------------------------------------发件人:李煜洲
<ia...@gmail.com>发送时间:2018年3月13日(星期二) 11:56收件人:users <
us...@rocketmq.apache.org>主 题:rocketmq性能提升相关问题咨询>
>
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