直播-提升直播成功率

对数据与日志的定位分析后。简化核心流程如上图，我们可以看到：其实我们失败最大的问题在于push，也就是推送。
1. 通知主播push失败，用户盲等
2. 通知用户push失败，主播盲等
3. 以上两个结果都是直播失败

弃个推换jpush

了解到个推对android端内的用户走离线消息，导致端内用户无法收到消息。我们决定放弃个推，转而开始测试jpush。在一些简单的测试和讨论后，我们接入了jpush。这是个痛苦的决定，老用户的绑定切换以及两家之间的互斥关系。
接完jpush之后，内测阶段似乎很理想，成功率大大提升了很多。在观察了一周左右的数据后我们发现：
1. jpush在9点之后送达失败（我们定义的失败是：在15s内如果消息没能送达到客户端就是失败的）开始上升
2. jpush在别名绑定的时候，因为我们采用的是用户每次登陆的时候重新绑定别名。jpush在这个过程开始出现用户别名绑定失败，这就意味着push失败
3. jpush显示消息送达，我们的服务器并未收到客户端的响应

问题解决

1. 针对问题1，我们很快开通vip，以为问题1可以解决了，事实并不是。
2. 问题2，我们用了一周的时间定位问题2，也找对方协助解决，最后也把每次登陆重新绑定改为绑定过之后不在绑定，问题似乎解决了（后台监控显示别名绑定失败率降低，转而变为问题3）。
3. 问题3，关于这个问题，之前服务端只是简单采集推送失败（别名绑定失败）。之后开始在推送之后30s左右采集送达情况，jpush官方给的答案是统计数据不实时但不影响推送。

针对问题3补充：当时在和jpush官方技术人员定位问题时，说了一些比较过激的话。如果比较巧合的是你们也看到了这篇文章，请接受我的歉意。

对于我们系统的推送，能够容忍的极限等待时间是15s。如果15s的时间推送无法送达就是一次失败的push。理想的push时间是1-5s，对阶段性的数据分析，jpush并没有达到我们想要的效果。虽然相比于个推，android和ios两个端的成功率都接近45%附近，但是距离我们想要的还很远。此处解释下，我们并不对个推和jpush做过多的评价。毕竟公司和技术都在进步，只是他们目前达不到我们比较高的及时性要求而已，不表示推送无法送达。

建立自己的长连接

正如文章开头所说，我们最大的问题在于消息送达率以及送达效率。在我们用户数据还未达到一个量值之后，一个很小量的消息都没办法保证及时送达我们客户端，对于我们自己来说是很不能理解的。

先做几个简单的假设：
1. 如果主播和用户都在端内，理论上数据应该很快送达（排除网络等因素），走长连接
2. 如果用户在后端运行app，未被系统杀死： ios, android似乎可以唤醒app（走长连接）
3. 如果app被杀死： ios走apns（依赖苹果，理论上可以送达），android （目前所有第三方推送都送达不了，5.0+）
4. 1）如果用户比较足的情况，主播一般都在端内；2） 用户基本都在端内

基于以上4个假设，我们完全有理由相信建立自己的长连接远优于依赖第三方推送。

九月中旬，团队开始接入长连接。
服务端和android端接入了netty，ios端接入cocoaasyncsocket

android和ios在10月份左右上线了第一个自有长连接版本。
1. android 因为在数据返回存在一定的问题，线上版本终止长连接
2. ios因为用户在端内直接锁屏，导致收到消息未能通知用户，以及其他一些发现的问题，线上版本终止长连接

虽然这版本的两个端寿命都非常的短暂，但是却给我们提供了一些有用的数据。10月底发布的版本，我们做了以下的一些调整：
1. 修改了之前版本存在的问题
2. 服务端在2s内未能收到客户端的响应，则关闭客户端长连接，走第三方push
3. 客户端返回的状态为后台运行app，走第三方push

调整之后的顺序图如下图：

上图为某一天的采集数据：
android 1.2.0 和ios1.2.0 走的是自有长连接，连续观察一周多的数据显示基本保持80%以上。

自此，系统直播成功率已经达到我们基本标准。之后从以下方面优化：
1. 降低用户的平均等待时长
2. 处理客户端其他极端情况