背景
：两个业务流程基于共享文件系统进行交互，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
版权声明：本文为russle原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。