作者：vivo 互联网服务器团队 - Yu Quan
本文介绍了推送系统容灾建设和关键技术方案，以及实践过程中的思考与挑战。
vivo推送平台是vivo公司向开发者提供的消息推送服务，通过在云端与客户端之间建立一条稳定、可靠的长连接，为开发者提供向客户端应用实时推送消息的服务，支持百亿级的通知/消息推送，秒级触达移动用户。
推送系统主要由接入网关，逻辑推送节点，长连接组成，长连接负责与用户手机终端建立连接，及时把消息送达到手机终端。
推送系统的特点是并发高、消息量大、送达及时性较高。
vivo推送系统现状最高推送速度140w/s，单日最大消息量200亿，端到端秒级在线送达率99.9%。同时推送系统具备不可提前预知的突发大流量特点。针对推送系统高并发，高时效，突发流量等特点，如何保证系统可用性呢？本文将从系统架构，存储容灾，流量容灾三个方面进行讲述，推送系统是如何做容灾的。
长连接是推送系统最重要的部分，长连接的稳定性直接决定了推送系统的推送质量和性能，因此，需要对长连接层做好容灾和实时调度能力。
原有推送系统架构是长连接层都部署在华东，所有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。等到该地区恢复后，可以重新再下发策略，进行回调。
流量调度系统图：
长连接层做好容灾后，逻辑层也需要做相应容灾。之前我们逻辑层都部署在一个机房，不具备机房机容灾能力，当一个机房出现断电风险，会出现服务整体不可用问题，因此我们做"同城双活"部署方案改造。
逻辑层单活架构：
逻辑层分别在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。
存储容灾方案对比：
本文从系统架构容灾、流量容灾、存储容灾三个方面讲述了推送系统容灾建设过程。系统容灾需要根据业务发展，成本收益，实现难度等多方面考虑。
当前我们长连接层已具备三地部署，逻辑层具备同城双活，数据中心为单数据中心。后续我们会持续研究和规划双数据中心，两地三中心部署架构方式来逐步加强推送系统容灾能力。
本文从零开始介绍了游戏推荐项目的发展历程，阐述了大型项目建设中遇到的业务与架构问题以及开发工程师们的解决方案，描绘了游戏推荐项目的特点以及业务发展方向，有着较好的参考与借鉴意义。
在大规模业务场景中，已经不可能通过单机提供业务，这就衍生出了负载均衡的需求。为了满足合适可靠的负载，本文将从简单的基础需求出发，一步步推进并解释如何建立负载均衡平台。
HBase是一款开源高可靠性、扩展性、高性能和灵活性的分布式非关系型数据库，本文围绕数据库选型以及使用HBase的痛点展开，从四个方面对HBase的使用进行优化，取得了一些不错效果。