消息队列在使用中的注意事项-阿里云开发者社区

开发者社区> 开发与运维> 正文

消息队列在使用中的注意事项

简介:

消息队列在使用中的注意事项

异步不是万能的,实现异步重要的手段,消息队列在使用中也是有很多注意事项的。

消息队列的瓶颈

消息队列至少有三处容易出现瓶颈,我们一经典的发布/订阅模式为例。分析一下都可能存在哪些瓶颈。

发布 ---> 队列 ---> 订阅

  1. 入队瓶颈,发布消息队列,处理太慢,发布端堵塞应用程序。
  2. 队列持久化瓶颈,队列持久化是需要写入磁盘的,大量的密集IO操作
  3. 出队瓶颈,(茶壶煮饺子,有嘴倒不出)出队瓶颈还包括订阅端的处理能力,
  4. 如果订阅端的处理能力跟不上,也会出现瓶颈。
  5. 消息大小,每个消息包的大小也决定了性能

发布端常见问题

发布端问题表现在入队速度影响了发布端应用程序的性能,例如

runtime {
    task1();
    task2();
    publish();
    task3();
    task4();
}



loop {
    task1();
    task2();
    publish();
    task3();
    task4();
}

上面伪代码 publish()将阻塞 task3()与task4(),必须等待publish()执行完成才能继续运行。

这样的情况是 发布数量 > 入队的速度, 影响发布端的性能

队列持久化

消息的持久化,既影响入队速度,也影响出对速度,入队是写磁盘操作,出对是修改或者删除操作。 在队列同时进行入队与出队的操作是,还涉及到各种“锁”,例如线程锁与文件锁等等。 最终结果是消息队列性能骤降。

订阅端性能

订阅端的处理能力也影响到队列的堆积程度。如果订阅端处理速度过慢,我们就会发现消息在队列中堆积。

loop {
    function sub_callback(){
        task1();
        task2();
        task3();
        task4();
    }
}

订阅端改进,将队列交给线程处理

threads[max_connet] {
    function sub_callback(){
        task1();
        task2();
        task3();
        task4();
    }
}

消息的大小

我们应该尽量减小消息的体积,例如选择轻量的协议,超过一定体积做压缩处理。

就消息协议而言, 二进制协议 < 文本协议。而文本协议中 json < xml 等等。

xml 成对出现的闭合标签占用了大量的空间,二进制的 msgpack 也好于文本的 json。 选择使用那种协议还要看你的场景。

另外还需要注意的就是 序列化/反序列化的开销。

总结

我们要尽量做到发布,队列与订阅之间的平衡,才能发挥消息队列的优势。

作者

陈景峰,昵称 Netkiller, 英文名 Neo 《Netkiller 系列 手札》电子书的作者,个人网站:http://netkiller.github.io/

转载请注明出处与作者声明

版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。

分享:
开发与运维
使用钉钉扫一扫加入圈子
+ 订阅

集结各类场景实战经验,助你开发运维畅行无忧

其他文章