异步不是万能的,实现异步重要的手段,消息队列在使用中也是有很多注意事项的。
消息队列至少有三处容易出现瓶颈,我们一经典的发布/订阅模式为例。分析一下都可能存在哪些瓶颈。
发布 ---> 队列 ---> 订阅
发布端问题表现在入队速度影响了发布端应用程序的性能,例如
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();
}
}
我们要尽量做到发布,队列与订阅之间的平衡,才能发挥消息队列的优势。