作者:vivo 互联网服务器团队 - Yu Quan

本文介绍了推送系统容灾建设和关键技术方案,以及实践过程中的思考与挑战。

一、推送系统介绍

vivo推送平台是vivo公司向开发者提供的消息推送服务,通过在云端与客户端之间建立一条稳定、可靠的长连接,为开发者提供向客户端应用实时推送消息的服务,支持百亿级的通知/消息推送,秒级触达移动用户。

推送系统主要由接入网关,逻辑推送节点,长连接组成,长连接负责与用户手机终端建立连接,及时把消息送达到手机终端。

推送系统的特点并发高、消息量大、送达及时性较高

vivo推送系统现状最高推送速度140w/s,单日最大消息量200亿,端到端秒级在线送达率99.9%。同时推送系统具备不可提前预知的突发大流量特点。针对推送系统高并发,高时效,突发流量等特点,如何保证系统可用性呢?本文将从系统架构,存储容灾,流量容灾三个方面进行讲述,推送系统是如何做容灾的。

二、系统架构容灾方案

2.1 长连接层容灾

长连接是推送系统最重要的部分,长连接的稳定性直接决定了推送系统的推送质量和性能,因此,需要对长连接层做好容灾和实时调度能力。

原有推送系统架构是长连接层都部署在华东,所有vivo IDC逻辑节点通过VPC与华东的Broker建立连接,手机端跟华东的broker进行长连接通信。这种部署方式存在以下问题

  • 问题一:华北、华南手机都需要连接华东的Broker,地域跨度大,长连接网络稳定性和时效性相对较差。

  • 问题二:逻辑层跟华东的Broker之间由一条VPC连接,随着业务的发展,推送流量越来越大,带宽会出现瓶颈,有超限丢包的风险。另外当该VPC出现故障时,会造成全网消息无法送达。

注:长连接层节点名为Broker。

原始长连接架构图:

基于以上架构存在问题,进行了优化,将Broker进行三地部署,分别部署在华北,华东,华南。

华北、华东、华南三地用户采用就近接入方式。

优化后的架构,不仅可以保证长连接网络稳定性和时效性。同时具有较强的容灾能力,华东,华南Broker通过云网跟华北Broker连接,华北Broker通过VPC与vivo IDC连接。当华北、华东、华南某个地区Broker集群故障或者公网故障,不会影响到全网设备收发消息。但是这种方式还是存在一个问题,就是某个地区Broker集群故障或者公网故障,会出现该区域部分设备无法收到推送消息的情况。

三地部署后的架构图:

针对上述单个地区异常导致该区域部分设备无法收到推送消息的问题,我们设计了一套流量调度系统,可以做到实时流量调度和切换。global scheduler节点负责策略调度和管理。

vivo phone进行注册时,dispatcher会下发多个地区的ip地址,默认情况下,进行就近连接。单多次连接失败后,尝试连接其他ip。当某个地区Broker出现长连接数瓶颈或者VPC出现故障,可以通过global scheduler节点下发策略,让该故障地区的设备重新从dispatcher获取新的ip集的ip,与其他地区Broker建立长连接,逻辑节点下发消息到重连后的Broker。等到该地区恢复后,可以重新再下发策略,进行回调。

流量调度系统图:

2.2 逻辑层容灾

长连接层做好容灾后,逻辑层也需要做相应容灾。之前我们逻辑层都部署在一个机房,不具备机房机容灾能力,当一个机房出现断电风险,会出现服务整体不可用问题,因此我们做"同城双活"部署方案改造。

逻辑层单活架构:

逻辑层分别在vivo IDC1和vivo IDC2进行部署,网关层根据路由规则将流量按照一定比例分别下发到两个IDC,实现逻辑层同城双活。我们发现,数据中心还是只有一个,部署在vivo IDC1,根据成本、收益,以及多数据中心数据同步延迟问题综合考虑,数据中心暂时还是以单数据中心为主。

逻辑层双活架构:

三、 流量容灾方案

做好系统架构的容灾能力后,推送系统的网关层还需要应对突发流量做相应的应对措施,做好流量控制,保证系统稳定性。历史上,我们曾经因为热点和突发新闻事件,并发推送流量巨大,导致服务出现异常,可用性降低问题。

如何应对突发大流量,保证突发流量的情况下,系统可用性不变,同时能兼顾性能和成本。为此,我们分别对比了设计了以下两种方案。

常规的方案是一般是根据历史情况估算冗余部署大量机器,来应对突发流量。单这种方式成本较高,突发流量可能只持续5分钟或更短时间,而系统为了满足5分钟突发流量,需要冗余部署大量机器。一旦流量超过了部署机器可承担的上限,无法及时扩容,可能导致可用性下降,甚至出现雪崩效应。

传统方案下的推送架构:

