MQ消息队列基础1

消息队列的作用:

异步,削峰,降低系统耦合性。

1.通过异步处理提高系统性能:(削峰,减少响应时间,比如如果没有消息队列,那么可能100条数据同时打入数据库,而有了消息队列,则数据会一条一条写入数据库,遵守消息队列的先进先出规则)。

2.降低系统耦合性:不同进程之间传递消息时,两个进程之间耦合度过高,改动一个进程,则必须修改另一个进程,为了隔离这两个进程,在两进程间抽离出一层(一个模块),两进程之间的通信,必须通过消息队列来传递,单独修改某一个进程,不会影响另一个;(比如你去送信,如果接受人的地址改变了,那么你送信的路线也会改变,但是如果中间多个邮局,那么即使收信人的地址改变了,也和你没关系,你只要把信放在邮局就ok了,你的路线永远是从你家到邮局这条固定的。)

常见的MQ:ActiveMq,RabbitMQ,RocketMQ,Kafka

 

名称

ActiveMQ

RabbitMQRocketMQKafka
单击吞吐量万级,吞吐量比RockerMQ和Kafka要低了一个数量级万级,吞吐量比RocketMQ和kafka要低了一个数量级十万级,RocketMQ也是可以支撑高吞吐的一种MQ十万级别,这是kafka最大的有点,就是吞吐量高。一般配合大数据类的系统来进行实时数据计算,日志采集等场景
topic数量对吞吐量的影响  topic可以达到几百,几千个的级别,吞吐量会有较小幅度的下降。这是RocketMQ的一大优势,在同等机器下,可以支撑大量的topictopic从几十个到几百个的时候,吞吐量会大幅度下降。因此在同等机器下,kafka尽量保证topic数量不要过多,如果要支撑大规模topic,需要增加更多的机器资源
时效性ms级微秒级,这是rabbitmq的一大特点,延迟是最低的ms级延迟在ms级以内
高可用性高,基于主从架构实现高可用高,基于主从架构实现高科应非常高,分布式架构非常高,kafka是分布式的,一个数据多个副本,少数机器宕机,不会丢失数据,不会导致不可用
消息可靠性有较低的概率丢失数据开启持久化使数据写入磁盘,数据丢失概率基本可以忽略(除非数据还没吸入磁盘呢rabbitmq就挂了)经过参数优化配置,可以做到零丢失经过参数优化配置,消息可以做到零丢失
功能支持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唯一的一点劣势是有可能消息重复消费,那么对数据准确性会造成极其轻微的影响,在大数据领域中以及日志采集中,这点轻微影响可以忽略

 

这个特性天然适合大数据实时计算以及日志收集

综上所述,各种对比之后,我个人倾向于是:

一般的业务系统要引入MQ,最早大家都用ActiveMQ,但是现在确实大家用的不多了,没经过大规模吞吐量场景的验证,社区也不是很活跃,所以大家还是算了吧,我个人不推荐用这个了;

后来大家开始用RabbitMQ,但是确实erlang语言阻止了大量的java工程师去深入研究和掌控他,对公司而言,几乎处于不可控的状态,但是确实人是开源的,比较稳定的支持,活跃度也高;

不过现在确实越来越多的公司,会去用RocketMQ,确实很不错,但是我提醒一下自己想好社区万一突然黄掉的风险,对自己公司技术实力有绝对自信的,我推荐用RocketMQ,否则回去老老实实用RabbitMQ吧,活跃开源社区,绝对不会黄

所以中小型公司,技术实力较为一般,技术挑战不是特别高,用RabbitMQ是不错的选择;大型公司,基础架构研发实力较强,用RocketMQ是很好的选择

如果是大数据领域的实时计算、日志采集等场景,用Kafka是业内标准的,绝对没问题,社区活跃度很高,绝对不会黄,何况几乎是全世界这个领域的事实性规范。

一下是网上比较好的消息队列基础文章:

https://www.jianshu.com/p/36a7775b04ec

https://blog.csdn.net/hellozpc/article/details/81436980#RabbitMQ_14

https://www.jianshu.com/p/5c01d5198217

https://blog.csdn.net/cws1214/article/details/52922267

https://www.cnblogs.com/laojiao/p/9573016.html

 

 

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值