开心一刻
正睡着觉,然后来了个电话
对方说:你好,方便面是吗
我愣了一下,以为是恶作剧
回了句:我不是,我是火腿肠!
就挂了电话
又躺了好一会,忽然琢磨过来......
不对呀,她好像说的是:你好,方便面试吗?

前提准备
项目中有这么一块业务

1、 脚本同步 这一环,是运维同事通过脚本实现的,所以我没去关注
2、 读取文件并上传 这一环,是我实现的,稳定运行了很长一段时间了,一直没出问题
中文乱码
直到有一天, 生产环境 出现了异常信息: /data/userData/Rsync 下不存在文件:测试文件.txt
提示很明显,在目录 /data/userData/Rsync 下,没有找到文件 测试文件.txt
然后联系运维,让运维去看 本系统 的目录: /data/userData/Rsync 下,文件 测试文件.txt 是否存在
运维的反馈是文件存在,还发了截图

并且把文件复制给我了
然后我将这个文件复制到 测试环境 的 /data/userData/Rsync 目录下, 测试环境 能正常找到文件 测试环境.txt
那问题出在哪?

问题排查
后面与同个运维同事沟通了下,了解了整个完整流程的细节:

其中 CentOS 7 作为 NFS 服务器 ,其系统编码是 UTF-8

Win 2012 作为 NFS 客户端 ,其系统编码是 GBK (chcp 值 936 表示 GBK)

我在怀疑是不是 NFS 的问题?
怎么验证了?
其实最简单的办法就是看一眼 CentOS 7 目录 /data/userData/Rsync 下是不是有中文名乱码文件即可
奈何我认为我说清楚了,运维同事也认为他理解了

结果南辕北辙,我想看的是 CentOS 7 的目录 /data/userData/Rsync ,运维给我看的却是 Win 2012 下的挂载目录 L:
关键是当时我没发现他给我的截图其实不是我想看的!
然后我就开始了我的线上环境模拟之旅
NFS 服务端
CentOS 7 上搭建 NFS 服务器非常简单
1、安装 NFS ,执行 yum install -y nfs-utils 即可
2、对客户端 IP 进行授权
编辑 /etc/exports ,进行授权配置,例如

/data/userData/Rsync/ 表示要共享出去的目录,不存在则需要先创建: mkdir -p /data/userData/Rsync
10.5.108.221 表示客户端 IP 地址,说明共享给谁
(rw,sync,no_root_squash) 表示授权列表, rw 表示客户端可以读写, sync 表示自动同步, no_root_squash 是什么含义,你们自己去查
涉及到目录的读写,需要对 /data/userData/Rsync/ 配置合适的读写权限,方便演示就简单点: chmod 777 /data/userData/Rsync/
编辑好之后,使配置生效,执行命令: exportfs -rv
3、启动 NFS : systemctl start nfs-server
开机启动: systemctl enable nfs-server
4、防火墙放行
为了演示方便,直接关闭防火墙: systemctl stop firewalld
NFS 客户端
WIN 2012 作为客户端,配置起来也很简单
1、安装 NFS 客户端
控制面板 -> 程序 -> 启用或关闭 Windows 功能

添加角色与功能 ,直接连续下一步,直到 服务器角色

如果在 WIN 2012 上搭建 NFS 服务器,则上面三个框住的需要勾选上,然后进行 安装
我们目前是搭建客户端,这个地方可以不勾,下一步,来到 功能

勾选上 NFS 客户端 ,然后进行安装即可
2、防火墙放行,为了演示方便,直接关闭防火墙
3、目录挂载
直接在 cmd 中执行: mount 10.5.108.225:/data/userData/Rsync L:
不出意外的话,挂载成功

此时, 我的电脑 会出现一个网络盘

正常来讲,不会有红叉;不影响效果,先不纠结
同步
简单点模拟,直接在 win 2012 上,往挂载盘(网络盘)写文件,文件名是: 测试文件.txt

在 win 2012 的挂载目录 L: 看,中文没乱码,简直太正常了!
但是,我们去 CentOS 7 的目录 /data/userData/Rsync/ 看下

哦豁,换了个马甲,还真不认识了!
程序去找 测试文件.txt ,怎么找得到嘛

乱码原因
这个时候基本能断定问题出在 NFS ,直接 google 下关键字: Window 2012 NFS 中文乱码 就能找到答案
根因就是:windows 内置的 nfs 支持的编码非常有限,不支持 utf-8

问题解决
去掉中文
既然中文有问题,那就干掉中文
和上游系统协商了下,文件名改成英文,中文乱码自然就不存在了
有小伙伴可能会有疑问:之前没有中文乱码问题?
其实你们心里应该有答案了,没错,就如你们所想:这块业务,之前一直没出现中文名的文件!
升级 window 系统
win10 可以开启 Beta 版本 ,来支持 UTF-8

具体可参考:一个小设置,让Win10 NFS正常显示中文UTF-8
注意看评论区,坑很多,不推荐这种方式
至于 Windows 系统的其他版本是否支持该配置,大家结合自己的系统去查阅
第三方 NFS 客户端
ms-nfs41-client,人家搭建步骤写的很清楚了

换共享方案
Samba 就是其中之一,大家可以去查阅并实现
总结
1、 Windows 自带的 NFS 支持的编码非常有限,竟连 UTF-8 都不支持,会导致中文乱码问题

2、沟通的时候,一定要清楚的表达自己的意图,要保证人家接收到的信息就是你要表达的信息