消息队列常见问题
1、为什么使用消息队列?
2、消息队列有哪些优缺点?
3、RabbitMQ、ActiveMQ、RocketMQ、Kafka各自优缺点,异同点,适用哪些场景?
4、如何保证消息队列的高可用
5、什么是MQ的消息重复消费,如何保证重复消息的幂等性
6、如何保证消息传输的可靠性,保证消息传输过程中消息不丢失
7、如何保证消息的顺序性
8、如何解决消息队列的延时以及过期失效问题?消息队列满了以后该怎么处理?有几百万消息持续积压几小时,说说怎么解决?
9、如何设计一个MQ消息中间件
消息队列的使用场景
1、解耦
没有使用MQ强耦合场景
![](https://img-blog.csdnimg.cn/img_convert/a548f4e4c7d983956466dc3168bb2660.png)
使用MQ解耦合
![](https://img-blog.csdnimg.cn/img_convert/531258c1a148253e657a9b92f97ae907.png)
2、异步
不使用MQ的高延时同步操作
![](https://img-blog.csdnimg.cn/img_convert/6d06ca30dcc38126ecf8ecf0c84565c0.png)
使用MQ,异步操作,性能优化
![](https://img-blog.csdnimg.cn/img_convert/b26b1abcf2460055a080a6bf07099698.png)
3、削峰
不使用MQ,高峰期系统被打死的场景
![](https://img-blog.csdnimg.cn/img_convert/28653b63aab0ec2a8b1d44c16d3a7c34.png)
使用MQ削峰
![](https://img-blog.csdnimg.cn/img_convert/6a84a4214a645123941a37b6b156a1ed.png)
消息队列有哪些优缺点
![](https://img-blog.csdnimg.cn/img_convert/91faefab37c12cfae48b4cf7e0518580.png)
常用MQ的对比
特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
单机吞吐量 | 万级,吞吐量比RocketMQ和Kafka要低了一个数量级 | 万级,吞吐量比RocketMQ和Kafka要低了一个数量级 | 10万级,RocketMQ也是可以支撑高吞吐的一种MQ | 10万级别,这是kafka最大的优点,就是吞吐量高。
一般配合大数据类的系统来进行实时数据计算、日志采集等场景 |
topic数量对吞吐量的影响 |
|
| topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降
这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topic | topic从几十个到几百个的时候,吞吐量会大幅度下降
所以在同等机器下,kafka尽量保证topic数量不要过多。如果要支撑大规模topic,需要增加更多的机器资源 |
时效性 | ms级 | 微秒级,这是rabbitmq的一大特点,延迟是最低的 | ms级 | 延迟在ms级以内 |
可用性 | 高,基于主从架构实现高可用性 | 高,基于主从架构实现高可用性 | 非常高,分布式架构 | 非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用 |
消息可靠性 | 有较低的概率丢失数据 |
| 经过参数优化配置,可以做到0丢失 | 经过参数优化配置,消息可以做到0丢失 |
功能支持 | MQ领域的功能极其完备 | 基于erlang开发,所以并发能力很强,性能极其好,延时很低 | MQ功能较为完善,还是分布式的,扩展性好 | 功能较为简单,主要支持简单的MQ功能,在大数据领域的实时计算以及日志采集被大规模使用,是事实上的标准 |
优劣势总结 | 非常成熟,功能强大,在业内大量的公司以及项目中都有应用
偶尔会有较低概率丢失消息
而且现在社区以及国内应用都越来越少,官方社区现在对ActiveMQ 5.x维护越来越少,几个月才发布一个版本
而且确实主要是基于解耦和异步来用的,较少在大规模吞吐的场景中使用
| erlang语言开发,性能极其好,延时很低;
吞吐量到万级,MQ功能比较完备
而且开源提供的管理界面非常棒,用起来很好用
社区相对比较活跃,几乎每个月都发布几个版本分
在国内一些互联网公司近几年用rabbitmq也比较多一些
但是问题也是显而易见的,RabbitMQ确实吞吐量会低一些,这是因为他做的实现机制比较重。
而且erlang开发,国内有几个公司有实力做erlang源码级别的研究和定制?如果说你没这个实力的话,确实偶尔会有一些问题,你很难去看懂源码,你公司对这个东西的掌控很弱,基本职能依赖于开源社区的快速维护和修复bug。
而且rabbitmq集群动态扩展会很麻烦,不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码,很难定制和掌控。 | 接口简单易用,而且毕竟在阿里大规模应用过,有阿里品牌保障
日处理消息上百亿之多,可以做到大规模吞吐,性能也非常好,分布式扩展也很方便,社区维护还可以,可靠性和可用性都是ok的,还可以支撑大规模的topic数量,支持复杂MQ业务场景
而且一个很大的优势在于,阿里出品都是java系的,我们可以自己阅读源码,定制自己公司的MQ,可以掌控
社区活跃度相对较为一般,不过也还可以,文档相对来说简单一些,然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码
还有就是阿里出台的技术,你得做好这个技术万一被抛弃,社区黄掉的风险,那如果你们公司有技术实力我觉得用RocketMQ挺好的 | kafka的特点其实很明显,就是仅仅提供较少的核心功能,但是提供超高的吞吐量,ms级的延迟,极高的可用性以及可靠性,而且分布式可以任意扩展
同时kafka最好是支撑较少的topic数量即可,保证其超高吞吐量
而且kafka唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略
这个特性天然适合大数据实时计算以及日志收集 |
如何保证消息队列的高可用
1、RabbitMQ普通集群模式,没有高可用可言
![](https://img-blog.csdnimg.cn/img_convert/92fff985cd217822da9f6670e95bcda0.png)
2、RabbitMQ镜像集群模式
![](https://img-blog.csdnimg.cn/img_convert/4ccc512450b281cea07a3a61caf43801.png)
3、Kafka的高可用(纯分布式的)
![](https://img-blog.csdnimg.cn/img_convert/f244d2fe1f70a1a95f0e41e0730fc5fc.png)
MQ的重复消费
1、Kafka消息的重复消费
![](https://img-blog.csdnimg.cn/img_convert/286c3f5213346ccda394f2dcd6f6e095.png)
2、如何保证MQ重复消费的幂等性
![](https://img-blog.csdnimg.cn/img_convert/1d97cb5e26bda0d44710948396a425ca.png)
如何保证消息传输的可靠性(消息丢失)
1、RabbitMQ保证消息的不丢失
![](https://img-blog.csdnimg.cn/img_convert/6fe6f999625b0ec7d7d0851abef0e631.png)
2、Kafka保证消息的不丢失
![](https://img-blog.csdnimg.cn/img_convert/c59d813c8098a2e3f9448d05ce17cb4a.png)
如何保证消息的顺序性
1、RabbitMQ消息乱序执行的场景
![](https://img-blog.csdnimg.cn/img_convert/22086e079d3d0dfcc8aef19cb6cae018.png)
2、RabbitMQ如何保证消息的顺序性
![](https://img-blog.csdnimg.cn/img_convert/7b992d6bb750fffcb1d3ac2aa0464d9f.png)
3、Kafka消息乱序执行的场景
![](https://img-blog.csdnimg.cn/img_convert/2f0ad670389851160132bdd6b6f40926.png)
4、Kafka如何保证消息的顺序性
![](https://img-blog.csdnimg.cn/img_convert/93d2e59d708e0574688cbded843ea3d3.png)
如何解决消息的延时,过期,快速处理积压的大量消息
![](https://img-blog.csdnimg.cn/img_convert/cd20aca15103508c1a68acc40d3401b9.png)