加入收藏 | 设为首页 | 会员中心 | 我要投稿 衡阳站长网 (https://www.0734zz.cn/)- 数据集成、设备管理、备份、数据加密、智能搜索!
当前位置: 首页 > 服务器 > 安全 > 正文

如何构建一套高可用的移动消息推送平台?

发布时间:2021-01-15 10:33:45 所属栏目:安全 来源:网络整理
导读:《如何构建一套高可用的移动消息推送平台?》要点: 本文介绍了如何构建一套高可用的移动消息推送平台?,希望对您有用。如果有疑问,可以联系我们。 作者:李晓清、董泽光 编辑:小智 消息推送作为移动 APP 运营中的一项关键技术,已经被越来越广泛的运用.本文

为了解决以上问题,我们考虑基于第三方消息推送服务构建一套移动消息推送中间件平台,该消息平台采用了低耦合的分层架构设计(如图 2 所示),分为三层:接入层、传输层和应用层.其中接入层是业务方调用的入口,我们采用异步消息队列的方式提供了较高的业务系统发送消息的速度,并且具备了消息缓冲功能,即使高峰期的海量消息推送对整个平台冲击较少,保护了推送系统;

传输层会从接入层接收消息并进行解析,对推送消息进行合法性检查校验,如果消息不合法直接丢弃,同时将合法的消息进行协议转换并发送到对应的第三方推送平台;应用层主要是提供统一的 SDK 供业务使用,封装适配第三方推送平台的 SDK 接口到统一的接口 SDK 中,这样业务 APP 使用方只关注统一封装的 SDK 即可实现业务消息的操作,而不需要考虑各种滤重、校验等通用操作.主要功能包括:

  • 屏蔽推送接口,实现业务与推送服务解耦,提供一套通用的客户端 SDK,简化客户端接入.
  • 实现多点接入,可同时接入多套推送服务,根据历史推送成功率动态选择最优推送路径,当一条路径失效可选择备用路径进行推送,保证消息推送万无一失.
  • 引入消息持久化机制,方便追溯和统计.
  • 引入消息的 ACK 机制和重传机制,提高消息的到达率.
  • 实现数据监控和统计机制,提供相关数据的统计分析,和报警预警功能.
  • 提供 web 管理后台,便于进行 APP 设置、推送设置、查看数据报表,提高系统维护的工作效率.

整个系统设计由三部分组成:移动推送平台、客户端 SDK、应用管理界面(第三方推送服务和自建推送服务统称为推送服务).

图 2:系统架构

移动推送平台提供统一的服务,对于应用层屏蔽推送服务接口,且实现推送服务可动态轮替.推送平台将接收到的消息持久化到数据库中,方便进行消息推送失败后的重发,以及后续数据的统计分析.

客户端 SDK 对 App 提供统一的使用接口,屏蔽推送服务 SDK 使用细节,且实现多种推送 SDK 可替换,隐藏 SDK 复杂的接入过程,方便使用.

应用管理系统面向 App 开发人员,实现应用申请,推送服务配置,消息查询与管理,数据统计与分析.

主要流程

消息推送涉及的主要模块是消息推送平台和客户端 SDK,主要流程如下图所示:

图 3:消息推送中间件核心流程

正常情况下,消息推送过程如下:

  • 系统接收到业务方的推送请求后,首先进行权限的验证,这包括应用 appKey 的验证、接口参数的验证、黑名单验证等.
  • 验证不通过,返回错误信息;验证通过后,为此条消息分配一个唯一 id(uuid),将消息内容持久化到数据库中,此时消息的状态为待发送.
  • 消息进入推送队列中,将之后推送接口请求的响应返回给业务方.
  • 推送队列的消费者从队列中取出待发送的消息,标记该条消息的状态为发送中,然后调用第三方推送服务接口进行发送.
  • 如果调用成功,那么标记该消息的状态为发送成功客户端未收到.
  • 客户端 SDK 在收到推送后,回调服务端接口,发送收到推送的回执;服务端收到客户端回执后,标记消息状态为发送成功客户端已收到.

对于推送过程中可能出现的异常情况,总结如下:

  • 在调用第三方推送服务接口时,可能出现调用失败的情况;此时需要标记消息的状态为发送失败,留待重发.
  • 在调用第三方推送服务接口成功后、第三方推送服务在下发至客户端的过程中,可能由于某种原因,造成客户端无法收到消息;此时消息的状态为发送成功客户端未收到,对于这种状态,需要重发.
  • 客户端在收到推送的消息后、向服务端发送 ACK 回执时,可能由于网络环境的问题,造成服务端没有收到客户端发送的回执,此时消息的状态为发送成功客户端未收到,需要重发.
  • 消息在重发 N 次(N 次可配置)、仍然没有进入发送成功客户端已收到的状态,那么将不再进行自动重发;管理界面将提供手动重发消息的操作入口,如有需要,可以手动再进行重发.监控平台对于一直重复不成功的消息会报警通知操作人员,这样操作人员可以及时通过手动方式处理.

根据消息发送流程,可以得到消息在生命周期中状态的变迁如下图:

图 4:消息状态机

重发机制

消息重发主要存在三种场景:系统启动时,查询所有的发送失败或发送成功未收到客户端回执的消息,加载到推送队列重发;系统运行时,后台线程定时查询需要重发的消息,进入推送队列;手动触发时,直接将消息加入推送队列.

由于消息推送中间件服务通常要求高可用,为分布式部署,消息重发必须保证在单一节点执行,且保证只发送一次.需采用分布式锁的方式,保证重发只发一次,主流实现方式有三种:

  1. ZooKeeper:通过竞争创建临时节点的方式获取锁.
  2. Redis:Redlock 是 Redis 作者的提出了一种分布式锁的算法,基于 Redis 实现,该算法实现了一种更安全、可靠的分布式锁管理.
  3. 数据库:如使用 MySQL 的 GET_LOCK 函数

对于每种锁机制的特点本文不详细介绍,根据实际应用需要任选一种即可.

由于 iOS 平台和 Android 平台的差异,消息重发需要考虑平台差异性.

(编辑:衡阳站长网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

热点阅读