五分钟学会智能多通道推送(PUSH)技术

背景

目前手机APP都具有消息推送功能,比如电商类APP会推送活动宣传和促销信息,天气类APP会根据天气变化为你推送天气信息,新闻类APP会定期推送新闻资讯,聊天类APP会把离线消息做成实时推送消息,可以说推送功能已经在手机APP中扮演着越来越重的角色。从运营的角度看推送也是召回用户,提高用户活跃度和粘性的有效手段。

在iOS平台推送功能全部由APNs(ApplePush Notification service)接管,对开发者来说别无选择,当然效果也非常好。

图1 iOS 移动PUSH推送流程

在Android平台Google也提供了一个类似于APNs的功能,但是由于众所周知的原因Google的服务在国内经常不可用,所以国内很多手机厂商直接直接把GCM/C2DM(Cloudto DeviceMessaging)模块去掉了,所以Android推送在国内就出现了很多解决办法。安卓推送总体来说有三种模式:一、手机品牌厂商自建推送通道(小米推送,华为推送等),二、第三方推送比如(个推推送,极光推送等),三、手机应用自建推送通道。

图2 Google GCM/C2DM推送流程

目前Android上绝大部分推送都是基于长连接的Client-Server架构,需要客户端和服务器之间保持一个长连接,虽然Android是可以允许程序驻留在后台,但是由于手机厂商和各种清理程序查杀工具越发严格,所以这个长连接非常不稳定,除非具有庞大用户群和巨大话语权的APP,所以自建通道对普通APP效果不一定最优。手机厂商自建推送通道在自己手机品牌上使用的系统级长连接,所以在自有品牌上到达率是有保证的。第三方推送由于拥有许多手机应用可以做到各种应用直接相互唤醒,所以也能在一定程度上提高到达率。

表1 活跃用户(A通道)各个品牌手机到达率

表2 活跃用户(B通道)各个品牌手机到达率

对每种品牌手机我们希望选择到达率高的通道进行推送,所以多通道推送就成为我们迫切的需求,同时为了增加可靠性,确保服务有较强的容灾能力,我们也需要多通道推送作为保证。

安卓多通道推送整体流程图如下:

图3 智能多通道推送整体流程图

Token获取

为了实现多通道推送,客户端会集成多个推送通道的SDK,SDK会在初始化时将客户手机Token上报给服务端,但是每个SDK都会在一定时间间隔向服务端发送心跳,这样就会使客户端程序耗电量成倍增加,所以客户端要在开启SDK之前请求服务端,根据服务端下发的开启通道指令初始化对应的SDK。具体要开启哪个SDK是逻辑控制层根据取配置中心规则决定,只有在配置发生变化时才会重新通知SDK重新上报Token,这样就也减少了服务端存储重复Token的问题。

图4 客户端Token上报流程图

multiPush

多通道推送分为多种模式,一种是根据业务需求实时推送,另外则是根据某些特征进行的批量推送。我们既要减少数据库的查询压力又要保证数据有比较小的延迟。我们用两个线程分别对发送内存队列做扫描,当消息个数或时间满足条件才会聚合数据,到数据库批量查询结果,最后组装包体交给pushProvider程序。

图5 multiPush客户端原理图

pushProvider

该模块有两个主要功能:一是要尽快把数据推送到第三方推送平台,二是根据配置中心的配置选择出正确通道。

图6 服务端多通道推送流程图

配置中心

配置中心有两种数据,一种是根据各个通道,各个手机品牌,各个APP的推送到达率不同,推荐出的最优通道,二是需要我们人工干预的通道选择开关选项,用于容灾控制和品牌到达率对比。

监控统计

实时统计是作为推送服务提供方,提供给服务使用方必备的功能。上游推送使用方发送完推送功能之后,可以使用实时统计推送结果查询推送结果。同时我们也可以在实时统计中进行达率统计,并对其进行监控,这样就可以及时发现第三方推送中出现的问题,我们随时进行调整。同时我们也可以对批量到达率进行统计分析之后放到配置中心,作为通道选择统计的必备数据。

