在共享文件系统中，A流程使用Python的with open as方式读写文件，然后立即通知B流程。偶尔出现B读取到不完整或为空的文件。问题在于A的文件改动可能未被立刻写入磁盘。解决方案是在关闭文件后调用os.sync()或os.fsync()来强制写入。os.sync()影响所有文件改动，os.fsync()仅影响特定文件描述符，性能影响较小。
背景：两个业务流程基于共享文件系统进行交互，A流程改动文件后，保存文件，通知B流程开始（通过业务编排系统或者直接调用B的接口进行通知）。 B流程开始读取该文件进行处理，偶发的B发现文件不完整，或者文件大小为0。
A 和B 是运行不同pod中的程序。 都挂在的该共享存储的盘， A写入后，B读取处理，再向下流转。
分析：问题是偶发的， 通过长期观察日志，有时发生问题的是A新写的文件相对较大，或者此时有A有好多写文件的操作，并且A刚close文件，立刻通知B开始操作。基本B读取文件是在A close文件后的不到1毫秒开始的。
经过确认A的文件确定调用close的方法的，A流程使用python开发，通过 with open as 方式读写文件的。
查看linux文件的读写过程，发现flush只能确保程序对文件的改动会进入的所在os的page cache中，并不会一定立刻写入到磁盘中，具体何时写入到磁盘中取决于操作系统。
而我们使用的共享文件系统，A流程虽然调用close，但是文件改动不应此时就save to disk，所以B流程该文件时候，可能发生读取的文件不完整的。 A和B位于不同机器，没法共享page cache。
具体解决办法：所有通过 with open 或者write方法写入文件的地方，在后面统一调用os.sync 或者os.fsync()
with 
最低0.47元/天 解锁文章
扫一扫
1067
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
