背景介绍
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…