共计 4210 个字符，预计需要花费 11 分钟才能阅读完成。
背景介绍
MQ 1.0 公布之初，根本满足了个别业务场景的异步化需要，实现了单机下高性能的工作长久化和生产调度。1.0 的根本框架如下图所示：
能够看到，其次要分为 MQ 和 Worker 两局部。MQ 是工作的长久化和调度框架，Worker 是工作的解决框架。该组件与常见的队列相比，有几个特点：
- 关注单机性能，工作单机长久化，本机生产；
- 框架染指了工作的整个生命周期，其中包含了：入队落盘、派发、解决、提交后果、销毁。业务基于框架开发，专一工作的解决逻辑。
随着业务倒退，面对日益简单的业务场景，1.0 版本逐步显得力不从心。因而，在 1.0 的根底上，咱们实现了 MQ 2.0 版本，次要优化点包含以下几方面：
- 更优的任务调度
- 更高效的工作解决
- 更强的过载爱护
上面对各个优化点具体解说。
更优的任务调度
现状剖析
IOS 音讯告诉性能，是 MQ 组件的一个典型利用场景。微信的后盾具备多 IDC 散布的特点，不同 IDC 与苹果推送服务（APNs）之间的网络品质参差不齐，局部链路故障频发。
因为 MQ 1.0 的工作只能本机生产，网络品质的降落将间接导致 Worker 生产能力的降落，进而产生积压，最终使音讯服务质量受损。
为此，咱们提出了跨机生产模式。其指标是实现一个去中心化、自适应的弹性生产网络，以解决零碎中呈现的部分积压问题。
任务调度是跨机生产的外围问题
生产模式从单机扩大到多机后，咱们要面临的外围问题是，哪些工作给哪个 Worker 去解决。其实，思考多机房、多 IDC、带宽老本、工作延时等因素，咱们很容易失去一个直观而奢侈的思维：
工作优先在本机生产，产生积压时才产生跨机生产。
如何实现咱们想要的跨机生产呢？通过思考，咱们将问题合成为三个子问题：
- 拉工作还是推工作？
- Worker 如何感知 MQ 的积压？
- Worker 如何打消 MQ 的积压？
上面逐个进行探讨。
拉工作还是推工作
MQ 1.0 下，MQ 能够精确察看到本机 Worker 的负载状态，并由其将工作推送给闲暇的 Worker 进行解决。推送的形式能够将工作的解决延时做到极低。
扩大到跨机生产后，Worker 能够生产任意 MQ 的工作。对 MQ 而言，曾经难以准确地保护全网每个 Worker 的状态了。若持续沿用推工作的形式，很可能会呈现 Worker 接管到超过其解决能力的任务量，从而产生积压。
若应用 Worker 拉取工作的形式，则拉取的速度能够依据 Worker 本身的生产能力调整，但在工作延时上，须要有所就义。
- 推工作：长处，低延时；毛病，工作在 Worker 端积压，无奈被从新调度；
- 拉工作：长处，工作在 MQ 端积压，能够被闲暇的 Worker 拉走；毛病，延时稍高；
通过简略的衡量，咱们选用了拉工作的形式，毕竟，咱们难以接受任务积压在 Worker 侧的状况。
Worker 如何感知 MQ 的积压
后面提到，零碎应该在工作呈现积压时，才产生跨机生产。因而，MQ 在产生积压时，应该要能以某种模式告诉 Worker。同时，积压量的变动是很快的，告诉的形式应该做到以下几方面的高效：
速度：尽可能地快；
精度：尽可能少地发送告诉，缩小有效告诉的发送；
为此，咱们实现了播送模式，将 MQ 产生的积压量信息作为一个音讯，播送给 多个 Worker。
它在实现上如何满足高效的积压告诉要求呢？
- 速度：应用长连贯将积压量信息推送到 Worker 端；
- 精度：通过灵便的订阅过滤器，实现对本机、跨机、跨 IDC 的分级的播送；
通过播送模式，咱们高效地解决了 MQ 积压的感知问题。
Worker 如何打消 MQ 的积压
通过播送模式，每个 Worker 都能够察看到所有它感兴趣的 MQ 的积压状况，并以此构建出整个零碎的积压散布统计。拿到这些信息后，Worker 如何决定拉取哪个 MQ 的工作呢？
还是回到咱们的原始诉求，尽量做到本机生产。所以咱们的策略是说，Worker 应该优先打消本机的积压，当它有余力的时候，才去帮忙其它 Worker。
通过分优先级地拉取，既可在队列零碎失常时大量升高跨机生产，同时也能够在故障产生时，无效地打消部分积压。
负载平衡剖析
跨机生产模式，从整个零碎角度来看，是齐全去中心化的，任意一个 MQ 和 Worker 个体都能够独立、自在地退出或退出零碎。
在这个竞争式的生产零碎里，依据具体的部署状况、不同机型生产能力不同等因素，无奈达到齐全的负载平衡状态。但在零碎产生部分过载时，则能够自适应调节，达到绝对的平衡。
小结
从理论利用成果来看，MQ 2.0 实现了告诉推送服务的 IDC 级别容灾，即便只剩下一个 IDC 可用，也能够做到推送品质岿然不动。
MQ 2.0 对跨机生产模式的反对，为业务提供了一种新的队列容灾模式：
- MQ 与 Worker 可齐全拆散部署，别离布局机器数量，按需部署，互不影响；
- MQ 的部分积压能够通过扩容 Worker 进行打消；
- Worker 的部分生产能力降落能够由其它 Worker 主动容灾；
更高效的工作解决
现状剖析
微信公布已有 6 年多的工夫，后盾的业务逻辑演变至今，往往是十分的简单，咱们来看一个比拟极其的例子 —— 群聊批量并行化投递。
上图是群音讯投递业务的简化流程示意。随着微信群音讯体量的高速收缩，其带来的老本压力越来越大，业务同学提出了批量并行化的优化形式。简略来说，就是将每个步骤中产生的 RPC 拜访按理论拜访机器聚合成一系列的批量操作，而后并行化执行。
通常来说，单次的批量并行化并不难写，一般而言，业务同学可能会抉择裸写。但如果波及屡次的批量并行化，其中还存在嵌套的话，事件就不那么简略了。最终代码将变得异样简单，业务开发的同学苦不堪言。MQ 是否从框架上解决这类问题？
类 MapReduce 工作解决框架
其实，深入分析群音讯投递的优化需要，能够看到：
- 一次批量并行化操作实质上是一次 MapReduce 过程；
- 整个群音讯投递的处理过程是屡次 MapReduce 过程的串联和并联；
所以，为了从根本上解决这一类问题，MQ 为业务提供了类 MapReduce 工作解决框架。
该框架提供封装了通用的 MR 过程，以及并发的调度过程，同时提供并发池隔离能力，解决了并发池饿死的问题。让业务同学能够从冗繁的代码中解放出来，将更多的精力投入到理论业务中。
流式工作解决框架
除了批量并行化的需要，业务常常提到的一个需要是，工作解决时会产生一些新的工作须要加到队列中。一般来说是走一次 RPC 来执行工作入队。在 MQ 2.0 下，流式工作能够帮忙实现这个事件。
所谓流式工作，就是在工作解决完结时，除了返回工作后果，还能够返回一系列新的工作。这些工作通过 MQ 外部框架流转入队，更轻量，事务性更强。
相比惯例的同步解决模型，它提供了一种轻量的逻辑异步化模型。一个简短的逻辑能够切分为很多小的功能块进行串联和复用，每一级之间都有 MQ 去充当缓冲和调度。
尽管这种解决模式并不适用于所有逻辑，但作为组件性能的一部分，它提供了一种新的解决问题的能力。
小结
MQ 2.0 提供的类 MapReduce 工作解决框架和流式工作解决框架，为业务的实现提供了便当的反对。
更强的过载爱护
现状剖析
MQ 的重要作用是充当零碎中的缓冲节点，流量管制的能力是十分要害的。在 MQ 1.0 下，只能通过配置队列的工作出队速度来实现流量管制。其问题有几个：
配置须要人工调整，难以估算对后端的理论拜访；
后端处于过载状态时无奈自适应调整；
本人处于过载状态时无奈自适应调整；
问题剖析
从需要来看，MQ 的过载爱护需要有两个方面，一是爱护本人不过载，二是爱护后端不过载。
导致过载的因素很多，从 MQ 的角度来看，这些因素能够分为两大类。一种是它能间接察看的因素，如本身的 CPU 使用率，内存使用率，工作执行的成功率；另一种是无奈间接察看的因素，如业务理论对后端产生的调用量。
从这两类因素登程，咱们将过载爱护的策略分为两大策略：
- 前向限速：MQ 通过其间接察看到的数据，被动对工作派发进行限速；
- 后向限速：MQ 通过业务反馈的数据，被动对工作派发进行限速；
上面别离探讨两种策略。
前向限速
基于 CPU 使用率的流控
该限速策略很好了解，就是在 CPU 使用率过高时，升高工作处理速度，以将 CPU 资源优先用于保障队列的缓存能力。
基于工作成功率的流控
后端模块故障时，往往会导致队列工作呈现大量的失败和重试，这些重试的量级往往会远超该后端模块设计的无效输入，给故障复原带来很大的艰难。
该流控策略的通过收集工作执行的成功率信息，评估后端的无效输入，并通过反馈计算限度工作重试的速度。
后向限速
MQ 实现了通用的后向限速能力，业务通过特定接口往 MQ 回传管制量，达到速度调控的目标。
基于后端 RPC 访问量的流控
咱们常常会遇到一些业务在解决工作时，存在不同水平的对后端的扩散拜访。仅对工作处理速度进行限度，无奈精确限度对后端产生的理论调用量。
该策略通过收集业务对后端产生的理论调用量，反向调节工作解决的速度。
小结
MQ 2.0 通过剖析流控需要，在前向和后向别离提供了无效的流控伎俩，并且为后续更精密的流控策略预留了拓展的能力，加强了过载爱护的能力。
写在最初
微信的队列组件，与业界其余队列相比，其突出的特点是更贴近理论业务场景，极大地解放了业务同学的生产力。
MQ 2.0 在 1.0 的根底上，在任务调度、工作解决、过载爱护这几方面做了大量的工作和尝试，目前已在微信各个外围业务模块运行，并经验了 2017 年元旦流量洪峰的考验。
后续，将在工作长久化容灾和调度性能上，对该组件进行继续的优化。对于 MQ 有任何疑难及想法，欢送与作者探讨。
作者介绍：廖文鑫，2013 年退出腾讯，从事微信后盾根底性能及架构的开发和经营，先后参加了音讯告诉推送零碎、工作队列组件、春晚摇红包流动等我的项目，在海量分布式高性能零碎方面有丰盛的教训。
本文转自微信后盾团队, 如有进犯, 请分割咱们立刻删除
OpenIMgithub 开源地址：
https://github.com/OpenIMSDK/…
OpenIM 官网： https://www.rentsoft.cn
OpenIM 官方论坛： https://forum.rentsoft.cn/
更多技术文章：
开源 OpenIM：高性能、可伸缩、易扩大的即时通讯架构
https://forum.rentsoft.cn/thr…
【OpenIM 原创】简略轻松入门 一文解说 WebRTC 实现 1 对 1 音视频通信原理
https://forum.rentsoft.cn/thr…
【OpenIM 原创】开源 OpenIM：轻量、高效、实时、牢靠、低成本的音讯模型
https://forum.rentsoft.cn/thr…