登录 立即注册
金钱:

Code4App-iOS开发-iOS 开源代码库-iOS代码实例搜索-iOS特效示例-iOS代码例子下载-Code4App.com

基于MQTT和ProtocolBuffer的推送系统(iOS) [复制链接]

2019-1-8 10:06
sergiochanTest 阅读:286 评论:0 赞:0
Tag:  

由于业务需求,需要实现实时获取服务端更新的数据功能,基于这个需求,进行调研及技术方案的实施,最终决定采用MQTT +ProtocolBuffer基于长连接的数据实时推送的方案;具体实现方案见本文;
本文包括三个部分:1.技术选型 2.技术方案实践 3.未来优化方向


技术选型

在调研过程中,发现需求功能可以使用推送来实现,但最终经过各种考虑,发现自建长连接进行实时数据推送是最为贴合需求的实现方案;调研过程中,对推送厂家方案及本文方案做了对比,结果如下:

推送SDK集成APNs保持长连接
极光推送
个推
百度推送
腾讯信鸽
本文方案

从表格来看,本文方案不过是极光推送和个推的一种简化版,完全可以使用极光推送和个推来实现,或者是使用推送来进行数据推送;但从需求具体来讲,才更能体现本文方案的可行性及必要性;具体分析如下:

  1. 推送方案具有极大的不确定性,消息丢失率比较高

  2. 极光推送和个推SDK采用了长连接的方式,但是长连接协议并不可知,且数据传输格式,链接存在状态不受控制

  3. 自定方案,因采用MQTT 和 Protocol Buffer两种协议,对弱网情况兼容较好,设备性能要求相对较低,且对数据格式优化比较好,且链接状态完全可控,可以实时监控到链路是否可用,对分析问题、解决问题有很大便利;


技术方案实践

方案流程

整个技术方案大体流程如下图:


在整个过程中,消息的实时传送靠推送后台和长连接SDK建立的长连接来实现;而基于本方案实现的SDK则负责和推送后台维持长连接的有效性以及维持长连接的优化功能;

详细流程中涉及到的交互方和交互流程参照下图:



方案架构

在整个数据实时传送方案中,涉及到长连接的建立维护、通信数据按协议封装、业务数据封装及优化等功能,在此对整个方案进行整理,整理之后结构如下:


在整体结构中,分为业务层、应用层、传输层、和网络层,其中业务层、应用层、传输层组成了数据实时推送服务的SDK;
1.业务层:主要处理业务数据,消息存储,消息丢失、重复处理,以及数据格式转化等;
2.应用层:该层为整个SDK的核心层,封装了MQTT协议,以及对断线重连、安全连接等;
3.传输层:该层主要核心为调用系统API实现长连接、数据封包、超时重发等处理;

下面对整个SDK架构层级,以及各层级间包含的模块进行详细整理及说明;如下图:



业务层

该层主要解决,数据格式转化,消息丢失、重复,消息存储,数据统计等功能;下边对这些功能逐一介绍:

  1. 数据格式转化: 此模块负责将ProtocolBuffer类型的数据转化成JSON数据

  2. 消息重复、丢失处理:此模块会根据规则判断收到的消息是否重复,或者在收到该信息之前是否丢过消息,经过处理之后,如果重复则不再传给业务方,如果有消息丢失也将告诉业务方,以便业务方处理相关情况;

  3. 消息存储:根据一定缓存策略对消息进行短时间存储,以便解决消息判重、处理丢失等问题;

  4. 数据统计:此模块将对消息进行统计,区分重复、丢失等情况,并将数据上报服务器,方便验证整个方案的可行性和问题等;

应用层
该层命名的来源主要来自于MQTT,因MQTT属于业务层协议,该层的操作绝大部分是对协议的实现以及优化;主要包含 MQTT的实现、心跳机制、断线重连机制、链接状态管理等;

  1. MQTT的实现:此模块主要采用三方库MQTTClient,该三方库对MQTT协议进行了完整封装,目前阶段,该方案对MQTT协议的实现暂时依赖该库;

  2. 心跳机制:因项目初期,且方案有待验证,此模块暂时使用较为简单的固定心跳机制,设置心跳间隔为60S;对于该心跳间隔,因不确定个运营商的NAT超时时间,故对心跳间隔设置较小,此间隔可能引起手机流量、电量消耗的增加,此模块为后续重点优化模块;

  3. 断线重连机制:因存在网络切换、移动网络基站变更、以及网络断开等问题,特提供断线重连机制,此机制目前采用方案为:以2的n次方为时间间隔进行重连,n为重连次数,当n等于6时不再重试;

  4. 链接状态管理:此模块负责对应用前台、后台不同状态情况下,链接的处理情况的管理;

传输层
该层主要为调用系统API对Socket数据进行拼接组装,以及发起连接、关闭连接等操作;

对于该方案的具体模块,以上均已介绍完毕,以下是对该方案大致流程的梳理,如下图:



此流程展示出了SDK从建立链接、接收数据,经由TCP数据包处理、MQTT通信数据解析,到ProtocolBuffer数据格式处理等大致流程;到此,整个现有方案结束;


未来优化方向

考虑到移动端手机电量、流量、及网络连接不稳定的情况,上述方案显然不是完美的方案,针对上述方案,现有以下规划:

智能心跳策略

因心跳是保证连接存活的必要手段,心跳的存在毋庸置疑,但是心跳的存在,也必定会增加电量、流量的消耗;在此针对该方案的心跳策略提出以下针对性优化设想,特提出以下方案---智能心跳策略;大致流程如下图:



断线重连机制优化

因有可能发生服务器异常,造成客户端集体掉线的情况,客户端会立刻发起重连,在用户量较小的情况下,客户端集体重连对于服务端可以承受,但当用户量级达到一定数量,大量客户端的重连,可能就会产生重连风暴,直接导致服务端再次出现异常,因此对于重连机制也应考虑一个比较合适、能避免重连风暴的策略;

网络连接优化

IP直连、链路复用、控制传输包大小等、


分享到:
我来说两句
facelist
您需要登录后才可以评论 登录 | 立即注册
所有评论(0)
关闭

每日头条

通过邮件订阅最新 Code4App 信息
上一条 /4 下一条
联系我们
关闭
合作电话:
13802416937
Email:
435399051@qq.com
商务市场合作/投稿
问题反馈及帮助
联系我们

广告投放| 广东互联网违法和不良信息举报中心|中国互联网举报中心|Github|申请友链|手机版|Code4App ( 粤ICP备15117877号-1 )

返回顶部