先说说元数据到底存什么。文件路径、分块信息、副本位置、访问权限这些是最基本的。但实际生产环境中远不止这些：数据的冷热状态、压缩标志、校验和、生命周期标签，甚至用户自定义的扩展属性，都是元数据的一部分。我们团队就吃过亏，早期设计时只考虑了基础字段，后来业务方想要实现智能分层存储，不得不对元数据表做了两次大的结构调整，那个迁移过程简直噩梦。

存储架构怎么选？这是首先要面对的问题。集中式虽然简单，但单点瓶颈太明显。我们最开始用的MySQL，当文件数量突破五千万时，那查询延迟简直没法看。后来转到etcd，看中的就是它的强一致性和watch机制，特别适合做服务发现和配置管理。但etcd的存储容量有限，而且对范围查询支持不够友好，在大规模文件列表场景下还是力不从心。

现在比较主流的是分层架构：用Redis集群做缓存，扛住高频访问；用MySQL或PostgreSQL做持久化存储，保证可靠性；再加上ZooKeeper或etcd处理集群状态和锁服务。我们现在的方案是三层：本地缓存->分布式缓存->持久化存储，命中率能做到95%以上，大大降低了后端压力。

说到一致性模型，这就要做取舍了。强一致性确实让人安心，但代价太高。我们曾经在跨地域部署时坚持强一致性，结果写延迟高得业务方直跳脚。后来想明白了，大多数业务场景下，最终一致性就足够了。比如文件列表的更新，晚几秒钟看到新文件，用户基本感知不到。但像文件锁这种操作，就必须强一致，不然多个客户端同时写同一个文件，数据就乱了。

缓存策略这块学问也不小。全量缓存不现实，我们吃过内存溢出的亏。后来改用的方案是LRU+主动预热，热点数据常驻内存，非热点数据按需加载。还有个细节，缓存不只是读缓存，写缓存也很重要。我们设计了写缓冲队列，对小文件写入先合并再落盘，元数据批量更新，性能提升了三倍不止。

分区策略直接影响扩展性。按文件路径哈希是最简单的，但有个问题：同一个目录下的文件可能被散列到不同节点，做目录遍历时要跨节点查询，效率很低。我们后来改进了方案，对目录树的上层按路径哈希，确保同一目录下的子项在同一个分区；对文件层按inode哈希，这样既保证了负载均衡，又优化了目录操作。

高可用是必须的。主从模式、多主模式、无中心模式我们都实践过。主从模式部署简单，但主节点挂了需要秒级切换，这个故障转移过程如果没处理好，可能导致元数据不一致。多主模式写冲突解决起来很头疼，需要根据业务场景设计合适的冲突解决策略。我们现在用的是Raft共识算法，虽然写性能有些损失，但保证了数据的强一致性，运维起来也省心。

监控报警不能少。元数据服务的QPS、延迟、错误率这些基础指标要实时监控，更重要的是业务层面的指标：比如目录遍历耗时、锁等待时间、缓存命中率等。我们设了多层报警：基础资源层、服务状态层、业务指标层，问题出现时能快速定位到具体环节。

性能优化是个持续的过程。我们曾经遇到元数据查询突然变慢，排查了半天发现是某个业务频繁列取超深层级目录。后来加了查询深度限制和超时机制，并对深度遍历做了特殊优化。还有一次是缓存穿透，随机生成的不存在文件路径把数据库打挂，我们用了布隆过滤器过滤非法查询，解决了这个问题。

最后说说运维中的坑。元数据备份不能停服务，我们用的快照+binlog的方式，全量快照每周一次，增量binlog实时同步到备库。版本升级要向前兼容，新增字段尽量设为可选，删除字段要分两步：先标记废弃，等所有服务都不用了再真正删除。

元数据管理就像分布式存储系统的神经系统，虽然后端用户看不见，但它决定了整个系统的稳定性和性能。没有一劳永逸的方案，只有适合当前业务场景的权衡。随着存储规模的增长，新的挑战又会不断出现，这就需要我们持续优化迭代。毕竟，在分布式系统里，唯一不变的就是变化本身。