cxljs

JuiceFS 设计和实现

Fri, 01 Aug 2025 19:06:59 +0800

分布式文件系统的发展

Google GFS 的发表是分布式文件系统发展的里程碑，Meta + Data 的架构影响了后来的分布式系统设计。随后的 HDFS 是大数据时代最重要的存储系统之一，现在分布式文件系统最流行的2种接口协议是 POSIX 和 HDFS。

随着云原生和对象存储的发展，数据系统的设计趋势是把数据放到对象存储，比如 autoMQ 把 Kafka 的数据放到对象存储，AWS 刚发布的基于对象存储的向量数据库。

现在 LLM 时代对分布式文件系统的需求也有变化，相比大数据时代，AI 训练存储的更多是小文件，所以文件系统的元数据更多。LLM 时代的分布式文件系统还有一个热点是 GPU Direct FS。

分布式文件系统的挑战

文件系统的元数据组成一个 DAG，分布式文件系统的挑战之一在于：

怎么存储这个 DAG?
怎么高并发读写这个 DAG?

常见思路：

整个 DAG 存储在单个节点（主备模式），缺点是单节点吞吐量和容量有限，可能会成为系统瓶颈
设计一个可扩展的存储 DAG 的系统，把 DAG 划分存储到多个节点，目前有相关的论文，但是没有这样做的开源项目(CubeFS 好像是?)
转化成 KV/Table 数据模型存储在 KV/RDB
不采用 Meta + Data 架构，把 Meta 和 Data 混合存储（10年前有这样做的系统，现在应该没有）

JuiceFS

JuiceFS 是经典的 client-meta-data 架构，采用第3种思路存储元数据，支持 TiKV/MySQL/Etcd/Redis 等多个系统作为 Meta Service，数据放在对象存储，JuiceFS 本身是一个 client 层。

LevelDB #1 WAL

Sun, 09 Mar 2025 17:36:52 +0800

LevelDB Overview

lsm-tree 设计思路：

写日志，从而把写操作变成磁盘顺序写
写先存储在内存，再批量写入新文件，保证每个文件的数据有序，方便合并，删除失效数据
分层合并策略

LevelDB 是 BigTable 的存储引擎，是最早流行的使用 lsm-tree 的存储引擎。

LevelDB 架构图(在网上广为流传，应该是出自 MS 的一篇文章):

LevelDB 系列文章的顺序：

WAL
MemTable
SSTables 格式，压缩、合并
其他工程优化：Bloom Filter, Block Cache, Lock, Env
MVCC 并发控制
完整读写流程

WAL

为了保证 MemTable 的数据不丢失，在写 MemTable 前会先写 WAL，重启时，重放 WAL 恢复 MemTable。正常情况一个 MemTable 对应一个 WAL，WAL 在 MemTable 成功落盘后删除。

所以 WAL 应该有2个接口：AddRecord() 和 Replay()。

LevelDB’s WAL 分成 log::Writer 和 log::Reader 2个数据结构。

Redis 主流程实现

Sat, 13 Jul 2024 15:28:13 +0800

Redis 是一个 in-memory data structures server, 在互联网应用广泛，常见的使用场景:

作为其他系统的缓存，减少其他系统的负载，相比于本地缓存，Redis 可以让多个实例共享缓存的数据
对延时要求高的场景

在高性能的前提下，我觉得 Redis 的接口设计是它能从 memcached 等系统中脱颖而出的关键原因，Redis 支持 hash table, set, sorted set, vector set 等数据结构，对用户更加友好，还支持 timeseries, pub/sub, stream 等，使它有更多的使用场景。

类似 S3, Redis API 被称为 Redis 协议，很多 KV 系统都支持 Redis 协议，比如阿里的 Tair。

Redis 单机的整体架构主要分4个部分：网络框架、线程模型、内存数据结构、持久化。

这篇文章讲 Redis 主流程的实现。

Util

lzf[.h/_c.c]实现 lzf 压缩算法，RDB 持久化时默认使用 lzf 压缩 key&value.

zmalloc.[h/c]是 malloc wrapper, 记录使用的堆内存量。

sds.[h/c]实现变长字符串类型，是内部最常用的数据结构，很多 buffer 的类型是 sds，分配内存的策略: