rocketmq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zhanhui Li <lizhan...@gmail.com>
Subject Re: 关于 master broker 宕机,导致的消费实时性问题
Date Sat, 10 Jun 2017 14:58:37 GMT
1. 路线图主要提供的是发展方向版本规划;
2. 具体的那个版本包含哪些功能, 在哪一天发布, 有很多因素影响; 其中一个最重要的因素就是社区开发活跃度;
如果contributor很多, 参与review的同学也很活跃, 相信这个日期会很快.
3. 主备自动切换, 其实也不是”silver bullet”, 比如切换过程, 一般也得几十秒;
如果实现完全的自我选举, 类paxos协议可能会需要更多机器; 模型复杂度,
数据一致性都不是很简单能实现的.
4. 主备不仅仅是"这个备仅仅是在主挂的时候提供读消息”, 这个起码提供了读写分离;
5. "本来只愿要3台机器,但为了确保高可靠,就需要6台机器,如果集群多了,成本就多很多”
作为软件工程师, 满足需求的情形下, 解决成本问题是能体现创造力的一个方面,
感兴趣的话, 可以到我们的meetup, 我届时会分享一下我们怎么用几乎是两台机器的成本实现两主两备高可用可支撑无限积压的.

> 在 2017年6月10日,下午10:30,维彤 <342407712@qq.com <mailto:342407712@qq.com>>
写道:
> 
> 我们知道两主的方案,也知道roadmap,但是没有说明具体放在4.1还是4.2,还是哪个版本,发布日期是什么时候。既然有主备,如果不能做到自动切换,这个备仅仅是在主挂的时候提供读消息,就显得特别浪费,尤其是在有多个备的情况下。本来只愿要3台机器,但为了确保高可靠,就需要6台机器,如果集群多了,成本就多很多。请各位重点考虑下,高可靠都没有做好,其他那些open
messaging等功能又有多少人会用到呢? 
> 
> 
> ------------------ 原始邮件 ------------------
> 发件人: "Zhanhui Li" <lizhanhui@gmail.com <mailto:lizhanhui@gmail.com>>;
> 发送时间: 2017年6月10日(星期六) 22:15
> 收件人: "维彤" <342407712@qq.com <mailto:342407712@qq.com>>;
> 抄送: "users" <users@rocketmq.incubator.apache.org <mailto:users@rocketmq.incubator.apache.org>>;"yukon"
<yukon@apache.org <mailto:yukon@apache.org>>;
> 主题: Re: 关于 master broker 宕机,导致的消费实时性问题
> 
> 
> 具体的开发计划, 请参考路线图: http://rocketmq.apache.org/docs/roadmap/ <http://rocketmq.apache.org/docs/roadmap/>
> 
> 欢迎大家一起贡献, 尽快的将计划落地实施.
> 
> 其实, 如果认真了解下设计, 目前的版本, 部署两组以上的主备, 可靠性其实已经非常高了,
应该能满足绝大多数用户生产上的需求. 主备自动切换, 并没有想象的那么必须.
当然, 如果您具体的场景特殊, 可以进一步讨论.
> 
>> 在 2017年6月10日,下午9:31,维彤 <342407712@qq.com <mailto:342407712@qq.com>>
写道:
>> 
>> 请问主备自动切换的功能已经在做了吗?大概推出的版本和时间是什么呢?似乎可靠性比其他高级特性更迫切一些,更能满足大家的需求。

>> 
>> 
>> ------------------ 原始邮件 ------------------
>> 发件人: "Zhanhui Li" <lizhanhui@gmail.com <mailto:lizhanhui@gmail.com>>;
>> 发送时间: 2017年6月10日(星期六) 21:19
>> 收件人: "users" <users@rocketmq.incubator.apache.org <mailto:users@rocketmq.incubator.apache.org>>;
>> 抄送: "yukon" <yukon@apache.org <mailto:yukon@apache.org>>;
>> 主题: Re: 关于 master broker 宕机,导致的消费实时性问题
>> 
>> 
>> 我个人看, 这个方案是可行的.
>> 
>>  一定程度上, 能减少消费的延迟. 本质上, 跟发送重试是一个思路.

>> 
>> 有一点需要注意: 考虑到pull一般情况下都是long polling, 考虑到网络抖动和异步复制模式下主备复制可能的延迟,
因异常向备机请求建议使用short-polling; 也就是说, 主在订阅信息中存在的情况下,
long polling主 —> 失败 —> short-polling备; 下一轮接着long polling 主;
 
>> 
>> 
>>> 在 2017年6月10日,下午6:59,goman <2896078362@qq.com <mailto:2896078362@qq.com>>
写道:
>>> 
>>> 感谢回复 !
>>> 
>>> 以我的理解,既然consumer会连接一个master broker下的所有slave,那么在发送pull
request时一旦出现系统级别的异常,就尝试往下一个broker address发送request。
>>> 
>>> 如果此类情况重复出现n次,则由consumer主动切换优先消费的broker
address。
>>> 
>>> 通过这种方式实现broker宕机带来的消费实时性问题,大家觉得方案可行么?
>>> 
>>> 
>>> ------------------ 原始邮件 ------------------
>>> 发件人: "yukon";<yukon@apache.org <mailto:yukon@apache.org>>;
>>> 发送时间: 2017年6月9日(星期五) 晚上10:35
>>> 收件人: "users"<users@rocketmq.incubator.apache.org <mailto:users@rocketmq.incubator.apache.org>>;
"goman"<2896078362@qq.com <mailto:2896078362@qq.com>>;
>>> 主题: Re: 关于 master broker 宕机,导致的消费实时性问题
>>> 
>>> NameServer发现Broker宕机最糟糕的情况下确实需要两分钟才会移除掉已宕机Broker。
>>> 
>>> 对于Producer发送消息会重试到其它健康的Broker,甚至提供了隔离机制快速隔离异常Broker,详见MQFaultStrategy。
>>> 
>>> Consumer消费是依赖Topic路由信息进行拉取的,确实有一定的延迟,对于消费延迟大多数场景下是可接受的,主机宕机的情况下最好的处理方式还是监控机制发现这一情况并及时将备机切回主机。
>>> 
>>> 
>>> 
>>> 2017-06-08 10:03 GMT+08:00 goman <2896078362@qq.com <mailto:2896078362@qq.com>>:
>>> hi all,想请教个问题,一旦 master broker 宕机,consumer 最多会在
(2分钟 + 30秒) 后才能切换到消费slave么?
>>> 
>>> 据我了解,一台 broker 宕机时,namespace 在2分钟(不可配置)内没有收到Broker心跳,认为该Broker下线并调整本地Topic跟Broker的对应关系;
>>> 但此时NameServer不会主动通知Producer、Consumer有Broker宕机。
>>> 同时,consumer在向broker发送pull request时,及时发送异常也不会切换下次重试访问的broker
address(这个逻辑我看得是 4.0.0 版本源码,不确认理解是否正确)。
>>> 只有当consumer每隔30秒(可配置)从nameserver获取topic的最新队列情况时,才会删除本地异常
master broker 地址,这时pull request才会发到 slave 。
>>> 
>>> 请问我理解的对么?
>>> 
>> 
> 

Mime
View raw message