RabbitMQ在特来电的深度应用

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

1.一张图看懂MQ的地位:

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

RabbitMQ在特来电的深度应用

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

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

目前在生产环境,我们通过三台RabbitMQ服务器、两台HAProxy服务器来保证每天接近900W的消息量,并且提供HSF的状态变化推送等功能。

RabbitMQ在特来电的深度应用

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

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

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

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

RabbitMQ在特来电的深度应用

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

RabbitMQ在特来电的深度应用

 

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相关的内容请参考:%E7%9A%84Qos-prefetch/

 

总结:

内容版权声明:除非注明,否则皆为本站原创文章。

转载注明出处:https://www.heiqu.com/zwzxpy.html