本文由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）