从头学消息队列

写在前面 在项目中总是用到的一个中间件就是消息队列，从以前的redis到后来用到的rabbitmq，再到即将要研究的kafka，一直只知道用，却没有进行好好总结。正如有句话说的，你知道的越多，你不知道也就越多。以下文章是对过去的总结，以及对未来的展望。

消息是指在应用间传送的数据，消息队列是一种应用间的通讯方式，消息发送后可以立即返回，有消息系统来确保信息的可靠传递，消息发布者只管把消息发布到MQ中而不管谁来取，消息使用者只管从MQ中取消息而不管谁发布的，这样发布者和使用者都不用知道对方的存在。

优点

1)解耦

这个很好理解，原本消息是由生产者直接传递给消费者，也就是说消息需要同步的发送给消费者，这时候问题来了，假设消费者挂了怎么办，是不是需要重发？实际上有些调用不需要同步调用接口，此时就可用MQ去作解耦。

2)异步

A系统需要调B、C、D系统，A系统写自己库需要20ms，但还需要去BCD调用，此时延时达到了用户不可接受的水平。使用MQ后，BCD只需要去自己对应消息队列取参数在本地自己执行对应操作。

3)削峰

缺点

1)系统可用性降低

系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。

2)系统复杂性提高

硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。

3)一致性问题

A系统处理完成，BCD系统有一个存在问题，数据就不一致了。

1) 点对点模式

点对点模式通常基于拉取或者轮询消息传送模型，发送到消息队列的消息有且只有一个消费者进行处理。生产者放入消息队列，由消费者主动拉取并决定拉取消息频率，缺点是消息队列是否有消息需要消费无法被消费者感知。

2) 发布订阅模式

发布订阅模式是基于消息的消息传送模型，该模型可有多个订阅者。生产者将消息放入消息队列，消息队列将消息推送给订阅过该消息的消费者。也就是说消费者属于被动接收消息，无需感知消息队列是否有待消费的消息。此处推送的速度变成问题，假设消费者速度不一致，则势必在推送速度上面存在过快或者过慢的问题，在消费者处就存在无法承受或者资源浪费的问题。