PDF《消息队列 CMQ》

消息队列 CMQ 版权所有:腾讯云计算(北京)有限责任公司 第1 共9页 消息队列 CMQ 最佳实践 产品文档 消息队列 CMQ 版权所有:腾讯云计算(北京)有限责任公司 第2 共9页 【版权声明】 ?2013-2019 腾讯云版权所有 本文档著作权归腾讯云单独所有,未经腾讯云事先书面许可,任何主体不得以任何形式复制、修改、抄袭、传播全 部或部分本文档内容.

【商标声明】 及其它腾讯云服务相关的商标均为腾讯云计算(北京)有限责任公司及其关联公司所有.本文档涉及的第三方主体 的商标,依法由权利人所有. 【服务声明】 本文档意在向客户介绍腾讯云全部或部分产品、服务的当时的整体概况,部分产品、服务的内容可能有所调整.您 所购买的腾讯云产品、服务的种类、服务标准等应由您与腾讯云之间的商业合同约定,除非双方另有约定,否则, 腾讯云对本文档内容不做任何明示或模式的承诺或保证. 消息队列 CMQ 版权所有:腾讯云计算(北京)有限责任公司 第3 共9页 文档目录 最佳实践 Push 和Pull 的区别 消息去重 消息队列 CMQ 版权所有:腾讯云计算(北京)有限责任公司 第4 共9页 消息队列 CMQ 支持 Pull 和Push 两种方式: Push 模型:当Producer 发出的消息到达后,服务端马上将这条消息投递给 Consumer. Pull 模型:当服务端收到这条消息后什么也不做,只是等着 Consumer 主动到自己这里来读,即Consumer 这 里有一个"拉取"的动作. 本文将结合不同场景,简要分析 Push 模型和 Pull 模型各自存在的利弊. 场景1:Producer 速率大于 Consumer 速率 当Producer 速率大于 Consumer 速率时,有两种可能性:一种是 Producer 本身的效率就要比 Consumer 高(例如,Consumer 端处理消息的业务逻辑可能很复杂,或者涉及到磁盘、网络等 I/O 操作);

另一种是 Consumer 出 现故障,导致短时间内无法消费或消费不畅. Push 方式由于无法得知当前 Consumer 的状态,所以只要有数据产生,便会不断地进行推送,在以上两种情况下 时,可能会导致 Consumer 的负载进一步加重,甚至是崩溃(例如生产者是 flume 疯狂抓日志,消费者是 HDFS+hadoop,处理效率跟不上).除非Consumer 有合适的反馈机制能够让服务端知道自己的状况. 而采取 Pull 的方式问题就简单了许多,由于 Consumer 是主动到服务端拉取数据,此时只需要降低自己访问频率即 可.举例:如前端是 flume 等日志收集业务,不断向 CMQ 生产消息,CMQ 向后端投递,后端业务如数据分析等 最佳实践 Push 和Pull 的区别 最近更新时间:2019-03-28 17:18:47 消息队列 CMQ 版权所有:腾讯云计算(北京)有限责任公司 第5 共9页 业务,效率可能低于生产者. 场景2:强调消息的实时性 采用 Push 的方式时,一旦消息到达,服务端即可马上将其推送给服务端,这种方式的实时性显然是非常好的;

而采 用Pull 方式时,为了不给服务端造成压力(尤其是当数据量不足时,不停的轮询显得毫无意义),需要控制好自己 轮询的间隔时间,但这必然会给实时性带来一定的影响. 场景3:Pull 的长轮询 Pull 模式存在的问题:由于主动权在消费方,消费方无法准确地决定何时去拉取最新的消息.如果一次 Pull 取到消 息了还可以继续去 Pull,如果没有 Pull 取到消息则需要等待一段时间再重新 Pull. 由于等待时间很难判定.您可能有 xx 动态拉取时间调整算法,但问题的本质在于,是否有消息到来不是由消费方决 定.也许1分钟内连续到来1000条消息,接下来的半个小时却没有新消息产生,可能您的算法算出下次最有可能到来 的时间点是31分钟之后,或者60分钟之后,结果下条消息10分钟后到达. 当然,延迟也有对应的解决方案,业界较成熟的做法是从短时间开始(不会对 CMQ broker 有太大负担),然后指 数级增长等待.例如开始等5ms,然后10ms,然后20ms,然后40ms,以此类推,直到有消息到来,然后再回到 5ms.即使这样,依然存在延迟问题:假设40ms到80ms之间的50ms消息到来,消息就延迟了30ms,对于半个小时 来一次的消息,这些开销就是白白浪费的. CMQ 提供了长轮询的优化方法,用以平衡 Pull/Push 模型各自的缺点.基本方式是:消费者如果尝试拉取失败,不 是直接 return,而是把连接挂在那里 wait,服务端如果有新的消息到来,把连接拉起,返回最新消息. 场景4:部分或全部 Consumer 不在线 在消息系统中,Producer 和Consumer 是完全解耦的,Producer 发送消息时,并不要求Consumer 一定要在线, 对于 Consumer 也是同样的道理,这也是消息通信区别于 RPC 通信的主要特点;