视频谈话记录和直播系统的实现（三）处理一定会存在的意外情况

  乍看标题，“一定“和“意外“似乎有点相互矛盾，其实不然。“一定”是说这种意料之外的情况在特定的情况下一定会发生，而“意外”则是说正常操作流程下，不应该发生的情况。

产生意外的场景

  这里所说的“意外”，不包括因编码、数据类型、长度等致使程序发生的异常，这些异常应在代码中捕获并处理，不在本文的讨论范围内。下面只讨论谈话流程开始后，因用户原因、网络原因、设备原因导致的正常操作流程中断，例如：

1. 谈话记录过程中，用户刷新、后退了当前页面、或者直接关闭了浏览器；
2. 浏览器进程被强行终止；
3. 服务器端非正常退出（死机、断电、故障等）；
4. 网络原因导致的通信中断。

处理意外情况达到的目标

1. 谈话记录必须有对应的录像文件；
2. 谈话结束时间，应该以录像文件的时长为参照；
3. 未正常技术的谈话记录，应该有自动处理机制；实在无法处理的，做好标记等候人工复核。
4. 谈话流程形成闭环，保证数据完整有效。

业务逻辑草图

  具体的代码在这里就不写了，从下图可以很清晰的梳理出要点。

  至此，该系统的原型结构测试就算完成了，剩下的任务就是按部就班的UI、数据处理了。相信大家都有属于自己的一套框架，不用在这里啰嗦了。

原型测试代码下载地址

  已经上传到资源下载。传送门在此。