背景
前端技术 使用 svg.js 及全家桶的组件实现 svg 绘图的 web 软件。
MySql8
词语定义
图纸:在页面上绘制的内容整体整体叫做图纸,业务上图纸是具有重要业务意义的概念。
对象:图纸上的业务元素的最小概念。
难点-技术背景
当时遇到一个一直困扰我们的问题:
由于我们实现的保存和更新时,都是将整张图纸内容都发送给服务器,在页面上通过 svg 绘图后的内容过大时,导致向后端发送图纸内容即便压缩后也有至少3~10M 左右不等。
其次,由于在图纸上更新对象(添加、修改、删除)时,除了更新图纸内容外,还需要额外发送对象相关信息,在实现上,两个请求是异步的。
同时,图纸内容的存储形式是压缩后的字符串内容,数据库类型是 longtext。
问题是:
后端图纸内容保存或更新的时间过长,期间如果出现其他操作(添加、修改、删除对象)时,可能带来数据不一致,即图纸内容和图纸内对象的相关信息不一致。
做出努力后的现状:
- 将数据库中的图纸内容的字段(longtext 类型)从图纸表中抽离出来,只剩下主键和内容两个字段。
- 前端加上保存和更新的时间触发频率,如果在指定时间内频繁触发更新或保存,那么只触发一次。
- 前端加上操作限制,在更新图纸时,如果 按 F5 刷新页面属于违规操作。
- 网络传输可以通过带宽来解决,解决的优先级不再很高(服务的后端问题更加凸显)。
偶然而得的解决方案
虽然因为某些原因无法实施,但还是记录下来吧。
方案一(折中,且稳妥)
首先,图纸内容不再用 数据库存储,改为用文件形式,每张图纸一个目录。每次保存或更新时,永远都生成一份文件放入对应的目录,显然文件名必须带有时间序号。
其次,在回显图纸内容(即加载图纸)时,永远去最大的序号的图纸即可。
最后,读取图纸内容必然存在 io 耗时问题,这个我们可以对最新的图纸加上缓存(可以是直接内存Map或干脆 redis)即可。
要求:保存、更新、下载图纸内容时只管保存到缓存即可,数据库的更新不再成为瓶颈,可以定期更新或延时更新数据库。
好处:暂时没想到会带来其他问题。
方案二(完美,但改动大)
在方案一的基础上,将两个请求彻底何为一个。即将图纸内容更新 和 对象信息的更新合并后一个请求。
思路:我们没有必要将对象信息单独传送,可以将对象信息和图纸放在一起,建议放在 svg 签的内部的自定义标签,比如<pid-data></pid-data>,只要不显示在页面上就行了。
如此一来,两个信息合并后,我们就都认为是图纸数据,便可以一起压缩传输到服务器。