支撑亿级文件规模：途虎养车 JuiceFS + Ceph RADOS 存储优化实践

在途虎养车，我们每天面临海量车辆维修记录、图片、视频等文件数据的存储挑战。如何高效、稳定地支撑亿级文件规模，同时兼顾成本和性能，是我们技术团队的核心课题。本文将用通俗语言，结合代码示例，分享我们基于 JuiceFS + Ceph RADOS 的存储优化实践。## 为什么选择 JuiceFS + Ceph RADOS？传统文件存储（如 NFS）在文件数超过千万级时，元数据操作会成为瓶颈。JuiceFS 是一个面向云原生的高性能 POSIX 文件系统，它将数据与元数据分离：元数据存储在 Redis 或 SQL 数据库中，数据则存储在对象存储（如 S3、Ceph RADOS）中。Ceph RADOS 作为分布式对象存储，具备高扩展性、自动故障恢复和低成本优势。核心优势：- 元数据性能：JuiceFS 的元数据操作（如 ls、stat）在亿级文件下仍能保持毫秒级响应。- 数据可靠性：Ceph RADOS 通过副本或纠删码保证数据不丢失。- 弹性扩展：支持动态添加节点，无需停机。## 架构概览我们的生产环境采用以下架构：- 元数据存储：Redis 集群（主从 + Sentinel 高可用）。- 数据存储：Ceph RADOS 集群（3 副本，SSD + HDD 分层存储）。- 文件系统挂载：通过 JuiceFS 客户端挂载到所有计算节点。## 关键优化实践### 1. 元数据缓存与分片JuiceFS 默认将目录树缓存到本地磁盘。对于亿级文件，我们调整了缓存策略：- 开启 --cache-size 参数，限制本地缓存大小，避免占用过多磁盘。- 使用 Redis Cluster 自动分片，避免单点瓶颈。### 2. Ceph RADOS 性能调优Ceph 默认配置可能不适合海量小文件。我们做了以下优化：- PG 数调整：根据集群规模设置合理的 Placement Group 数（公式：PG数 = (OSD数 * 100) / 副本数）。- 客户端缓存：通过 ceph.conf 开启 client cache size 减少网络请求。### 3. 文件大小自适应处理针对小文件（如车辆图片），我们使用 JuiceFS 的 Truncate + Append 模式减少写放大。代码示例：pythonimport osimport fcntlimport time# 创建 1KB 小文件，模拟车辆图片写入def write_small_file(file_path, data): # 使用 O_DIRECT 跳过缓存，减少内存占用 fd = os.open(file_path, os.O_CREAT | os.O_WRONLY | os.O_DIRECT) try: # 锁文件防止并发写冲突 fcntl.flock(fd, fcntl.LOCK_EX) os.write(fd, data) os.fsync(fd) # 立即刷入 Ceph finally: fcntl.flock(fd, fcntl.LOCK_UN) os.close(fd)# 批量写入 100 万个 1KB 文件start = time.time()for i in range(1_000_000): data = b"x" * 1024 # 1KB write_small_file(f"/mnt/jfs/images/vehicle_{i}.jpg", data)print(f"写入 100 万小文件耗时：{time.time() - start:.2f}秒")## 性能测试与对比我们对比了传统 NFS 和优化后的 JuiceFS + Ceph 方案。测试环境：3 节点 Ceph 集群（每节点 8 核 CPU、32GB 内存、4 块 SSD）。### 测试 1：亿级文件 ls 速度bash# 在 JuiceFS 挂载点执行time ls /mnt/jfs/images/ | wc -l# 输出：100000000 个文件，耗时 0.8 秒# 在 NFS 挂载点执行time ls /nfs/images/ | wc -l# 输出：100000000 个文件，耗时 45 秒（因元数据遍历）### 测试 2：并发读写性能我们编写了一个 Python 脚本模拟高并发场景：pythonimport threadingimport randomimport string# 并发写入 1000 个 10MB 文件def write_large_file(file_id): file_path = f"/mnt/jfs/large_files/data_{file_id}.bin" data = ''.join(random.choices(string.ascii_letters, k=10*1024*1024)).encode() with open(file_path, 'wb') as f: f.write(data)# 启动 100 个线程threads = []for i in range(100): t = threading.Thread(target=write_large_file, args=(i,)) threads.append(t) t.start()for t in threads: t.join()print("所有大文件写入完成")结果：- JuiceFS + Ceph：总耗时 12 秒（平均 120ms/文件）- NFS：总耗时 58 秒（平均 580ms/文件）## 遇到的大坑与解决方案### 坑 1：Redis 内存爆炸现象：文件数超过 5 亿时，Redis 内存使用达 200GB，导致 OOM。解决： 启用 JuiceFS 的 --compact 选项，定期压缩元数据，减少内存占用。同时将 Redis 升级为 64GB 实例。### 坑 2：Ceph 写入延迟抖动现象：高峰期写入延迟从 1ms 飙升至 500ms。解决： 为 Ceph 配置 QOS 限速，隔离高 IO 业务。代码中增加指数退避重试：pythonimport timeimport randomdef write_with_retry(fd, data, max_retries=5): for attempt in range(max_retries): try: os.write(fd, data) os.fsync(fd) return except OSError as e: if e.errno == 5: # IO 错误 wait = 2 ** attempt + random.uniform(0, 0.5) time.sleep(wait) else: raise raise Exception("写入失败，重试耗尽")## 总结通过 JuiceFS + Ceph RADOS 的组合，我们成功支撑了亿级文件规模，同时将元数据操作延迟降低 98%，写入性能提升 80%。核心经验：1. 元数据分离：JuiceFS 的元数据与数据分离设计是亿级文件的关键。2. 调优无止境：从 Redis 缓存到 Ceph PG 数，每个细节都可能影响整体性能。3. 容错设计：指数退避重试、文件锁等机制让系统更健壮。如果你的业务也面临海量小文件或高并发存储挑战，不妨试试 JuiceFS + Ceph 这个组合。记住：没有银弹，只有最适合自己场景的方案。