You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@rocketmq.apache.org by goman <28...@qq.com> on 2017/06/13 10:05:52 UTC
关于 master 下发重定向指令
hi all，想请教个问题
rocketmq 有一个master下发重定向指令的设计，逻辑是：mater一旦发现consumer访问堆积在磁盘的数据时，会向consumer下发一个重定向指令，令consumer从slave消费。
关于这个设计的理由，这篇文章解释是 “这样正常的发消息与正常消费的 Consumer 都不会因为消息堆积受影响，因为系统将堆积场景与非堆积场景分割在了两个不同的节点处理”
关于这个解释，发送消息的部分我可以理解，因为读写分离后，读请求不会再和写请求争用内存（用来加载目标文件page cache），在写请求时也就不触发page fault导致延迟。
但关于消费不会受到堆积影响，我没有理解：既然master会不断和slave进行同步，那么在slave还是会出现读写请求争用内存，导致page fault的现象。
所以关于读写分离后，消费消息不会受消息堆积影响，应该如何理解？
回复： 关于 master 下发重定向指令
Posted by goman <28...@qq.com>.
好的，谢谢
------------------ 原始邮件 ------------------
发件人: "Zhanhui Li";<li...@gmail.com>;
发送时间: 2017年6月13日(星期二) 晚上7:49
收件人: "users"<us...@rocketmq.incubator.apache.org>;
主题: Re: 关于 master 下发重定向指令
当大量堆积时, 最大的瓶颈是IO; Slave写数据, 是从Master成批处理的, 对IO消耗比较少, 而且, 即便IO wait高一点, 影响也很小(Master的话, 需要ack每一条发送的消息), 也就是主要实现了读写分离.
内存方面, 只要程序读写的那部分在物理内存, 就OK. 比如机器物理内存16G, 写的那部分, retain物理内存1/2G; 积压数据pull读取的时候, 只要留有足够的物理内存给磁盘预读, 影响就比较有限.
当然了, 当有很多consumer groups数据积压都比较严重, 他们的消费进度又各不相同, 各自都在消费不同时期的历史积压数据, 那这个时候, slave负载也会非常高, IO 负荷(即便电梯算法有IO合并), CPU IO Wait都会很高(这个当然也看存储随机读的能力了), 内存大量page fault(假定物理内存远远不够用), load自然也很高. 不过这种糟糕的情况, 除非故意模拟, 现实正常的环境不会走到这样的糟糕情景之中... 简单的说, 这种蹂躏情形下, 什么系统都是在崩溃的边缘.
在 2017年6月13日，下午6:05，goman <28...@qq.com> 写道：
hi all，想请教个问题
rocketmq 有一个master下发重定向指令的设计，逻辑是：mater一旦发现consumer访问堆积在磁盘的数据时，会向consumer下发一个重定向指令，令consumer从slave消费。
关于这个设计的理由，这篇文章解释是 “这样正常的发消息与正常消费的 Consumer 都不会因为消息堆积受影响，因为系统将堆积场景与非堆积场景分割在了两个不同的节点处理”
关于这个解释，发送消息的部分我可以理解，因为读写分离后，读请求不会再和写请求争用内存（用来加载目标文件page cache），在写请求时也就不触发page fault导致延迟。
但关于消费不会受到堆积影响，我没有理解：既然master会不断和slave进行同步，那么在slave还是会出现读写请求争用内存，导致page fault的现象。
所以关于读写分离后，消费消息不会受消息堆积影响，应该如何理解？
Re: 关于 master 下发重定向指令
Posted by Zhanhui Li <li...@gmail.com>.
当大量堆积时, 最大的瓶颈是IO; Slave写数据, 是从Master成批处理的, 对IO消耗比较少, 而且, 即便IO wait高一点, 影响也很小(Master的话, 需要ack每一条发送的消息), 也就是主要实现了读写分离.
内存方面, 只要程序读写的那部分在物理内存, 就OK. 比如机器物理内存16G, 写的那部分, retain物理内存1/2G; 积压数据pull读取的时候, 只要留有足够的物理内存给磁盘预读, 影响就比较有限.
当然了, 当有很多consumer groups数据积压都比较严重, 他们的消费进度又各不相同, 各自都在消费不同时期的历史积压数据, 那这个时候, slave负载也会非常高, IO 负荷(即便电梯算法有IO合并), CPU IO Wait都会很高(这个当然也看存储随机读的能力了), 内存大量page fault(假定物理内存远远不够用), load自然也很高. 不过这种糟糕的情况, 除非故意模拟, 现实正常的环境不会走到这样的糟糕情景之中... 简单的说, 这种蹂躏情形下, 什么系统都是在崩溃的边缘.
> 在 2017年6月13日，下午6:05，goman <28...@qq.com> 写道：
>
> hi all，想请教个问题
>
> rocketmq 有一个master下发重定向指令的设计，逻辑是：mater一旦发现consumer访问堆积在磁盘的数据时，会向consumer下发一个重定向指令，令consumer从slave消费。
>
> 关于这个设计的理由，这篇文章 <http://alibaba.github.io/RocketMQ-docs/document/design/RocketMQ_design.pdf>解释是 “这样正常的发消息与正常消费的 Consumer 都不会因为消息堆积受影响，因为系统将堆积场景与非堆积场景分割在了两个不同的节点处理”
>
> 关于这个解释，发送消息的部分我可以理解，因为读写分离后，读请求不会再和写请求争用内存（用来加载目标文件page cache），在写请求时也就不触发page fault导致延迟。
>
> 但关于消费不会受到堆积影响，我没有理解：既然master会不断和slave进行同步，那么在slave还是会出现读写请求争用内存，导致page fault的现象。
>
> 所以关于读写分离后，消费消息不会受消息堆积影响，应该如何理解？
>