消息队列MQ
之前一直也没有学习过这方面的知识,直到项目中用到才决定学习一下
https://www.jianshu.com/p/36a7775b04ec
https://www.cnblogs.com/rjzheng/
1. 为什么要使用消息队列?
MQ(Message Queue)顾名思义就是消息队列。打个比方去快餐店点餐,每个人点餐可能只要10s,但如果三个人同时向服务员点餐,服务员就可能会乱了,三个顾客还可能会吵起来,这件事就没法30s内解决,那么很简单,排队点餐就好办了。所以MQ最核心的功能就是削峰蓄洪。其他特征则是围绕这一功能衍生出来的。
- 比如如何维持排队的人不乱套(持久化和重发和事务支持)
- 如何容纳更多的人排队(堆积能力)
- 如果实在接待不了这么多人怎样让后来的人去其他地方安置(限流机制)等等。
最主要的应用场景即以下六个字:解耦、异步、削峰。
①:解耦
传统模式:
传统模式的缺点:
系统间耦合性太强,如上图所示,系统A在代码中直接调用系统B和系统C的代码,如果将来D系统接入,系统A还需要修改代码,过于麻烦!
中间件模式:
中间件模式的的优点:
将消息写入消息队列,需要消息的系统自己从消息队列中订阅,从而系统A不需要做任何修改。
②:异步
传统模式:
传统模式的缺点:
一些非必要的业务逻辑以同步的方式运行,太耗费时间。
中间件模式:
中间件模式的的优点:
将消息写入消息队列,非必要的业务逻辑以异步的方式运行,加快响应速度
③:削峰
传统模式:
传统模式的缺点:
并发量大的时候,所有的请求直接怼到数据库,造成数据库连接异常
中间件模式:
中间件模式的的优点:
系统A慢慢的按照数据库能处理的并发量,从消息队列中慢慢拉取消息。在生产中,这个短暂的高峰期积压是允许的。
消息队列缺点?
- 系统可用性降低:你想啊,本来其他系统只要运行好好的,那你的系统就是正常的。现在你非要加个消息队列进去,那消息队列挂了,你的系统也就完蛋了。因此,系统可用性降低
- 系统复杂性增加:要多考虑很多方面的问题,比如一致性问题、如何保证消息不被重复消费,如何保证保证消息可靠传输。因此,需要考虑的东西更多,系统复杂性增大。
特性 | 开发语言 | 单机吞吐量 | 时效性 | 可用性 | 功能特性 |
---|---|---|---|---|---|
ActiveMQ | java | 万级 | ms级 | 高(主从架构) | 成熟的产品,在很多公司得到应用;有较多的文档;各种协议支持较好 |
RabbitMQ | erlang | 万级 | us级 | 高(主从架构) | 基于erlang开发,所以并发能力很强,性能极其好,延时很低;管理界面较丰富 |
RocketMQ | java | 十万级 | ms级 | 非常高(分布式架构) | MQ功能比较完备,扩展性佳 |
kafka | scala | 十万级 | ms级以内 | 非常高(分布式架构) | 只支持主要的MQ功能,像一些消息查询,消息回溯等功能没有提供,毕竟是为大数据准备的,在大数据领域应用广。 |
综合上面的材料得出以下两点:
- 中小型软件公司,建议选RabbitMQ。
- erlang语言天生具备高并发的特性,管理界面用起来十分方便。
- 但是缺少能定制化开发erlang的程序员。
不考虑rocketmq和kafka的原因:
- 中小型软件公司不如互联网公司,数据量没那么大,选消息中间件,应首选功能比较完备的,所以kafka排除不考虑。
- rocketmq是阿里出品,如果阿里放弃维护rocketmq,中小型公司抽不出人来进行rocketmq的定制化开发,因此不推荐。
- 大型软件公司,根据具体使用在rocketMq和kafka之间二选一。
- rocketMQ,大型软件公司可以抽出人手对rocketMQ进行定制化开发。
- kafka,根据业务场景选择,如果有日志采集功能,肯定首选kafka。