背景

前端技术 使用 svg.js 及全家桶的组件实现 svg 绘图的 web 软件。

MySql8

词语定义

图纸：在页面上绘制的内容整体整体叫做图纸，业务上图纸是具有重要业务意义的概念。

对象：图纸上的业务元素的最小概念。

难点-技术背景

当时遇到一个一直困扰我们的问题：

        由于我们实现的保存和更新时，都是将整张图纸内容都发送给服务器，在页面上通过 svg 绘图后的内容过大时，导致向后端发送图纸内容即便压缩后也有至少3~10M 左右不等。

        其次，由于在图纸上更新对象（添加、修改、删除）时，除了更新图纸内容外，还需要额外发送对象相关信息，在实现上，两个请求是异步的。

        同时，图纸内容的存储形式是压缩后的字符串内容，数据库类型是 longtext。

问题是：

        后端图纸内容保存或更新的时间过长，期间如果出现其他操作（添加、修改、删除对象）时，可能带来数据不一致，即图纸内容和图纸内对象的相关信息不一致。

做出努力后的现状：

1. 将数据库中的图纸内容的字段（longtext 类型）从图纸表中抽离出来，只剩下主键和内容两个字段。
2. 前端加上保存和更新的时间触发频率，如果在指定时间内频繁触发更新或保存，那么只触发一次。
3. 前端加上操作限制，在更新图纸时，如果 按 F5 刷新页面属于违规操作。
4. 网络传输可以通过带宽来解决，解决的优先级不再很高（服务的后端问题更加凸显）。

        

偶然而得的解决方案

        虽然因为某些原因无法实施，但还是记录下来吧。

        方案一（折中，且稳妥）

首先，图纸内容不再用 数据库存储，改为用文件形式，每张图纸一个目录。每次保存或更新时，永远都生成一份文件放入对应的目录，显然文件名必须带有时间序号。

其次，在回显图纸内容（即加载图纸）时，永远去最大的序号的图纸即可。

最后，读取图纸内容必然存在 io 耗时问题，这个我们可以对最新的图纸加上缓存（可以是直接内存Map或干脆 redis）即可。

要求：保存、更新、下载图纸内容时只管保存到缓存即可，数据库的更新不再成为瓶颈，可以定期更新或延时更新数据库。

好处：暂时没想到会带来其他问题。

        方案二（完美，但改动大）

在方案一的基础上，将两个请求彻底何为一个。即将图纸内容更新 和 对象信息的更新合并后一个请求。

思路：我们没有必要将对象信息单独传送，可以将对象信息和图纸放在一起，建议放在 svg 签的内部的自定义标签，比如<pid-data></pid-data>,只要不显示在页面上就行了。

如此一来，两个信息合并后，我们就都认为是图纸数据，便可以一起压缩传输到服务器。