这一年，因为网盘踩的坑

业务系统使用网盘一年，大坑小坑不断，近期系统逐步稳定，可以总结一下，供分享。业务系统使用NFS和GlustFS，本文不对这两种网盘进行比较说明。主要说明遇到问题如何解决。

1、NFS的不同主机的同步问题

问题描述：使用NFS共享规则数据，使用mmap实现数据的同步。在使用时发现数据不同步，例如创建方写了一个新版本号。同一主机读到版本是新版本号。其他主机可能旧的版本。

问题分析：怀疑是不同主机的同步问题，在显示调用msync问题仍然存在。尝试利用fwrite/fclose方式直接触发同步，也无法在业务场景正常。由于后续项目使用GFS网盘，该问题没有继续研究，但场景已经存在风险。

2、使用GFS网盘时，存在记录丢失问题

问题描述：业务系统中存在大量，上游环节生成文件，移到下游环节的扫描目录，分环节处理。可能存在处理记录是和实际记录不服。

问题分析：产生问题原因有两点：1 GFS的rename是cp操作，不单单指向改变。2 GFS的rename是异步操作，可能系统调用返回，但是文件还没有移走。

解决思路：采用文件大小或者记录数校验是个稳妥方法。简单处理方式，在每次扫描了一批文件后，sleep 几秒再处理。这个时间和文件大小以及网盘主机的性能相关。在测试环境，25M文件3秒以上。文件较小时1秒就够了。

3、GFS网盘，多进程同写一个文件问题

传统模式，业务进程写文件在本地盘，不会重名；容器时代，大家输出在网盘，文件重名，写入的就是同一个文件。这种情况，写入的记录一般是正常的。但是如果某一个进程rename，可能导致记录不完整，甚至乱码。

解决方法：文件名可以包含容器信息或者一个统一的序列。

4、GFS网盘，rename失败

问题描述：系统上线，每天有10+的rename失败问题，导致文件处理重复，带来很大困惑。

问题分析：可能作为nfs 有些操作有时候就会失败 我们应用要做好对这种情况的处理

http://man7.org/linux/man-pages/man2/rename.2.html 

BUGS       

      On NFS filesystems, you can not assume that if the operation failed,

      the file was not renamed.  If the server does the rename operation

      and then crashes, the retransmitted RPC which will be processed when

      the server is up again causes a failure.  The application is expected

      to deal with this.  See link(2) for a similar problem.

在NFS上调用rename的时候，有可能rename返回失败，但是实际实际上执行成功了，也有可能真失败了。rename调用者应该做好这种准备。

解决方案：如果rename失败尝试三次，才作为失败。可以基本解决失败的问题。

5、网络丢包会影响很大

网盘读写也都是基于网络的性能。如果网络丢包严重，可能导致性能问题。某台主机因为8k的包ping时，丢包率30%，使得该容器性能急剧下降。使用云盘，网络状况必须关注。