背景
用户在管理直播的过程中，需要判断主播是否在线，即主播开关播。
鉴于网络抖动等一些不可抗因素，通常我们建议用户优先使用业务自身房间的开关播逻辑，判断主播是否在线，例如客户端开播信令和主播在线心跳等。
存在的问题
在实际使用中，用户会根据最晚回调时间的回调请求来判断主播在线状态。使用这种方式判断，最常见的问题是乱序问题。
乱序是指当两次推断流间隔很短的情况下，用户流断开就立马就推流上。
因为直播系统的请求方式是异步请求，可能会出现重新推流的推流回调在上一次断流回调之前，用户会收到断流回调，从而认为主播已经下线，导致直播间一直处于非正常下线状态。在网络抖动等不可抗因素下，也不一定能保证一直保持 一次推流回调 对应 一次断流回调 这样的理想顺序。
注意：
在主备流的场景下，主备流同时推流时，只断了其中一路，不能光凭收到断流回调就判断主播关播。
解决方案
下面推荐几种方案，您可以根据自己的实际情况使用其中一种或者多种结合。
方案 | 方案描述 | 判断主播在线的方法描述 |
回调事件中的 sequence 查询判断 | sequence 是回调事件中产生的消息序列号，用来标识一次推流活动的过程。一次推流活动会产生相同序列号的推流和断流消息，每次推流的 sequence 都是唯一的 | 乱序场景：比如您回调过程中收到的信息是推流回调 sequence1、推流回调 sequence2 、断流回调 sequence1，那您在收到回调信息回调时，您就可以对sequence 进行匹配判断，就可以发现第二次推流并没有产生断流的回调信息，从而就可以判断主播此时还处于开播状态 |
回调事件中的 event_time 查询判断 | event_time 是推流/断流产生的时间戳，这个时间不会因为网络抖动等问题而变化 | event_time 基本在推流和断流产生的那一刻就生成了，所以推流事件中的 event_time 比断流事件中的 event_time 大。您此时只需要对比这个时间，便会发现断流回调在推流回调之前，从而可以判断现在主播仍在线n |
通过定时（间隔 > 1min）查询判断 | 定时调取接口，根据接口返回的正在直播中的所有流列表，查询该接口是否返回的有您所关注的主播信息，从而来判断主播是否在线 | |
通过查询流判断 | 调取该接口，根据指定流 ID 查询该路流的一个状态值，从而判断主播是否在线 |
说明：
解决方案中任一方式判断为在线，都可以认为主播开播中，并且接口查询超时或解析异常时，也默认为在线，减少对业务的影响。