消息队列的应用场景
废话不多说，全是容易理解的干货。博主最开始接触消息队列的时候是公司的转型，由传统业务转型分布式。可以想象一下，分布式项目中两个微服务之间相互调用怎么调用？然后大家七嘴八舌
“我知道！我知道！用注册中心！”
“我知道！我知道！用网关用网关”
“啊啊啊！我也知道Nginx！！”
哈哈哈 大家别笑，这些都是我之前的想法哈哈哈
真正进入项目的时候会遇到一个问题，你需要调用的微服务人还没开始写你咋调？你请求发过去一个个请求挨个消费，就在那排队干等着？分布式系统的高并发量一下给你系统冲击的瘫痪掉？这些问题一出来就暴露了分布式项目一个很大的弊端，也是为什么要用消息队列的原因。
为什么使用消息队列
消息队列相当于是一个中间商，这部分概念有点像中介。消费者发出的请求全到这里，然后由消息队列去帮你完成。
第一：举一个生活中的场景，你需要寄一个快递，联系快递员，联系之后这段时间你需要在家里等快递员不能出门。？？？？？？？？？？（黑人问号，寄个快递好像被禁锢了）。
目前这个困境算是解决掉了，通过快递柜，你需要寄的快递放在快递柜里就OK了，这样你的时间就会被解放出来，也就是程序员口中的异步和解耦。这样你就好快递员之间没有必然的耦合关系了。他啥时候来，今天来不来对你的影响就不是很大了。这个快递柜就相当于我们的消息队列，你存快递就是发请求，快递员取你的快递并发走就是请求的消费。异步和解耦就被消息队列实现了。
第二：当有高并发需求时，消息队列可以把众多的请求缓一下，然后以一个不是很剧烈的节奏去让他们消费。这样就消去了请求峰值。
消息队列的种类以及对比
目前比较常见的消息队列有ActiveMQ、RabbitMQ、RocketMQ、kafka（Redis也可以做这个功能，再次感慨Redis的强大）
简单介绍一下他们的区别
ActiveMQ：早期的消息队列，社区比较成熟，但是性能已经有点落后了，更新也慢，所以不建议用
RabbitMQ：在处理大量数据方面不及RocketMQ 、kafka，但是由于它基于 erlang 开发，所以并发能力很强，性能极其好，延时很低，达到微秒级，因此如果并发量不是很大的话，只有十来万，百万以内，你不用Rabbit你在想啥？
RocketMQ：这是阿里的开源项目，可以根据自己的需求DIY定制，前提是你有这个实力（扎心了！）。有一个问题是RocketMQ没有老老实实按照统一的消息队列的规范来，修改起来得删删改改很多地方，虽然性能也很好，但是阿里哪天不想要它了，那你估计也难受了。如果如果如果公司实力很牛*，可以忽略掉这点，使用RocketMQ很香的。
kafka：他的特点很明显，他的功能很少，但是巨牛*的吞吐量，毫秒级别的延迟。但是它唯一的缺点就是可能出现重复消费情况，概率虽然很小，但是对超大数量的信息处理，这点毛毛雨基本上可以忽略掉。就像你打印上千万行日志消息，你会在意中间漏了一条日志么?
消息队列带来的问题
系统可用性降低： 系统可用性在某种程度上降低，为什么这样说呢？在加入MQ之前，你不用考虑消息丢失或者说MQ挂掉等等的情况，但是，引入MQ之后你就需要去考虑了！
系统复杂性提高： 加入MQ之后，你需要保证消息没有被重复消费、处理消息丢失的情况、保证消息传递的顺序性等等问题！
一致性问题： 我上面讲了消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办？这样就会导致数据不一致的情况了!
一致性问题的解决办法
上面提到的,当你吧消息发送到消息队列,但是消息队列和另外微服务那边出故障了没执行完成该怎么办?
这里举个例子吧，你在12306上订票，怎么处理的？
对啦！就是先给你返回，后面如果失败了会给你回复一些信息，发个短信啥的，总之也算是一个解决办法。嘿嘿
全都是手敲的，有点错字的话大家别介意，看看就行！