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

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

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

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

图 4：消息状态机

重发机制

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

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

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

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

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

（编辑：网站开发网_盐城站长网 ）

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