那如何设计一套既可以控制成本,面对突发大流量弹性扩容,又保证消息不漏并兼顾推送性能的方案呢?

优化方案:在原有架构的基础上,在接入层增加缓冲通道,当流量洪峰到来时,对于系统可处理的上限能力外的流量,打入缓冲队列。通过消息队列形式,增加bypass接入层,限速消费消息队列。在流量洪峰过去后,提升bypass消费速度,处理缓存队列消息。bypass接入层通过docker部署,支持动态扩缩容,默认最小化集群,当消息队列积压很多,并且下游有能力处理时,提升消费速度,bypass根据CPU负载动态扩容,快速消费消息队列。处理完毕后动态缩容。

消息队列:选用吞吐量较大的KAFKA中间件,并且与离线计算KAFKA集群共用,能充分利用资源。

bypass接入层:采用docker部署,支持根据CPU负载和时间动态扩缩容。默认最小集群部署。对于已知的流量高峰时段,可以提前扩容服务,保证流量快速处理。未知时段流量高峰,可以bypass接入层,根据CPU负载情况进行动态扩缩容。

增加缓存队列后的推送架构:

进行上述改造后,还存在一个问题,就是如何进行接入层全局控速。我们采用的方式是收集下游推送节点的推送流量情况,比如:流量达到系统可承受上限的80%时下发限速指令,调整接入层推送速度。让消息先积压在消息队列,等到下游流量降低之后,下发解除限速指令,让bypass接入层加速消费消息队列,进行推送。

增加控速后的推送架构:

优化后方案与传统方案对比:

四、存储容灾方案

做好并发流量控制后,能很好的预发突发热点问题。推送系统内部,由于使用Redis集群缓存消息,出现过因为Redis集群故障导致消息无法及时送达问题。因此,我们考虑对Redis集群做相关容灾方案设计,实现系统在Redis集群故障期间,也能及时推送消息并保证消息不丢失。

推送消息体缓存在Redis集群中,推送时从Redis中获取消息体,如果Redis集群宕机,或者内存故障,会导致离线消息体丢失。

原有消息流程:

方案一:引入另一个对等Redis集群,采用推送双写方式,双写两个Redis集群。该方案需要冗余部署规模对等的备Redis集群。推送系统需要双写Redis操作。

方案二:原有Redis集群,采用RDB+AOF方式同步到另一个备Redis集群。该方案不再需要推送系统双写Redis改造,直接利用将原有Redis集群数据同步到另一个备Redis集群。也需要冗余部署规模对等的备Redis集群。可能存在部分数据同步延迟导致推送失败问题。

方案三:应用另一个分布式存储系统,磁盘KV,兼容Redis协议,同时具有持久化能力。可以保证消息体不丢失。但是为了节省成本,不再直接使用Redis集群对等资源。而是根据推送特点,推送分为单推、群推。单推是一对一推送,一个用户一条消息体。群推是一对多推送,一个消息体对应多个用户。群推往往是任务级别推送。因此我们使用一个相对小一些的磁盘KV集群,主要用于冗余存储,群推消息体,即任务级别的消息。对于单推,还是只保存到Redis中,不进行冗余存储。

如果Redis集群故障,对于单推消息,推送系统可以携带消息体往下游推送,确保消息可以继续下发。对于群推消息,因为消息体冗余存储在磁盘KV中,当Redis集群故障后,可以降级到读取磁盘KV。

方案三还存在一个问题,就是磁盘KV的写入性能和Redis集群不是一个数量级,特别是时延,磁盘KV在平均在5ms左右。而Redis集群却在0.5ms。如果在推送系统对群推消息体进行双写。这个时延是不能接受的。因此只能采用异步写入磁盘KV的方式。这里将备份群推消息体,先写入消息中间件KAFKA,由bypass节点消费KAKFA进行异步写入磁盘KV。这样在使用的灾备磁盘KV资源较少的前提下,保证推送系统的高并发能力,同时可以保证群推消息体不丢失,Redis异常时,单推消息携带消息体推送,群推消息体读取磁盘KV。

存储容灾方案对比:

五、总结

本文从系统架构容灾、流量容灾、存储容灾三个方面讲述了推送系统容灾建设过程。系统容灾需要根据业务发展,成本收益,实现难度等多方面考虑。

当前我们长连接层已具备三地部署,逻辑层具备同城双活,数据中心为单数据中心。后续我们会持续研究和规划双数据中心,两地三中心部署架构方式来逐步加强推送系统容灾能力。