图7 实时统计监控

总结和展望

本文介绍了58智能多通道推送的推送方案和每个部分的设计框架。分享出来希望和大家交流讨论。接下来我们可能会选择自建通道,虽然自建通道对到达率提高不会有太大帮助,但是现在需要我们对推送目标状态进行更加详细的数据,在线状态,网络情况,长连接的强度,推送失败的具体原因,只有拥有这些数据才能把推送到达率再上一个台阶。

参考

  1. http://bbs.hiapk.com/thread-4652657-1-1.html
  2. http://www.jianshu.com/p/d77eaca4e52a
  3. https://zhuanlan.zhihu.com/p/22909985

原文发布于微信公众号 - 架构之美(beautyArch)

原文发表时间:2017-01-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏游戏杂谈

chrome诡异的Provisional headers are shown

昨天吐槽了cocos2d-js的问题,所以就准备调研几个其它HTML5引擎,发现PIXI性能极高,但是没有音频。而Phaser.js是在PIXI.js的基础之上...

3.1K1
来自专栏流柯技术学院

LR--Controller的Pacing设置(不容忽视的设置)

笔者:很多人在使用LR时会忽略此选项,但对LR有深入理解的人,会经常使用该配置。测试场景:100个并发用户达到100TPS的处理能力,重点验证并发用户,也就是每...

1802
来自专栏顶级程序员

看似简单的 Windows 记事本,其实维护起来并不简单

相信大家对 Windows 系统自带的记事本程序都不会陌生,在座的各位或许还有用它来写代码的经历。看上去它的功能非常简单,但你能否想到即便功能如此简单的程序,也...

752
来自专栏CDA数据分析师

敲黑板!你和GitHub高手就差这三条规则······

本文不会介绍如何创建 GitHub 简历或如何使用终端提交 Git。我将解释每天使用 Git 和 GitHub 的重要性,尤其对于正在学习写代码的人。我还将分享...

1512
来自专栏杂烩

一种海量日志存储、分析解决方案V1.0 原

    flume,版本1.7.0,主要用来从业务系统收集数据以及从jms收集数据。

2622
来自专栏逸鹏说道

.Net 分布式云平台基础服务建设说明概要

.Net 分布式云平台基础服务建设说明概要 1) 背景 建设云平台的基础框架,用于支持各类云服务的业务的构建及发展。 2) 基础服务 根据目前对业务的理解和...

4118
来自专栏即时通讯技术

简述移动端IM开发的那些坑:架构设计、通信协议和客户端1、前言 2、学习交流3、概述4、有关移动端IM通信协议的坑5、移动端IM客户端的坑6、移动端IM架构设计的坑7、结语附录:更多IM技术文章

有过移动端开发经历的开发者都深有体会:移动端IM的开发,与传统PC端IM有很大的不同,尤其无线网络的不可靠性、移动端硬件设备资源的有限性等问题,导致一个完整的移...

2391
来自专栏Netkiller

PHP 7.0.0 一键安装脚本

OSCM (Operation System Configure Management) 是我创建的一个自动化运维脚本的项目,旨在提供敏捷运维。传统自动化运维工...

3395
来自专栏维恩的派VNPIE

适用于python3的CTP交易接口

目前vn.py官方适用的python版本是2.7,有关python3的版本正在开发中,但鉴于最近大家对python3需求的呼声较高,论坛有两个帖子提供了适用于p...

8084
来自专栏性能与架构

微服务架构

微服务产生的背景 在网站初期,网站的架构比较简单,通常把所有代码统一打包部署的服务器上 以java项目为例,例如有5个程序员,他们各自开发自己的功能模块,然后...

3365

扫码关注云+社区

领取腾讯云代金券