服务器和客户端同步状态,客户端不能依赖服务器的响应
有一类系统,基本上所有操作都要求在线。在客户端产生的数据,直接提交到服务器,本地不存数据,或者仅保存少量缓存数据。这类应用有一个优势,就是客户端和服务器的数据始终是同步的,罕有两端不一致的情况。但是也有缺点,即对网络条件要求高,在网络条件不好的时候,用户操作需要等待,甚至无法正常使用
我们的一个APP,与上述系统不同,是支持离线操作的。数据在本地和服务器各有一份,然后通过同步机制来保持一致。这样做的缺点是提升了系统的复杂性,因为如果设计有缺陷,就很容易发生两端数据不一致的情况;另外就是如果客户端长期离线,存在数据丢失的风险。当然好处也很明显,即操作不依赖网络,所以非常流畅。即使在无网络条件下,也可以正常使用,只要在网络恢复以后,与服务器做数据同步就可以了
这类数据同步方案的一个常见错误,是客户端依赖服务器的响应结果。我们的老方案就踩了不少坑,本文总结几个常见的场景
比如这个场景:
1、客户端向服务器发起一个请求
2、服务器收到此请求以后,往数据库写入一条记录,返回成功响应
3、客户端收到响应以后,往本地也写入一条记录
看起来这个方案还不错,很直观,并且两端都有了同样的数据。但是这只是理想情况。有一天我们的系统访问量突然增大,导致服务器的负载升高,每个请求都处理得很慢,于是客户端超时了。所以客户端认为此次请求失败,没有往本地写数据,但是其实服务器稍后还是处理了这条请求。于是服务器就比客户端多了一条数据。更糟糕的情况是,客户端认为操作失败,继续反复发起请求,当然毫无例外地全部超时了,于是服务器里就多了N条记录……这是一个很容易模拟重现的场景,只要在服务端的代码里打一个断点,然后等客户端超时以后,再把断点走下去就行了
后来为了解决这个问题,我们试过增加防重复提交的机制,但是也不理想。因为首先,“重复提交”本身就是一个模糊的概念,什么样的提交算是重复提交呢,如果认为用户在同一个界面重复点击是重复提交,那么如果用户关掉窗口再来一次,是否也算重复提交呢?其次,数据同步机制本来就比较复杂,再加一个新的纠错机制,会让系统更加复杂,隐藏更多出BUG的可能性。最后,即使真的有了完美的防重复提交方案,也只能解决“多N条”的问题,还是解决不了“多一条”的问题
最后我们采取的办法是,先往本地插入一条记录,然后再提交到服务器去异步处理。由于是异步的,必然存在一个时间差(特别是客户端离线的时候,时间差还会比较长),所以会有短时间的两端数据不一致,但是只要最终一致,也就达到了目的
再比如这个场景:
1、客户端生成自从上次同步以后的新差量数据
2、将数据发到服务器,服务器处理,返回成功响应
3、客户端收到成功响应以后,删除这批数据
和上一个场景也有类似的问题,服务端处理得慢,导致客户端超时,差量数据没有被清除,但是这些数据实际上已经写入了服务器。于是下次同步的时候,重复的数据就又发到了服务器;此外还有另一个BUG,由于上报的时候,有2份差量数据(上次未清除的,此次新生成的),所以上报也发生了错误
后来我们修改了这2个BUG,首先是服务器收到请求以后,不处理已经处理过的数据;客户端则是每次只上报最新的那份差量数据;另外还被迫加入了错误数据的清理机制……为了修复一个BUG,代码又复杂了很多
其实更好的做法,应该是客户端每次要同步的时候,都重新生成一份新的差量,上报以后,即使没有收到响应,也应该把这份差量删除。这样就避免了客户端堆积多份差量文件的情况。然后接下来,就面临一个选择:在没有收到响应的时候,应该怎么标识哪些数据是“新”的。这个时候,服务器的状态是不可知的(而不是确定的成功或者失败),如果假设服务器操作成功,那么就应该在客户端上把这些数据都标识成旧的,下次不要再提交;相反,如果假设服务器操作失败,就应该保留这些数据的状态,下次再提交上去。前者的风险在于,如果服务器真的处理失败了,客户端又不再提交这些数据,那么这部分数据就再也没有机会同步到服务器。后者的问题在于,服务器可能会重复写入。两相权衡,我们认为前者的问题更严重,因为会直接造成数据丢失,所以最终选择了后面的方案,但是在服务器加上防止重复写入的机制
以上2种场景,本质上都是因为客户端和服务器是分离的,明明是一个操作,却不在一个事务里,并且服务器的状况对于客户端来说有时是不可知的。具体的解决办法,需要根据实际场景分别处理,但是有一点是明确的,即客户端不能依赖服务器的响应,而是需要单独的机制来保证一致性
再延伸一点考虑,为什么在线的应用没有这类问题,就是因为客户端没有数据,所以在整个系统里只有一份数据,自然不存在数据不一致。当然,如果允许多个客户端同时操作,还是需要考虑并发操作时的异常场景。这是另外一个主题,本文不展开。还有一种更复杂的情况,就是有多于2份数据,比如有2个客户端都能操作,并且都和服务器同步,这时候系统的复杂性又大大提升,因为1份数据,什么都不需要做;2份数据,仅需要处理同步;>2份数据,则还需要处理数据合并。比如某个会员,原本的余额是3000。然后在客户端A做了2个操作,余额变成2000;在客户端B做了3个操作,余额变成2500。这时候他的实际余额是多少呢?显然2000和2500都是错误的,需要合并数据,一种思路是客户端定时把数据上报到服务器,在服务器执行合并逻辑,把数据合并到一个中心节点,再下发到各个客户端。这个场景不在本文的讨论范围,以后再单独写