RabbitMQ在特来电的深度应用
特来电是一个互联网公司，而且是技术非常先进的互联网公司。互联网公司的标配是什么？答案就是缓存+MQ。没错，您没看错，就是MQ–消息队列，我们今天要说的RabbitMQ就是消息队列的其中一种，而且是功能非常强大的一种。那么RabbitMQ在特来电是如何应用的呢。这就是今天这篇博文的目的，让您知道RabbitMQ在特来电的深入应用!
1.一张图看懂MQ的地位：
RabbitMQ是和关系型数据库、内存数据库同等的地位，作为最底层的组件，为上层调用提供服务。在特来电，所有系统都是分布式部署，而RabbitMQ是所有分布式系统的基础组件。
2.RabbitMQ集群在特来电的部署方式：
为了最大限度的保证可用性，避免单个节点的故障而影响整个系统的运行，RabbitMQ使用集群方式搭建，并配合HAProxy来提供负载均衡功能。
目前在生产环境，我们通过三台RabbitMQ服务器、两台HAProxy服务器来保证每天接近900W的消息量，并且提供HSF的状态变化推送等功能。
3.分布式任务计算平台(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，这样Rabbit会尽可能快速地发送队列中的所有消息到client端。因为consumer在本地缓存所有的message，从而极有可能导致OOM或者导致服务器内存不足影响其它进程的正常运行。所以我们需要通过设置Qos的prefetch count来控制consumer的流量。同时设置得当也会提高consumer的吞吐量。
prefetch并不是说设置得越大越好。过大可能导致consumer处理不过来，一直在本地缓存的BlockingQueue里呆太久，这样消息在客户端的延迟就大大增加；而对于多个consumer的情况，则会分配不均匀，导致有些consumer一直在忙，有些则非常空闲。然而设置的过小，又会令到consumer不能充分工作，因为我们总想它100％的时间都是处于繁忙状态，而这时可能会在处理完一条消息后，BlockingQueue为空，因为新的消息还未来得及到达，所以consumer就处于空闲状态了。
MAC会根据一定的方式，依照流量控制阈值来设置RabbitMQ的prefetch，将MAC接收消息的数量控制在一定范围内，减少MAC缓存消息占用的内存。
prefetch相关的内容请参考：http://zclau.com/2016/09/15/RabbitMQ%E7%9A%84Qos-prefetch/
总结：
RabbitMQ 作为消息队列产品的佼佼者，提供了丰富的功能来满足业务需求，而特来电人也在基于RabbitMQ做最大限度的深度应用，集群部署、分布式任务计算平台、主动流量控制等都是我们对RabbitMQ深入使用。
在RabbitMQ的使用路上，参考我们具体的业务需求及RabbitMQ提供的特性，我们还会创造出更多有价值的功能。在RabbitMQ的使用之路上，有你我不孤单。