消息队列在使用中的注意事项
异步不是万能的，实现异步重要的手段，消息队列在使用中也是有很多注意事项的。
消息队列的瓶颈
消息队列至少有三处容易出现瓶颈，我们一经典的发布/订阅模式为例。分析一下都可能存在哪些瓶颈。
发布 ---> 队列 ---> 订阅
- 入队瓶颈，发布消息队列，处理太慢，发布端堵塞应用程序。
- 队列持久化瓶颈，队列持久化是需要写入磁盘的，大量的密集IO操作
- 出队瓶颈，（茶壶煮饺子，有嘴倒不出）出队瓶颈还包括订阅端的处理能力，
- 如果订阅端的处理能力跟不上，也会出现瓶颈。
- 消息大小，每个消息包的大小也决定了性能
发布端常见问题
发布端问题表现在入队速度影响了发布端应用程序的性能，例如
runtime {
task1();
task2();
publish();
task3();
task4();
}
loop {
task1();
task2();
publish();
task3();
task4();
}
AI 代码解读
上面伪代码 publish()将阻塞 task3()与task4(),必须等待publish()执行完成才能继续运行。
这样的情况是 发布数量 > 入队的速度， 影响发布端的性能
队列持久化
消息的持久化，既影响入队速度，也影响出对速度，入队是写磁盘操作，出对是修改或者删除操作。 在队列同时进行入队与出队的操作是，还涉及到各种“锁”，例如线程锁与文件锁等等。 最终结果是消息队列性能骤降。
订阅端性能
订阅端的处理能力也影响到队列的堆积程度。如果订阅端处理速度过慢，我们就会发现消息在队列中堆积。
loop {
function sub_callback(){
task1();
task2();
task3();
task4();
}
}
AI 代码解读
订阅端改进，将队列交给线程处理
threads[max_connet] {
function sub_callback(){
task1();
task2();
task3();
task4();
}
}
AI 代码解读
消息的大小
我们应该尽量减小消息的体积，例如选择轻量的协议，超过一定体积做压缩处理。
就消息协议而言, 二进制协议 < 文本协议。而文本协议中 json < xml 等等。
xml 成对出现的闭合标签占用了大量的空间，二进制的 msgpack 也好于文本的 json。 选择使用那种协议还要看你的场景。
另外还需要注意的就是 序列化/反序列化的开销。
总结
我们要尽量做到发布，队列与订阅之间的平衡，才能发挥消息队列的优势。
作者
陈景峰，昵称 Netkiller, 英文名 Neo 《Netkiller 系列 手札》电子书的作者，个人网站：http://netkiller.github.io/
转载请注明出处与作者声明
