整体概述
如上图,整个直播业务逻辑相对简单。
1. 用户搜索主播,业务服务器返回可用主播
2. 用户翻牌(用户同意直播),业务服务器通知(push)主播
3. 主播拒绝直播,通知用户
4. 主播同意直播,创建房间,通知用户(push)进入房间
5. 用户成功进入房间,直播开始,活动直播可用时长(收费)
7. 直播结束
计费模式
直播按分钟计费。系统可采用实时计费,非实时计费
1. 实时计费。系统每隔规定时间(5s)完成一次计费。系统存在很多弊端: 性能,实时性要求都比较高。优点则是计费相对合理准确。
2. 非实时计费: 在直播开始给定当次直播可用时长,客户端在直播时长达到可用时长即退出直播。优缺点如下:
- 弊端:
1. 计费可能存在一定的误差(本系统采用按分钟计费,不足1分钟按一分钟算)
2. 客户端未正确获取直播可用时长,出现无限直播
3. 客服端在规定时间内未能正常终止直播
4. 主播和用户同时非正常退出(闪退,杀死app),导致当次直播无计费
5. 用户非正常退出(闪退,杀死app), 主播无限挂机导致用户费用增多
- 优点: 服务端压力降低等
最后分析总结: 本系统采用非实时计费方式,直播开始后服务端返回当次直播可用时长(用户可用虚拟币兑换时间),客户端对可用时长倒计时,直播时长大于等于可用时长即退出直播。
遇到的问题
图中标红部分表示消息需要push到客户端,第一版本采用个推做核心的推送,所有push部分都采用第三方推送实现。
1. push量小、闲时似乎没问题,9点(高峰期)之后推送送达率直线下降
2. 个推在处理push消息时,有在线和离线发送概念。在线发送走长连接机制。离线ios走apns,android离线消息基本送达不了(目前所有第三方都送达不了)
3. 因为离线和在线推送的原因,android用户即使在端内,消息也走离线。个推在android推送时送达率几乎直线下降
4. 因为问题3的原因,android 在早期两个版本直播成功率低于2%
5. push送达不及时,延迟较为严重
6. 客户端系统时间异常(系统时间大于互联网时间),导致客户端在收到消息后对消息时效验证时忽略此消息。(此处大坑,市面上目前有些APP在客户端时间不对时直接出错,支付宝,虎嗅,36K部分数据直接加载不了,36k图片资源直接拉不出来)
7. ios为方便测试,增加企业版本,导致在企业,测试,线上版本之间切换出现各种奇葩问题
8. 本系统采用的计费模式存在的问题
注(个推我们开通的vip服务)
以上问题的解决
- 关于推送的问题后续文章做补充说明
- 问题6提供两种方案:1)客户端请求服务端标准时间戳, 2)强制用户设置系统时间为互联网时间
- 问题7 企业版本实属无奈之举(苹果:怪我咯)。企业版在9月份出现证书过期导致企业版本用户全部推送时效(证书为借用其他公司的证书),之后也因为苹果审核加快全部移除企业版
- 问题8 之后文章详细描述,因其涉及直播过程以及客户端较多极端情况
第一版本上线后结果
- android在8月初上线第一个版本,我只能用噩梦形容。后台监控数据得到的结果,用户基本都是直播失败。各个环节都是问题: 主播收不到消息,用户收不到消息,进入房间失败等等。
- ios因审核原因,8月初提交直到9月初才正式上线。中间被拒9次。ios的情况略好于android,毕竟在端内的ios用户消息送达情况还算能接受。但是直播成功率也是远低于20%
总结
八月份,我们每天定位问题。每天看日志,用户反馈。团队气氛很是低落,对于自己的系统我只想用两个字形容:垃圾。以下几点可能是导致我们的问题:
1. 主播在用户连接时才开始创建房间
2. 用户和主播直接的事件需要通过消息传递
3. 推送永远是不及时,不稳定的
4. 所有依赖推送的都会被第三方推送绑定
5. 收费直播
6. 有主播没用户,有用户没主播。
7. 一对一用户瓶颈过于明显(平台主播需要审核通过的帅哥)
8. 在技术选型时没有充足时间验证(转化为经验不足)