特来电是一个互联网公司，而且是技术领先的互联网公司。互联网公司的标配是什么？答案就是缓存+MQ。没错，您没看错，就是MQ--消息队列，我们今天要讨论的RabbitMQ就是消息队列中功能非常强大的一种。那么RabbitMQ在特来电是如何应用的呢？这就是今天这篇博文的目的，让您连接RabbitMQ在特来电的深度应用!

1.一张图看懂MQ的地位

RabbitMQ具有和关系型数据库、内存数据库同等的地位，作为最底层的组件，为上层调用提供服务。在特来电，几乎所有应用系统都是分布式部署，而RabbitMQ是分布式系统的基础组件。

2.RabbitMQ集群在特来电的部署方式

为了最大限度的保证可用性，避免单个节点的故障而影响整个系统的运行，RabbitMQ使用集群方式搭建，并配合HAProxy来提供负载均衡功能。

目前在生产环境，我们通过三台RabbitMQ服务器、两台HAProxy服务器来保证每天接近900W的消息分发与处理。

3.分布式任务计算平台(MAC)在特来电的广泛使用

消息队列对于应用解耦、流量削峰等具有极大的优势。分布式任务计算平台--MAC是处理RabbitMQ消息的主要途径之一，何为分布式任务计算平台？

处理MQ消息是一件非常复杂的事情，虽然说MQ官方会推出对应的调用SDK，但对于具体使用方式、异常处理、性能调优、异常补偿等，都会增加使用者的学习成本，并且对于SDK的统一升级等都会非常复杂。鉴于此，特来电公共技术部经过仔细调研，开发了分布式任务计算平台简化了处理MQ消息复杂性，并通过支持分布式部署、水平扩展、自动重试、流量安全控制、通过任务插件注入的方式来简化使用MQ的复杂性，并通过一系列的辅助来保证最终数据处理的一致性。

分布式任务计算平台是作为MQ的消费者Consumer而存在。

截止到目前为止，分布式任务计算平台共有274类不同任务，承载着900W的消息处理。

4.分布式任务计算平台(MAC)主动对流量的控制

还记得我们说过，MQ的两个主要功能：应用解耦和流量削峰。生产环境274类不同任务支撑了不同应用之间的解耦，但没有主动控制流量削峰。

为什么以前我们不主动对流量进行主动控制，而现在要主动控制呢？

究其原因，我们认为对于每个消息的处理应该是尽可能的快，但随着业务之间的交互越来越复杂，消息的处理总是达不到消息到来的速度。尽管分布式任务计算平台会尽可能增大消息处理并发数。但在消息峰值来临时，会对后端的业务处理带来更大的压力，严重时，可能会拖垮系统的运行，影响公司整体业务的处理。基于此，我们在MAC端增加主动控制流量，在业务系统可接受的影响范围内，进行消息的处理。

MAC将是否主动控制流量的配置进行了极大的简化，只需在对应的任务元数据配置流量控制阈值及时间单元即可启用，MAC会主动控制消息的消费速率在阈值范围内。

5.MAC如何解决RabbitMQ消息全部被接收到Client端，造成Client端内存占用高的问题

实际使用RabbitMQ过程中，如果完全不配置QoS，这样RabbitMQ会尽可能快速地发送队列中的所有消息到MAC。MAC会在本地缓存所有的消息，从而极有可能导致OOM或者导致服务器内存不足而影响其它进程的正常运行。所以我们需要通过设置Qos的prefetch count来控制MAC缓存的消息数量，同时设置得当也会提高MAC的吞吐量。

prefetch count并不是说设置得越大越好。过大可能导致consumer处理不过来，一直在本地缓存的BlockingQueue里呆太久，这样消息在客户端的延迟就大大增加；而对于多个consumer的情况，则会分配不均匀，导致有些consumer一直在忙，有些则非常空闲。然而设置的过小，又会令到consumer不能充分工作，因为我们总想它100％的时间都是处于繁忙状态，而这时可能会在处理完一条消息后，BlockingQueue为空，因为新的消息还未来得及到达，所以consumer就处于空闲状态了。

MAC会根据一定的方式，依照流量控制阈值来设置RabbitMQ的prefetch Count，将MAC缓存消息的数量控制在一定范围内，减少MAC缓存消息占用的内存。

prefetch Count相关的内容请参考：http://zclau.com/2016/09/15/RabbitMQ%E7%9A%84Qos-prefetch/

总结：

RabbitMQ 作为消息队列产品的佼佼者，提供了丰富的功能来满足业务需求，而特来电人也在基于RabbitMQ做最大限度的深度应用，集群部署、分布式任务计算平台、主动流量控制等都是我们对RabbitMQ深度应用。

在RabbitMQ的使用路上，参考我们具体的业务需求及RabbitMQ提供的特性，我们还会创造出更多有价值的功能。

在RabbitMQ的使用之路上，有你我不孤单。