直播-失败的开始

整体概述

如上图，整个直播业务逻辑相对简单。
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服务）

以上问题的解决

1. 关于推送的问题后续文章做补充说明
2. 问题6提供两种方案：1）客户端请求服务端标准时间戳， 2）强制用户设置系统时间为互联网时间
3. 问题7 企业版本实属无奈之举（苹果：怪我咯）。企业版在9月份出现证书过期导致企业版本用户全部推送时效（证书为借用其他公司的证书），之后也因为苹果审核加快全部移除企业版
4. 问题8 之后文章详细描述，因其涉及直播过程以及客户端较多极端情况

第一版本上线后结果

1. android在8月初上线第一个版本，我只能用噩梦形容。后台监控数据得到的结果，用户基本都是直播失败。各个环节都是问题： 主播收不到消息，用户收不到消息，进入房间失败等等。
2. ios因审核原因，8月初提交直到9月初才正式上线。中间被拒9次。ios的情况略好于android，毕竟在端内的ios用户消息送达情况还算能接受。但是直播成功率也是远低于20%

总结

八月份，我们每天定位问题。每天看日志，用户反馈。团队气氛很是低落，对于自己的系统我只想用两个字形容：垃圾。以下几点可能是导致我们的问题：
1. 主播在用户连接时才开始创建房间
2. 用户和主播直接的事件需要通过消息传递
3. 推送永远是不及时，不稳定的
4. 所有依赖推送的都会被第三方推送绑定
5. 收费直播
6. 有主播没用户，有用户没主播。
7. 一对一用户瓶颈过于明显（平台主播需要审核通过的帅哥）
8. 在技术选型时没有充足时间验证（转化为经验不足）