五分钟学会智能多通道推送（PUSH）技术

最新推荐文章于 2022-10-25 21:38:55 发布

musicml

最新推荐文章于 2022-10-25 21:38:55 发布

阅读量1.5k

点赞数

本文链接：https://blog.csdn.net/musicml/article/details/103878378

版权

背景

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