博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
推送方案的评价标准
阅读量:6330 次
发布时间:2019-06-22

本文共 788 字,大约阅读时间需要 2 分钟。

推送方案的公认评价采取4s标准:1.Safe(安全) 2. Stable(稳定) 3.Save(省电省流量省成本) 4.Slim(体积小)

Safe (安全)

推送方案应支持 及各种 方案,保障信息传递安全。
推送方案的ID系统应该独立于已有的网站或服务的ID系统,这样保障用户在不同手机上登录后的信息投递准确性,避免因为取消绑定事件失败因网络传输而造成的信息误投送。

Stable(稳定)

稳定包括两个部分一个是服务器端的稳定性,一个是手机端的稳定性。
服务端稳定性,因为使用长连接方案,对服务器的开销和要求很大,推送方案对服务器开发要求很高,海量 连接下的服务器稳定性是非常具有挑战性的。一般的评判标准包括:
- 同时在线时峰值 (一般按照百万并发连接时服务器稳定性评测)
- 高并发时消息平均延迟时间(一般按照1分钟处理1百万条信息评测)
- 服务稳定性 (一般要求全年99.9%以上可用,有备份,有负载均衡等)
鉴于服务器稳定的开发难度很大,小团队不建议自己开发,建议使用稳定的第三方推送方案,如 ,蝴蝶等。
手机端的稳定性,主要是因为中国的复杂网络状况及手机型号适配情况造成手机长时间稳定联网较困难,所以稳定性非常重要,一般的评判标准包括:
- 每日联网23.5小时以上用户比例 (表征联网稳定性)
- 消息发送后9小时内收到率 (表征到达率)
一般来说,推送方案要做网络的分运营商,分省,分机型适配,自己开发工作量较大

Save(节省)

省电应注意CPU休眠,一般用服务缩短待机时间百分比评判
省流量应注意协议的修改和冗余数据包的处理,一般用空载待机月流量评判
省成本应考虑单服务器承载同时连接数,可承载同时连接数越多成本越低,业内 顶尖水平为 的单服务器50万连接

Slim(体积小)

推送服务应该体积尽量小,不影响主程序的大小和复杂度,一般以小于300K为宜。

转载地址:http://nzfoa.baihongyu.com/

你可能感兴趣的文章
各种排序算法总结篇(高速/堆/希尔/归并)
查看>>
使用c#訪问Access数据库时,提示找不到可安装的 ISAM
查看>>
Highcharts X轴纵向显示
查看>>
windows 注册表讲解
查看>>
【算法】论平衡二叉树(AVL)的正确种植方法
查看>>
基于DDD的现代ASP.NET开发框架--ABP系列之1、ABP总体介绍
查看>>
【原】东拼西凑PBR(1):PBR基础
查看>>
react 从零开始搭建开发环境
查看>>
scala recursive value x$5 needs type
查看>>
ps -ef |grep 输出的具体含义
查看>>
markdown编辑
查看>>
ASCII 在线转换器
查看>>
Linux内核同步:RCU
查看>>
Android逆向进阶——让你自由自在脱壳的热身运动(dex篇)
查看>>
Java设计模式之五大创建型模式(附实例和详解)
查看>>
60 Permutation Sequence
查看>>
主流的RPC框架有哪些
查看>>
Hive学习之路 (七)Hive的DDL操作
查看>>
[转]mysql使用关键字作为列名的处理方式
查看>>
awesome go library 库,推荐使用的golang库
查看>>