C/C++编程：消息队列入门

川长思鸟来 2022-03-25 07:16 208阅读 0赞

为了解决后台将数据库的变化实时更新到前台的问题，我来了解一下消息队列

### 文章目录 ###

*  1、为什么要使用消息队列
 *  2、使用了消息队列会有什么缺点?
 *  3、消息队列如何选型?
 *  4、如何保证消息队列是高可用的？

# 1、为什么要使用消息队列 #

三个最主要的应用场景：解耦、异步、削峰  
(1)解耦  
传统模式:  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]  
传统模式的缺点：

*  系统间耦合性太强，如上图所示，系统A在代码中直接调用系统B和系统C的代码，如果将来D系统接入，系统A还需要修改代码，过于麻烦！  
    中间件模式:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]  
    中间件模式的的优点：
 *  将消息写入消息队列，需要消息的系统自己从消息队列中订阅，从而系统A不需要做任何修改  
    (2)异步  
    传统模式:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]  
    传统模式的缺点：
 *  一些非必要的业务逻辑以同步的方式运行，太耗费时间。  
    中间件模式:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]  
    中间件模式的的优点：
 *  将消息写入消息队列，非必要的业务逻辑以异步的方式运行，加快相应速度。

(3)削峰  
传统模式  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]  
传统模式的缺点：

*  并发量大的时候，所有的请求直接怼到数据库，造成数据库连接异常  
    中间件模式:  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]  
    中间件模式的的优点：
 *  系统A慢慢的按照数据库能处理的并发量，从消息队列中慢慢拉取消息。在生产中，这个短暂的高峰期积压是允许的。

# 2、使用了消息队列会有什么缺点? #

分析:一个使用了MQ的项目，如果连这个问题都没有考虑过，就把MQ引进去了，那就给自己的项目带来了风险。我们引入一个技术，要对这个技术的弊端有充分的认识，才能做好预防。要记住，不要给公司挖坑！  
回答:回答也很容易，从以下两个个角度来答

*  系统可用性降低:你想啊，本来其他系统只要运行好好的，那你的系统就是正常的。现在你非要加个消息队列进去，那消息队列挂了，你的系统不是呵呵了。因此，系统可用性降低
 *  系统复杂性增加:要多考虑很多方面的问题，比如一致性问题、如何保证消息不被重复消费，如何保证保证消息可靠传输。因此，需要考虑的东西更多，系统复杂性增大。

# 3、消息队列如何选型? #

先说一下，博主只会ActiveMQ,RabbitMQ,RocketMQ,Kafka，对什么ZeroMQ等其他MQ没啥理解，因此只能基于这四种MQ给出回答。  
分析:既然在项目中用了MQ，肯定事先要对业界流行的MQ进行调研，如果连每种MQ的优缺点都没了解清楚，就拍脑袋依据喜好，用了某种MQ，还是给项目挖坑。如果面试官问:"你为什么用这种MQ？。"你直接回答"领导决定的。"这种回答就很LOW了。还是那句话，不要给公司挖坑。  
回答:首先，咱先上ActiveMQ的社区，看看该MQ的更新频率:

Apache ActiveMQ 5.15.3 Release
    Christopher L. Shannon posted on Feb 12, 2018
    Apache ActiveMQ 5.15.2 Released
    Christopher L. Shannon posted on Oct 23, 2017
    Apache ActiveMQ 5.15.0 Released
    Christopher L. Shannon posted on Jul 06, 2017

我们可以看出，ActiveMq几个月才发一次版本，据说研究重心在他们的下一代产品Apollo。  
接下来，我们再去RabbitMQ的社区去看一下,RabbitMQ的更新频率

RabbitMQ 3.7.3 release  30 January 2018
    RabbitMQ 3.6.15 release  17 January 2018
    RabbitMQ 3.7.2 release23 December 2017
    RabbitMQ 3.7.1 release21 December 2017

我们可以看出，RabbitMQ版本发布比ActiveMq频繁很多。至于RocketMQ和kafka就不带大家看了，总之也比ActiveMQ活跃的多。详情，可自行查阅。  
再来一个性能对比表  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]  
综合上面的材料得出以下两点:  
(1)中小型软件公司，建议选RabbitMQ.一方面，erlang语言天生具备高并发的特性，而且他的管理界面用起来十分方便。正所谓，成也萧何，败也萧何！他的弊端也在这里，虽然RabbitMQ是开源的，然而国内有几个能定制化开发erlang的程序员呢？所幸，RabbitMQ的社区十分活跃，可以解决开发过程中遇到的bug，这点对于中小型公司来说十分重要。不考虑rocketmq和kafka的原因是，一方面中小型软件公司不如互联网公司，数据量没那么大，选消息中间件，应首选功能比较完备的，所以kafka排除。不考虑rocketmq的原因是，rocketmq是阿里出品，如果阿里放弃维护rocketmq，中小型公司一般抽不出人来进行rocketmq的定制化开发，因此不推荐。  
(2)大型软件公司，根据具体使用在rocketMq和kafka之间二选一。一方面，大型软件公司，具备足够的资金搭建分布式环境，也具备足够大的数据量。针对rocketMQ,大型软件公司也可以抽出人手对rocketMQ进行定制化开发，毕竟国内有能力改JAVA源码的人，还是相当多的。至于kafka，根据业务场景选择，如果有日志采集功能，肯定是首选kafka了。具体该选哪个，看使用场景。

# 4、如何保证消息队列是高可用的？ #

分析:在第二点说过了，引入消息队列后，系统的可用性下降。在生产中，没人使用单击模式的消息队列。因此，作为一个合格的程序员，应该对消息队列的高可用有很深刻的了解。如果面试的时候，面试官问，你们的消息中间件如何保证高可用？你的回答只是表明自己只会订阅消息和发布消息，面试官就会怀疑你是不是只是自己搭着玩，请做一个爱思考，会思考，懂思考的程序员。  
回答:这问题，其实要对消息队列的集群模式要有深刻了解，才好回答。

【未完，接下来的还用不到】

作者：孤独烟 出处： http://rjzheng.cnblogs.com/  
还有一篇消息队列写的很好的文章：http://www.cnblogs.com/linjiqin/p/5720865.html

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70]: /images/20220325/c2c70d3c6ad04dc1beee4324041e6d0c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 1]: /images/20220325/0b72fe20baab49ac9a71a3859e1ae3c1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 2]: /images/20220325/f45fc21d87b54fd29049651553d02254.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 3]: /images/20220325/7fbad2173a414b2da84f7d4a076021ba.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 4]: /images/20220325/646bae3eff604a20b430e8cacb8df0da.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 5]: /images/20220325/656f75e7727f4edcbe3c4c28058f9a42.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3poaXpoZW5nZ3Vhbg_size_16_color_FFFFFF_t_70 6]: /images/20220325/113c40ab7cd648dcb42ce457fa427ef6.png