本篇文章简单介绍了在业务逻辑中处理断线重连的一种方法

之前一直对如何在业务逻辑中处理断线重连没有一个清晰的认识,后来做了一些思考,这里简单记录一下~

假设存在一段业务逻辑 A A A ,整体实现上分为两部分:

• 服务器逻辑部分 A S A_S AS​
• 客户端逻辑部分 A C A_C AC​

一般来讲都是 A S A_S AS​ 负责维护逻辑状态与事件分发, A C A_C AC​ 则主要负责显示,输入等表现层的处理.

假设 A C A_C AC​ 不存在状态存储,仅作为纯终端显示的话,那么我们就不用处理断线重连的问题了,因为 A C A_C AC​ 的显示(由 A S A_S AS​ 驱动)总是与 A S A_S AS​ 同步的.

不过在现实的开发中并没有这么理想化, A C A_C AC​ 或多或少总会在本地存储一些状态,于是 A C A_C AC​ 与 A S A_S AS​ 便产生了状态同步问题,如果网络条件良好,逻辑上也没有纰漏的话, A C A_C AC​ 与 A S A_S AS​ 间的状态同步其实也不会存在什么问题.

只是一旦引入断线重连,状态同步问题就出现了,因为在 A C A_C AC​ 断线然后进行重连的这段时间中, A S A_S AS​ 发生的状态变化将无法同步至 A C A_C AC​, 甚至 A C A_C AC​ 重连成功之后, A S A_S AS​ 本身都可能因为处理完毕而结束了自己的逻辑过程.

那么如何正确的处理这种情况下的断线重连呢?

以下是我的一点思考:

• A S A_S AS​ 与 A C A_C AC​ 都监听并处理 o n _ r e l a y _ s u c c e s s on\_relay\_success on_relay_success 事件
• A C A_C AC​ 在 o n _ r e l a y _ s u c c e s s on\_relay\_success on_relay_success 事件中将本地所有相关的逻辑状态清空
• A S A_S AS​ 在 o n _ r e l a y _ s u c c e s s on\_relay\_success on_relay_success 事件中将 A C A_C AC​ 所需要的逻辑状态做一次全量同步(需要保证 A S A_S AS​ 的 o n _ r e l a y _ s u c c e s s on\_relay\_success on_relay_success 事件发生在 A C A_C AC​ 的 o n _ r e l a y _ s u c c e s s on\_relay\_success on_relay_success 事件之后)

除了逻辑状态以外, A S A_S AS​ 与 A C A_C AC​ 之间可能还会进行事件通知,推荐规避这些事件通知,都改以状态(的变化)实现.

采用上述方案之后, A C A_C AC​ 就能在重连成功之后,获得最新的 A S A_S AS​ 状态,于是便能与 A S A_S AS​ 再次形成同步;即便此时 A S A_S AS​ 逻辑已经退出,不再能推送当前状态信息,也因为 A C A_C AC​ 在 o n _ r e l a y _ s u c c e s s on\_relay\_success on_relay_success 之后主动做了一次状态清除操作,所以状态上也是同步的( A S A_S AS​ 退出便意味着 A C A_C AC​ 状态需要清除).