Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

前后端数据同步的实现设想

  传统的Web以页面为单位,完全通过HTTP的缓存机制在客户端做缓存。这种实现方式完全可以不考虑数据同步的问题。但是现代Web就不同,网页中的数据是细分到单条记录的,缓存也是使用现代浏览器中的本地储存API来做的,那么这时就需要考虑数据同步问题。
  最简单的做法是,在请求数据之前判断本地的数据是否存在,存在则不发起请求。但是这种做法存在一个问题,比如我们现在以“聊天记录”为例。客户端访问某一页旧聊天记录时,它并不知道自己要访问的是哪些记录。一种可能的解决方案是为这些记录添加一个顺序的编号,这样客户端就可以计算出某一页聊天记录的条目序号。但这么做又会遇上另一个问题。假如这是一个群聊天记录,客户端并不是所有时候都在线,所以这些记录是断断续续的。那么请求服务器时如何告诉服务器自己需要哪些记录呢?照着这个思路下去大概会发展成直接告诉服务器自己缺少的记录。如果真的这么做,请求成本就会增加许多。当然也可以找到一些优化方案,比如告诉服务一个开始序号,然后用二进制的位来标识从这个序号之后的每个条目需要与否。
  以上这一大堆,都是建立在数据不会在服务器端被修改或删除的前提下。如果数据本身在服务器端是不稳定的,客户端就必须在使用任何数据前都发起请求来判断数据的最新状态。这么一来,一切缓存所带来的性能提升都化为乌有了。这篇文章的重点就在于解决这个问题。
  是否可以考虑让服务器端自己也维护一份客户端所持有的数据清单呢?如果服务器知道客户端缺什么,那么客户端发起的请求成本就会小很多,至少不会像上面的方案那么纠结吧?而且,服务器既然知道每个客户端各自持有的数据清单,它就可以在这些数据被修改或删除时通知相应的客户端(这可能需要服务器推送)。照着这个思路就可以彻底解决前后端的数据同步问题了,剩下的就是如何实现它和实现的成本分析。
  也许有人会质疑说,客户端有可能删除自己的本地数据,造成前后端的数据不同步。其实不用担心,普通用户绝对不会这么干,要教会他们这么干都得花上很长时间。只有一些程序猿做测试时会这么干,这种作死的行为咱可以不予理会。接着才是一个比较严重的问题,由于网络原因造成不同步的情况。考虑到这种情况,我们的数据请求就需要像TCP一样进行三步握手确认。当客户端请求一个数据时,服务器找到这个数据,并传输给客户端。客户端在做完这个数据缓存之后再向服务器反馈,服务器在收到反馈后才在对应的清单上记录,这样才可以保证不落下任何数据。也许又有人觉得这样提高了传输成本,其实我觉得这个过程并没有太大影响,因为数据一旦请求完成,就不会再次发起。
  服务器还必须为每个客户端添加一个唯一的标识符来识别他们,最容易的办法就是直接开启Session。而Session本身又可以储存数据,那么客户端的数据清单也可以直接在Sesssion中储存。当然,对于不同的编程语言可能对Session使用了不同的实现方式,大多数情况是直接作为文件储存。这对于NTFS文件系统来说基本没问题,但我还是建议使用数据库来做。
  大家最担心的也许是这么实现的成本吧?别忘了我们的初衷。我们是为了解决带宽占用问题才这么做的,带宽就是服务器最大的瓶颈,然后才是内存和运算能力,最廉价的就是硬盘空间。现在我们用硬盘来换取带宽,这不是非常划算吗?而且这么做节约的还不仅是服务器的带宽,对客户端的带宽和浏览器也同时节省了。
  暂时没想到其它问题了,等过段时间把它实现出来试试看再说吧~
网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^