Web 技术研究所

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

重提「前后端数据同步的实现设想」

  在 2013 年冬天某一个寒冷的夜里,我颤抖着写了篇「前后端数据同步的实现设想」,不久之后就在自己的这个博客上尝试了这种实现方式。这个设想在实现和使用上确实没问题,可是当时确实忽略了一些因素。最近突然神奇地发现这个设想将来似乎会有更大发展空间。

概念、逻辑与坑

  这个设想的基本理念是让后端维护用户已加载的数据清单,并在后续通信中不再传输清单已记录的数据。理论上这样是可以完全解决数据传输的冗余问题的。但我当时在实现这个功能时遇到了一些,比如前端请求了一个曾访问过的列表,后端发现清单中前端是已经加载过这份数据的,所以不做任何传输。此时,前端虽然有数据,但无法知道当前请求的列表所对应的到底是哪些数据。于是我在实现是无论清单中是否存在记录都至少会给前端响应一个记录的 id 以便前端将列表和自己拥有的数据对应上。

我的实现

  只谈概念的话那确实也太流氓了。举个实际的例子,就拿现在这个博客的文章列表来说吧,用户首次访问时需要请求一个文章列表(可以看到的部分)。后端处理请求时发现是新用户,所以从数据库中查询了新的数据响应给前端。前端程序拿到这份数据后除了用于页面展示外,还在 IndexedDB 中逐条储存了下来,并且在 IndexedDB 储存完成后把这些储存成功的记录 id 反馈给后端。后端收到这个反馈后将这些反馈的 id 储存下来,作为当前用户的「所持数据清单」。当用户再次访问主页或其他需要加载文章列表的页面时,同样会给服务器发起请求。后端收到请求后从数据库查询出对应的数据,但并不是直接将这个数据直接传输给前端,而是先比对用户的「所持数据清单」,让客户端已经做了缓存的数据只传输一个 id,只有新增或修改的记录做传输(删除也可以实现,只是有点麻烦,我暂时没有实现)。

硬件性能与数据量的纠结

  这个设想是一年前实现的,它已经在我的博客上正常运作了一年,在此期间也没有挂过(偶尔访问不了是因为被墙)。但仅仅是我自己的程序上可以正常运作并不能说明什么问题,毕竟我这里的访问量太低了。其实对于这个做法我一直在担心一个问题,访问量大了会如何?因为当时写那篇文章的时候没有考虑数据库查询的性能,没有考虑磁盘 IO 的性能问题,访问量大的话或许真会硬件资源不足(我没做过测试,目前也没条件测试)。理论上,这个程序会对每一个新访客在数据库中创建一个「所持数据清单」。就我的数据而言,每个访客平均 28 条文章记录(还有其它记录,这里只讨论这个),幸亏我的访问量低,要不然记录条数的增加会非常可怕。

大数据的契机与重新审视

  当时我觉得这个数据量太大,要是用于产品级的项目中估计不靠谱,所以就只是把这个程序丢着,没再继续纠结了。今天突然扯回这个问题是因为最近觉得所有事情仿佛都可以得到解决。契机是前几天突然有同事让我给产品添加埋点记录用户行为作为大数据分析用。我楞了一下,心想这数据量真的没问题么,会不会把数据库搞挂啊?后来一拍脑袋就想通了,他们组不就叫「大数据」嘛,数据量大又何妨!于是突然想到了去年的那篇「前后端数据同步的实现设想」,感觉自己重新燃起来了。既然我们的服务器上有现成的「所持数据清单」,而且这个清单是有其它用处的,那么我的设想用于产品级的项目中也完全没问题了嘛!

结语

  其实目前我依然处于一个混沌的状态,不知道这个想法到底在产品级的项目中是否可用,或者是否有必要?它可以带来多少性能提升,节省多少流量?各种问题摆在眼前。不过无论这个设想的可用性如何,将「大数据」与「Web 缓存」接合起来的魔法也许真的可以解决一些曾经无法解决的问题。

网名:
54.144.24.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^