分布式服务器文件管理，别一上来就堆节点

节点不是越多越好，这话搁在计算上还有人争，搁在文件管理上基本没啥可争的。分布式服务器文件管理最常被搞反的一件事就是：一觉得慢、一觉得乱，第一反应是加机器，加完发现慢的地方一点没变，乱的地方倒更乱了。因为文件系统这玩意儿，卡人的地方通常在元数据、在目录设计、在谁什么时候持着锁这些不显眼的角落，跟节点数量关系没那么大。

分布式服务器文件管理，先问一句谁来写

读多写少和读写混着来，完全是两套设计。要是你的业务就是一堆静态资源往外发，那简单，随便挂几台都能扛。但如果你这儿是几十个进程同时往一个目录里丢小文件，那锁竞争、目录项争用就全上来了，这时候加节点只会让更多人来抢同一把锁。

我一般让人先干一件事：把写入路径画出来。谁写、写到哪个目录、一天大概多少、单个文件多大、写完还改不改。这几条弄清楚了，方案基本自己就浮出来了。反过来，连写入方是谁都没搞清楚就开始选分布式文件系统，选哪个都是碰运气。

目录结构定不下来，扩节点就是扩大混乱

见过太多把文件按日期平铺的，一个月一个目录，一年下来十几万个文件堆在一起，ls 一下终端能卡住。这种时候你就算把后端换成再贵的存储，前端遍历还是那么慢。

目录规划这事儿土是土，但它决定了后面所有的运维成本。我倾向按业务分第一层，按时间分第二层，最多再留一层给状态。超过三层的目录，日常维护的人自己都记不住。还有命名，别用中文加空格加特殊符号，跨机器同步的时候编码一不对就是一堆乱码，排查起来能耗掉半天。

元数据这块省不得

小文件多的场景，压力八成在元数据服务上，不在数据盘上。所以元数据节点尽量不要跟存储节点挤在一台机器里，也别指望它跟业务进程和平共处。条件允许的话给它单独的资源，内存给足一点，元数据基本都吃内存。

有些开源的方案把元数据放在单独一组节点里，配置起来麻烦一点，但后面扩容的时候你会感谢当初那个麻烦。至于具体的参数和部署方式，各家版本差异不小，以服务商或官方文档的说明为准，别照抄别人博客里的配置。

小文件太多，先合并再谈横向扩展

一个目录里塞几十万个几 KB 的文件，这种活儿任何分布式系统看了都头疼。能打包的先打包，能归档的归档，冷数据往对象存储上挪，热数据留在本地盘。这套分层做下来，往往能省掉一半的扩容预算。

顺便说一句，对象存储和文件系统不是一回事。前者按 key 找，没有真正的目录，也没法像本地盘那样随机改中间几个字节；后者能挂载、能 open、能 append。有些人把该用对象存储的图片视频硬塞进共享文件系统，然后抱怨性能不行，这属于用错了工具。

NFS 用着顺手，但它有边界

挂载简单、权限沿用系统那一套，所以很多人第一选择就是它。单机房内网里跑跑确实没问题。但跨机房硬挂就会出事，网络一抖，挂载点卡死，应用的进程跟着一起僵在那儿，重启都不一定解得开。

还有锁。多个节点同时对一个文件加锁写的场景，NFS 的表现要实测，不要凭感觉。真要做跨机房共享，宁可走同步或者走网关，也别让业务直接挂远端目录。

rsync 是兜底，不是方案

rsync 配上定时任务，是最容易上手的同步方式，但它解决的是「过一会儿能对上」，不是「随时都对」。拿它当实时一致性方案用，早晚会碰上数据对不上的时候。inotify 触发同步稍微快点，可事件一丢就静默漏文件，最难查的就是这种。

真要强一致，那得在应用层或者存储层解决，不是靠一个脚本。这块没有便宜的路可走，愿意花多少成本换多少一致性，自己权衡。

写进去了才算数

最后说个容易忽略的点：写入返回成功，但副本还没同步完，这时候机器一重启，文件就没了。所以要验证的不是「写没写」，是「写到几个副本了」。监控里得有这一项，备份也得定期做恢复演练，光看备份任务成功是没意义的，恢复不出来就等于没备份。

回到最开始那句话。分布式服务器文件管理这摊事，先把写入模式、目录层级、元数据位置、恢复演练这四样定下来，再谈加不加节点。顺序反了，加多少台都是在给混乱添砖。