浅谈RabbitMQ

知识先知

其实引入这个解决方案,纯属是因为在项目中有这样的应用场景;
何为解决方案,其实通俗讲就是针对于某些应用场景,选取适合的解决办法,这里指的是较好的,或许解决方案会有许多,包括MQ消息队列要解决的应用场景。

前因后果

场景一、目前常见的分布式服务项目，都是通过服务于服务之间进行通信完成各自的业务逻辑，因此相互之间耦合性比较较大；
（1）只要中间服务出了故障后，上游和下游都会受到波及，同时相互之间的调用关系为被动；
（2）后期进行扩增和删减的话，都会波及依赖的服务；

解决方式：引用MQ后，上游服务只负责将下游想要的东西发送给它，至于下游如何处理，这就不是上游需要考虑的问题了；相互之间的调用关系为主动。

场景二、一些大数据量的频繁同步处理，一个系统如果不光在本项目读写数据，而且还要调用其他项目操作库，这时候，他们之间的处理如果是同步的话，损耗的时间就是两者之和了。

解决方式：引入MQ后，上游系统连续发送消息到MQ队列中,直接返回；当然也可以利用多线程的方式解决，但是会造成单体服务内存损耗。

场景三、比如某个业务处理过程一直都处于稳定状态，但是某一时间点后，用户请求量突增，针对于这种场景，提升服务器的硬件显然不是最好的方式。

解决方式：引入MQ后，利用消息队列持久化存储的机制，可以避过短时间业务量突增的场景，稍后等到请求平稳后，慢慢处理业务量。

合理分析

难道说，MQ消息队列就是最优的解决方案？其实不然，我们还要根据现在业务情况，综合的进行考虑。

弊端一、系统的可用性降低，原本两个项目之间相互调用明确，同时也只需要维护这两个项目即可，但是引入MQ后，两个项目同时还需要和MQ服务对接，同时还要考虑单点服务故障的问题。

弊端二、系统复杂度提高

消息丢失
1：生产者丢失数据，其一开启事务，但是吞吐量会降低；其二利用Ack机制，Broker通知生产者是否接收到消息。
2：消息队列丢失数据，开启持久化磁盘机制，配合confirm机制使用。
3：消费者丢失数据，其一开启自动确认模式，但是会一直重新发送，其实很多失败的原因都是因为处理不了，所以说再重新发送同样处理不了；其二开启手动确认模式，此队列发送失败后移交给另外一个队列处理，手动定时任务执行。
消息传递顺序性
1：消息发送过程中是顺序的，但是由于集群项目负载均衡的机制，会导致项目发送到不同的项目（多个服务器部署相同项目）中消费，此时消息消费顺序过程无法保证；这种问题，可以利用全局Id进行解决。

弊端三、分布式消息一致性问题

业务和队列如何保持一致性
解决方案：参考“弊端二”中消息传递顺序性

知识补充

RabbitMQ（消息中间件）组成： 生产者、消息代理、消费者
RabbitMQ相关概念： 生产者、消费者、消息、队列、主题
RabbitMQ的消费语义： 消息至多被消费一次、消息至少被消费一次、消息只被消费一次
RabbitMQ遵从协议（AMQP）： 生产者将消息发送给交换器，交换器和队列绑定。当生产者发送消息时所携带的RoutingKey与绑定时的BindingKey相匹配时，消息即被存入相应的队列中；消费者可以订阅相应的队列来获取消息。

具体相关概念性问题，大家可以自行查阅资料，这里不再进行叙述，强烈推荐一本书《RabbitMQ实战指南》