消息队列的理解，几种常见消息队列对比，新手也能看得懂！----分布式中间件消息队列

• 消息队列的应用场景

废话很少说，全是容易理解的干货。博主最开始接触消息队列的时候是公司的转型，由传统业务转型分布式。能够想象一下，分布式项目中两个微服务之间相互调用怎么调用？而后你们七嘴八舌

“我知道！我知道！用注册中心！”

“我知道！我知道！用网关用网关”

“啊啊啊！我也知道Nginx！！”

哈哈哈 你们别笑，这些都是我以前的想法哈哈哈
真正进入项目的时候会遇到一个问题，你须要调用的微服务人还没开始写你咋调？你请求发过去一个个请求挨个消费，就在那排队干等着？分布式系统的高并发量一下给你系统冲击的瘫痪掉？这些问题一出来就暴露了分布式项目一个很大的弊端，也是为何要用消息队列的缘由。

• 为何使用消息队列

消息队列至关因而一个中间商，这部分概念有点像中介。消费者发出的请求全到这里，而后由消息队列去帮你完成。

 

第一：举一个生活中的场景，你须要寄一个快递，联系快递员，联系以后这段时间你须要在家里等快递员不能出门。？？？？？？？？？？（黑人问号，寄个快递好像被禁锢了）。

目前这个困境算是解决掉了，经过快递柜，你须要寄的快递放在快递柜里就OK了，这样你的时间就会被解放出来，也就是程序员口中的异步和解耦。这样你就好快递员之间没有必然的耦合关系了。他啥时候来，今天来不来对你的影响就不是很大了。这个快递柜就至关于咱们的消息队列，你存快递就是发请求，快递员取你的快递并发走就是请求的消费。异步和解耦就被消息队列实现了。

第二：当有高并发需求时，消息队列能够把众多的请求缓一下，而后以一个不是很剧烈的节奏去让他们消费。这样就消去了请求峰值。

 

 

 

• 消息队列的种类以及对比

目前比较常见的消息队列有ActiveMQ、RabbitMQ、RocketMQ、kafka（Redis也能够作这个功能，再次感慨Redis的强大）

简单介绍一下他们的区别
ActiveMQ：早期的消息队列，社区比较成熟，可是性能已经有点落后了，更新也慢，因此不建议用

RabbitMQ：在处理大量数据方面不及RocketMQ 、kafka，可是因为它基于 erlang 开发，因此并发能力很强，性能极其好，延时很低，达到微秒级，所以若是并发量不是很大的话，只有十来万，百万之内，你不用Rabbit你在想啥？

RocketMQ：这是阿里的开源项目，能够根据本身的需求DIY定制，前提是你有这个实力（扎心了！）。有一个问题是RocketMQ没有老老实实按照统一的消息队列的规范来，修改起来得删删改改不少地方，虽然性能也很好，可是阿里哪天不想要它了，那你估计也难受了。若是若是若是公司实力很牛*，能够忽略掉这点，使用RocketMQ很香的。

kafka：他的特色很明显，他的功能不多，可是巨牛*的吞吐量，毫秒级别的延迟。可是它惟一的缺点就是可能出现重复消费状况，几率虽然很小，可是对超大数量的信息处理，这点毛毛雨基本上能够忽略掉。就像你打印上千万行日志消息，你会在乎中间漏了一条日志么?

• 消息队列带来的问题

系统可用性下降： 系统可用性在某种程度上下降，为何这样说呢？在加入MQ以前，你不用考虑消息丢失或者说MQ挂掉等等的状况，可是，引入MQ以后你就须要去考虑了！

系统复杂性提升： 加入MQ以后，你须要保证消息没有被重复消费、处理消息丢失的状况、保证消息传递的顺序性等等问题！

一致性问题： 我上面讲了消息队列能够实现异步，消息队列带来的异步确实能够提升系统响应速度。可是，万一消息的真正消费者并无正确消费消息怎么办？这样就会致使数据不一致的状况了!

一致性问题的解决办法上面提到的,当你吧消息发送到消息队列,可是消息队列和另外微服务那边出故障了没执行完成该怎么办?这里举个例子吧，你在12306上订票，怎么处理的？对啦！就是先给你返回，后面若是失败了会给你回复一些信息，发个短信啥的，总之也算是一个解决办法。嘿嘿全都是手敲的，有点错字的话你们别介意，看看就行！