文档缓存机制
Filez文档中台可以支持业务系统中文件的在线预览和在线编辑。文件存储在业务系统中,每次在线预览或者在线编辑时,Filez文档中台都需要从业务系统获取文件。每次从三方取到文件后,会把文件转化为内部的数据结构来完成文档的预览或者编辑。这些存储在文档中台服务端的数据结构可以视为文档的某种类型缓存。如果下次再预览或者编辑该文件,文档中台会直接使用缓存数据,加快预览和编辑打开性能。
文档中台在线编辑和预览时,如何决定是否使用内部数据(缓存)?
文档中台根据文件的两个属性来判断。一个是文件的docId。也就是请求在线编辑或者预览时,请求url中的docId。一个是文件在业务系统的最后修改时间。也就是在线编辑或者预览时,业务系统传给文档中台的meta 信息中的modified_at。如果一个文件在线编辑或者预览时,传给中台的docId + modified_at对应的数据在中台中有缓存,则中台会用相关的缓存。
有清除缓存的机制吗?
对于仅在线预览的文件,中台服务端会定期删除这些内部数据。对于在线编辑的文件,由于在线编辑时会产生一些线上独有的数据(协作记录,按人授权等),在线编辑文件相关的内部数据不会自动清除。
meta API 返回的modified_at 域非常重要,返回结果不对,不仅会带来整个系统效率下降,而且会带来奇怪的文件冲突问题。modified_at不仅会出现在meta API的返回json中,还会出现在post content API(文件保存)的返回json中。 modified_at 代表了这个文件在三方系统的最后修改时间。比如用户在10:00 上传了一个文件,其modified_at应该是10:00。用户在10:30上传了该文件的一个新的版本,其modified_at应该是10:30。用户在线编辑,在10:40保存,中台server回传了该文件到三方系统。这时它的modified_at应该是10:40。 中台server每次从三方取到文件后,会把文件转化为内部的数据结构。转化任务是CPU消耗型任务。为了提高效率,如果中台server发现三方系统中的文件自上次在线编辑后,并没有上传新版本。中台server不会从三方系统取文件。 中台server根据三方系统meta API返回的modified_at域判断该文件是否有变化。如果modified_at值和上次返回的值相同,表示文件没变化,不会重复获取文件内容。
- 如果业务系统用数据库来管理文件,可以在数据库中记录这个文件的最后保存时间。如果业务系统直接用文件系统来管理这个文件,可以从文件系统中得到这个文件的最后修改时间。
- 有时候,业务系统为了实现方便,用当前时间的值来作为modified_at域的值。这样做是错误的。不仅会带来整个系统效率下降,而且会带来奇怪的文件冲突问题。 弹文件内容冲突对话框的情况是,用户在线编辑时,发现文件没有保存到三方系统,同时用户/其他用户又在三方系统中上传这个文件的新版本。这时在线编辑的内容没有保存,和新上传的文件有潜在冲突。 但是,如果modified_at值,每次都是当前时间。当页面有改动,用户刷新页面时,这时zOffice编辑器会做异步保存,同时响应编辑请求。保存没有完成用户又进来编辑。如果此时在线编辑从三方得到的meta中modified_at是最新的时间,这对于中台server来说就是三方系统有了新版本。并且当前保存没有完成,中台server就会认为当前有冲突。
- 当用户保存文档时,中台server会发post content API把保存后的文件回传到三方。这个API,三方需要返回的json与meta API返回的json格式一致。这时,要求post content API返回的json中modified_at值和下次编辑时三方返回的meta API中的modified_at值是一致的。例如,用户10:31分保存了文件,三方系统响应post content API返回的modified_at是"2023-03-22T10:31:38.000Z"。过了两分钟10:33,另一个用户在线编辑这个文件(期间,没有用户上传这个文件的新版本),三方系统响应meta API返回的modified_at值也是"2023-03-22T10:31:38.000Z"。只要三方系统实现时,能正确的记录文件的最后修改时间,就能正确的返回modified_at。
- meta API返回的modified_at这个域,它必须是能被JS语言认可的时间格式(比如:符合ISO-8601标准的时间格式)。可以用如下方法来判断。打开Chrome的dev tools,进入Console。输入 var a = new Date("2020-03-25T02:57:38.000Z"); console.log(a); 如下的两种格式("2020-03-25T02:57:38.000Z")与("2020-03-25T02:57:38-08:00")都是正确的,但是("2006-01-02T15:04:05Z07:00"),(2020-3-25T02:57:38.000Z)是错误的。