共计 4763 个字符，预计需要花费 12 分钟才能阅读完成。
本文由 vivo 互联网服务器团队 Yu Quan 分享，本文收录时有内容订正和从新排版。
1、引言
现在，Android 端的即时通讯 IM 这类利用想实现离线音讯推送，难度越来越大（详见《Android P 正式版行将到来：后盾利用保活、音讯推送的真正噩梦》、《Android 保活从入门到放弃：乖乖疏导用户加白名单吧》）。
于是，应用手机厂商自建的 ROOM 级音讯推送通道进行 IM 离线音讯推送是个不得不面对的问题，咱们也正好借此文机会，一窥支流手机厂商的 ROOM 级推送通道的技术实现吧。
vivo 手机的厂商级音讯推送零碎的现状是最高推送速度 140w/s，单日最大音讯量 200 亿，端到端秒级在线送达率 99.9%。同时推送零碎具备不可提前预知的突发大流量特点。
本文将要分享的是 vivo 技术团队针对音讯推送零碎的高并发、高时效、突发流量等特点，从长连贯层容灾、逻辑层容灾、流量容灾、存储容灾等方面动手，如何保障百亿级厂商音讯推送平台的高可用性的。
- 举荐浏览：vivo 技术团队分享的另一篇音讯推送技术文章《vivo 手机上的零碎级音讯推送平台的架构设计实际》。
技术交换：
- 挪动端 IM 开发入门文章：《新手入门一篇就够：从零开发挪动端 IM》
- 开源 IM 框架源码：https://github.com/JackJiang2011/MobileIMSDK（备用地址点此）
（本文已同步公布于：http://www.52im.net/thread-4416-1-1.html）
2、推送零碎介绍
vivo 推送平台是 vivo 公司向开发者提供的音讯推送服务，通过在云端与客户端之间建设一条稳固、牢靠的长连贯，为开发者提供向客户端利用实时推送音讯的服务，反对百亿级的告诉 / 音讯推送，秒级触达移动用户。
推送零碎次要由 3 局部组成：
1）接入网关；
2）逻辑推送节点；
3）长连贯。
其中，长连贯负责与用户手机终端建设连贯，及时把音讯送达到手机终端。
推送零碎的特点是：
1）并发高；
2）音讯量大；
3）送达及时性较高。
上面将针对这几个方面来分享咱们的技术实际。
3、长连贯层容灾的技术实现
长连贯是推送零碎最重要的局部，长连贯的稳定性间接决定了推送零碎的推送品质和性能。因而，须要对长连贯层做好容灾和实时调度能力。
3.1 面临的问题
原有推送零碎架构是长连贯层都部署在华东，所有 vivo IDC 逻辑节点通过 VPC 与华东的 Broker 建设连贯，手机端跟华东的 broker 进行长连贯通信。
这种部署形式存在以下问题。
1）问题一：华北、华南手机都须要连贯华东的 Broker，地区跨度大，长连贯网络稳定性和时效性绝对较差。
2）问题二：逻辑层跟华东的 Broker 之间由一条 VPC 连贯，随着业务的倒退，推送流量越来越大，带宽会呈现瓶颈，有超限丢包的危险。另外当该 VPC 呈现故障时，会造成全网音讯无奈送达。
注：长连贯层节点名为 Broker。
原始长连贯架构图：
3.2 解决办法
基于以上架构存在问题，咱们对架构进行了优化。行将 Broker 进行三地部署，别离部署在华北、华东、华南。华北、华东、华南三地用户采纳就近接入形式。优化后的架构，不仅能够保障长连贯网络稳定性和时效性。同时具备较强的容灾能力，华东、华南 Broker 通过云网跟华北 Broker 连贯，华北 Broker 通过 VPC 与 vivo IDC 连贯。当华北、华东、华南某个地区 Broker 集群故障或者公网故障，不会影响到全网设施收发音讯。
三地部署后的架构图：
3.3 进一步优化
然而上述这种形式还是存在一个问题，就是某个地区 Broker 集群故障或者公网故障，会呈现该区域局部设施无奈收到推送音讯的状况。针对上述单个地区异样导致该区域局部设施无奈收到推送音讯的问题，咱们设计了一套流量调度零碎，能够做到实时流量调度和切换。global scheduler 节点负责策略调度和治理。
vivo phone 进行注册时：dispatcher 会下发多个地区的 ip 地址，默认状况下，进行就近连贯。单屡次连贯失败后，尝试连贯其余 ip。当某个地区 Broker 呈现长连接数瓶颈或者 VPC 呈现故障，能够通过 global scheduler 节点下发策略，让该故障地区的设施从新从 dispatcher 获取新的 ip 集的 ip，与其余地区 Broker 建设长连贯，逻辑节点下发音讯到重连后的 Broker。等到该地区复原后，能够从新再下发策略，进行回调。
流量调度零碎图：
4、逻辑层容灾的技术实现
长连贯层做好容灾后，逻辑层也须要做相应容灾。之前咱们逻辑层都部署在一个机房，不具备机房间容灾能力，当一个机房呈现断电危险，会呈现服务整体不可用问题，因而咱们做 ” 同城双活 ” 部署计划革新。逻辑层单活架构：
逻辑层别离在 vivo IDC1 和 vivo IDC2 进行部署，网关层依据路由规定将流量依照肯定比例别离下发到两个 IDC，实现逻辑层同城双活。咱们发现：数据中心还是只有一个，部署在 vivo IDC1，依据老本、收益，以及多数据中心数据同步提早问题综合思考，数据中心临时还是以单数据中心为主。
逻辑层双活架构：
5、流量容灾的技术实现
5.1 概述
做好零碎架构的容灾能力后，推送零碎的网关层还须要应答突发流量做相应的应答措施，做好流量管制，保证系统稳定性。历史上，咱们已经因为热点和突发新闻事件，并发推送流量微小，导致服务出现异常，可用性升高问题。为了应答突发大流量，保障突发流量的状况下，零碎可用性不变，同时能兼顾性能和老本。为此，咱们别离比照了设计了以下两种计划。
5.2 惯例计划
惯例的计划是个别是依据历史状况估算冗余部署大量机器，来应答突发流量。单这种形式老本较高，突发流量可能只继续 5 分钟或更短时间，而零碎为了满足 5 分钟突发流量，须要冗余部署大量机器。一旦流量超过了部署机器可承当的下限，无奈及时扩容，可能导致可用性降落，甚至呈现雪崩效应。
传统计划下的推送架构：
那如何设计一套既能够管制老本，面对突发大流量弹性扩容，又保障音讯不漏并兼顾推送性能的计划呢？
5.3 优化计划优化后的计划：
1）在原有架构的根底上，在接入层减少缓冲通道，当流量洪峰到来时，对于零碎可解决的下限能力外的流量，打入缓冲队列；
2）通过音讯队列模式，减少 bypass 接入层，限速生产音讯队列；
3）在流量洪峰过来后，晋升 bypass 生产速度，解决缓存队列音讯；
4）bypass 接入层通过 docker 部署，反对动静扩缩容，默认最小化集群，当音讯队列积压很多，并且上游有能力解决时，晋升生产速度，bypass 依据 CPU 负载动静扩容，疾速生产音讯队列；
5）处理完毕后动静缩容。
音讯队列：选用吞吐量较大的 KAFKA 中间件，并且与离线计算 KAFKA 集群共用，能充分利用资源。bypass 接入层：采纳 docker 部署，反对依据 CPU 负载和工夫动静扩缩容。默认最小集群部署。对于已知的流量顶峰时段，能够提前扩容服务，保障流量疾速解决。未知时段流量顶峰，能够 bypass 接入层，依据 CPU 负载状况进行动静扩缩容。
减少缓存队列后的推送架构：
5.4 进一步优化
进行上述革新后：还存在一个问题，就是如何进行接入层全局控速。
咱们采纳的形式是：收集上游推送节点的推送流量状况。
比方：流量达到零碎可接受下限的 80% 时下发限速指令，调整接入层推送速度。让音讯先积压在音讯队列，等到上游流量升高之后，下发解除限速指令，让 bypass 接入层减速生产音讯队列，进行推送。
减少控速后的推送架构：
优化后计划与传统计划比照：
6、存储容灾的技术实现
6.1 问题
做好并发流量管制后，能很好的预发突发热点问题。但在推送零碎外部，因为应用 Redis 集群缓存音讯，呈现过因为 Redis 集群故障导致音讯无奈及时送达问题。
因而：咱们思考对 Redis 集群做相干容灾方案设计，实现零碎在 Redis 集群故障期间，也能及时推送音讯并保障音讯不失落。推送音讯体缓存在 Redis 集群中，推送时从 Redis 中获取音讯体，如果 Redis 集群宕机，或者内存故障，会导致离线音讯体失落。
6.2 计划
原有音讯流程：
1）计划一：
引入另一个对等 Redis 集群，采纳推送双写形式，双写两个 Redis 集群。该计划须要冗余部署规模对等的备 Redis 集群。推送零碎须要双写 Redis 操作。
2）计划二：
原有 Redis 集群，采纳 RDB+AOF 形式同步到另一个备 Redis 集群。该计划不在须要推送零碎双写 Redis 革新，间接利用将原有 Redis 集群数据同步到另一个备 Redis 集群。也须要冗余部署规模对等的备 Redis 集群。可能存在局部数据同步提早导致推送失败问题。
3）计划三：
利用另一个分布式存储系统，磁盘 KV，兼容 Redis 协定，同时具备长久化能力。能够保障音讯体不失落。然而为了节省成本，不再间接应用 Redis 集群对等资源。而是依据推送特点，推送分为单推、群推。单推是一对一推送，一个用户一条音讯体。群推是一对多推送，一个音讯体对应多个用户。群推往往是工作级别推送。因而咱们应用一个绝对小一些的磁盘 KV 集群，次要用于冗余存储，群推音讯体，即工作级别的音讯。对于单推，还是只保留到 Redis 中，不进行冗余存储。如果 Redis 集群故障，对于单推音讯，推送零碎能够携带音讯体往上游推送，确保音讯能够持续下发。对于群推音讯，因为音讯体冗余存储在磁盘 KV 中，当 Redis 集群故障后，能够降级到读取磁盘 KV。
6.3 优化
计划三还存在一个问题，就是磁盘 KV 的写入性能和 Redis 集群不是一个数量级，特地是时延，磁盘 KV 在均匀在 5ms 左右。而 Redis 集群却在 0.5ms。如果在推送系统对群推音讯体进行双写。这个时延是不能承受的。因而只能采纳异步写入磁盘 KV 的形式。这里将备份群推音讯体，先写入消息中间件 KAFKA，由 bypass 节点生产 KAKFA 进行异步写入磁盘 KV。这样在应用的灾备磁盘 KV 资源较少的前提下，保障推送零碎的高并发能力，同时能够保障群推音讯体不失落，Redis 异样时，单推音讯携带音讯体推送，群推音讯体读取磁盘 KV。
存储容灾计划比照：
7、本文小结
本文从长连贯层容灾、逻辑层容灾、流量容灾、存储容灾等几个方面讲述了推送零碎容灾建设过程。零碎容灾须要依据业务倒退，老本收益，实现难度等多方面思考。以后咱们长连贯层已具备三地部署，逻辑层具备同城双活，数据中心为单数据中心。后续咱们会继续钻研和布局双数据中心，两地三核心部署架构形式来逐渐增强推送零碎容灾能力。
8、参考资料
[1] vivo 手机上的零碎级音讯推送平台的架构设计实际
[2] 魅族 2500 万长连贯的实时音讯推送架构的技术实际分享
[3] 专访魅族架构师：海量长连贯的实时音讯推送零碎的心得体会
[4] 百万在线的美拍直播弹幕零碎的实时推送技术实际之路
[5] 京东京麦商家开放平台的音讯推送架构演进之路
[6] 解密“达达 - 京东到家”的订单即时派发技术原理和实际
[7] 长连贯网关技术专题 (四)：爱奇艺 WebSocket 实时推送网关技术实际
[8] 喜马拉雅亿级用户量的离线音讯推送零碎架构设计实际
[9] 微信直播聊天室单房间 1500 万在线的音讯架构演进之路
[10] 百度直播的海量用户实时音讯零碎架构演进实际
[11] 音讯推送技术干货：美团实时音讯推送服务的技术演进之路
[12] 技术干货：从零开始，教你设计一个百万级的音讯推送零碎
9、vivo 技术团队分享的其它文章
《IM 音讯 ID 技术专题 (七)：深度解密 vivo 的自研分布式 ID 服务 (鲁班)》
《直播零碎聊天技术 (八)：vivo 直播零碎中 IM 音讯模块的架构实际》
《IM 跨平台技术学习 (三)：vivo 的 Electron 技术栈选型、全方位实际总结》
《vivo 手机上的零碎级音讯推送平台的架构设计实际》
（本文已同步公布于：http://www.52im.net/thread-4416-1-1.html）