vivo 推送系统的容灾建设与实践的更多相关文章

  1. 在Openfire上弄一个简单的推送系统

    推送系统 说是推送系统有点大,其实就是一个消息广播功能吧.作用其实也就是由服务端接收到消息然后推送到订阅的客户端. 思路 对于推送最关键的是服务端向客户端发送数据,客户端向服务端订阅自己想要的消息.这 ...

  2. MPush开源消息推送系统:简洁、安全、支持集群

    引言由于之前自己团队需要一个消息推送系统来替换JPUSH,一直找了很久基本没有真正可用的开源系统所有就直接造了个轮子,造轮子的时候就奔着开源做打算的,只是后来创业项目失败一直没时间整理这一套代码,最近 ...

  3. 开源实时消息推送系统 MPush

    系统介绍 mpush,是一款开源的实时消息推送系统,采用java语言开发,服务端采用模块化设计,具有协议简洁,传输安全,接口流畅,实时高效,扩展性强,可配置化,部署方便,监控完善等特点.同时也是少有的 ...

  4. laravel整合workerman做消息推送系统

    官方建议分离 workerman和mvc框架的结合,我去,这不是有点脑缺氧吗? 大量的业务逻辑,去独立增加方法和类库在写一次,实际业务中是不现实和不实际的 gateway增加一些这方面的工作,但是我看 ...

  5. 微博Rss邮箱推送系统

    微博Rss邮箱推送

  6. androidpn 推送系统

    (文中部分内容来自网络,如无意中侵犯了版权,请告之!) XMPP协议: XMPP : The Extensible Messaging andPresence Protocol. 中文全称:可扩展通讯 ...

  7. php实现简单消息发送+极光推送系统

    前几天刚写完的一个东西,写的比较简单,没有使用其他插件,原生php+计划任务实现 极光推送的代码 /* $receiver="registration_id" : [ " ...

  8. .net core 3.0 Signalr - 实现一个业务推送系统

    ## 介绍 ASP.NET Core SignalR 是一个开源代码库,它简化了向应用添加实时 Web 功能的过程. 实时 Web 功能使服务器端代码能够即时将内容推送到客户端. SignalR 的适 ...

  9. Android P正式版即将到来:后台应用保活、消息推送的真正噩梦

    1.前言 对于广大Android开发者来说,Android O(即Android 8.0)还没玩热,Andriod P(即Andriod 9.0)又要来了.   下图上谷歌官方公布的Android P ...

  10. QQ 相册后台存储架构重构与跨 IDC 容灾实践

    欢迎大家前往云加社区,获取更多腾讯海量技术实践干货哦~ 作者简介:xianmau,2015 年加入腾讯 TEG 架构平台部,一直负责 QQ 相册平台的维护和建设,主导相册上传架构重构和容灾优化等工作. ...

随机推荐

  1. 读取nrf52832的ADC,并且获取N个数组中的中间值

    //****读取中间值****// short GetMedianNum(short * bArray, short iFilterLen) { short i,j,bTemp;// 排序循环 for ...

  2. BlenderGIS记录

    blender GIS 的插件名:"3Dview:blenderGIS" 具体使用方法看文档. 选择地图时选择bing地图会快一点.如果能挂梯子可以选择google地图 shift ...

  3. git操作回顾,从零入手

    1.可在极狐或者git上直接通过http克隆项目,或者通过ssh密钥,这样就不用每次上传代码需要输入密码和验证 ssh密钥参考如下 (80条消息) git如何生成ssh密钥 git生成配置ssh密钥k ...

  4. 记一下Linux环境SpringBoot 用OpenOffice Word转PDF

    环境 Windows或者Linux 首先安装 deb方式 tar -xvzf Apache_OpenOffice_XXXX_Linux_x86-64_install-deb_zh-CN.tar.gz ...

  5. app工程目录结构

    一.APP工程目录结构 APP工程分为两个层次,第一个层次是项目(这里在eclipse中是指workspace),另一个层次是模块(这里在eclipse中是指project) 模块依附于项目,每个项目 ...

  6. 在VS中C#工程操作Mysql数据库

    1.实现mysql数据库与VS的连接,需要安装两个插件,作者装的是mysql-connector-net-6.9.9.msi和 mysql-for-visualstudio-1.2.6.msi. 2. ...

  7. 《MySQL是怎样运行的》第二章小结

  8. Echarts的安装和使用

    安装步骤 下载相关文件 可以在该网站下载Echarts.js文件,网址在此:https://www.echartsjs.com/zh/builder.html 然后选择号自己需要用到的图形模块,点击下 ...

  9. 获取了文心一言的内测及与其ChatGPT、GPT-4 对比结果

    百度在3月16日召开了关于文心一言(知识增强大语言模型)的发布会,但是会上并没现场展示demo.如果要测试的文心一言 也要获取邀请码,才能进行测试的. 我这边通过预约得到了邀请码,大概是在3月17日晚 ...

  10. 什么是mvvm?简单介绍它的概念、原理及实现

    1.MVVM的概念 model-view-viewModel,通过数据劫持+发布订阅模式来实现. mvvm是一种设计思想.Model代表数据模型,可以在model中定义数据修改和操作的业务逻辑;vie ...