上篇《表设计与相关逻辑》里提到异常退出的处理方案：使用定时任务，用直播间表关联场次表，去查询“当天”“直播已结束”“场次结束时间为空”的直播间ID、场次ID、直播间更改时间，然后，将直播间的更改时间，作为异常退出没有结束时间的场次数据的直播结束时间，批量去更改，即可。

这个地方的筛选条件，经验证，发现有问题，今天特发此文，进行纠正。数据表，还是接上篇《表设计与相关逻辑》里的表，那么，上文的问题在哪里呢？问题就在于，刚开的直播，流因网速等问题，还没同步到腾讯直播流数据中，此时表里的状态还是“暂未直播”，而场次表里，恰好“场次结束时间”也为空，因此，就在这1~3秒的时间里，异常处理的定时任务，就会将还没来得及同步流到腾讯云的直播间数据，当成异常数据处理，这就不对了。

那么，更改后的方案是什么呢，后来，我仔细观察，发现，刚开的直播间场次，“创建时间”和“更改时间”这两个字段的值，是一样的；此外，因为我在腾讯云配置了“断流消息通知”的回调接口，一旦出现异常退出，肯定会触发断流回调，这时，场次表里的更改时间，就会发生变化，创建时间不会，因此，通过这个特征，我们就可以匹配到刚开的直播间。

于是，最终的方案，就更改为：用场次表关联直播间表，去查询“当天”“直播已结束”“场次结束时间为空”的直播间ID、场次ID、直播间更改时间、场次的创建时间、场次的更改时间，获取结果后，将场次创建时间和更改时间相同的数据，过滤掉，剩下的即是异常退出的数据，最后，将直播间的更改时间，作为异常退出没有结束时间的场次数据的直播结束时间，批量去更改，就可以了！

切记，异常退出的定时任务，执行时间不要设置太长，否则，当主播再次开启直播，你上一个场次的结束时间，就捕捉不到了；而且，场次表上一个异常数据还“未结束”，状态1，这样，就会出现脏数据。

导致的后果，就是主播再次直播的场次，可能对应的并非最新的，而是上一条的异常数据，后续的送礼物，场次结束观看人数、关注人数、打赏礼物等的统计，都会出现问题，甚至，一些意想不到的其他问题！这个问题一定要注意，否则，牵一发动全身，后面的排错会耗费你大量的时间。说一下，我这边设置的是3秒执行一次！仅供参考！




The END!                                                                                     2020/4/17 12:18:18