// 功能需求：
// 1. 上传/下载文件
// 2. 多设备自动同步
// 3. 文件版本管理
// 4. 文件夹共享
// 5. 离线编辑，上线后同步

// 非功能需求：
// 1. 数据持久性：99.999999999%（11个9）
// 2. 同步延迟：< 5秒
// 3. DAU：10亿
// 4. 平均文件大小：1MB

// 规模估算：
// DAU：10亿
// 平均每人存储：10GB
// 总存储需求：10亿 × 10GB = 10EB（Exabyte）
// 每日活跃修改文件：10亿 × 5个 = 50亿文件
// 每日同步数据量：50亿 × 1MB = 5PB

// 系统架构：
//
// [Client (Desktop/Mobile)]
//     ↓ (文件变更检测)
// [Sync Engine]
//     ↓
// [Block Service] → [Block Storage (对象存储)]
//     ↓
// [Metadata Service] → [Metadata DB]
//     ↓
// [Notification Service] → [Push 到其他设备]
//
// 核心组件：
// 1. Sync Engine（客户端）：检测文件变更，计算差异，同步
// 2. Block Service：文件分块、去重、存储
// 3. Metadata Service：文件树、权限、版本管理
// 4. Notification Service：通知其他设备同步

// 不分块的问题：
// 文件 A（100MB）修改了 1KB → 需要重新上传整个 100MB
// 浪费带宽和时间

// 分块的优势：
// 文件 A 切分为 25 个 4MB 的块
// 修改了 1KB → 只影响 1 个块
// 只需上传 1 个块（4MB），而不是整个文件（100MB）

// 分块策略：
// 固定大小分块：简单，但文件修改可能导致所有块的 hash 变化
// 可变大小分块（Rabin fingerprint）：根据内容确定分块边界
//   → 文件前面的修改不影响后面的分块
//   → 更智能，但实现复杂

// 文件 v1: [Block1][Block2][Block3]  (hash: h1, h2, h3)
// 文件 v2: [Block1][Block2'][Block3] (hash: h1, h2', h3)
//
// 同步过程：
// 1. 客户端计算 v2 的块 hash：[h1, h2', h3]
// 2. 与服务端对比 v1 的块 hash：[h1, h2, h3]
// 3. 发现 Block2 变化（h2 ≠ h2'）
// 4. 只上传 Block2'（4MB）
// 5. 服务端更新文件元数据
//
// 带宽节省：4MB vs 100MB（96% 节省）

// 去重原理：
// 相同的块只存储一份，多个文件引用同一个块
//
// 示例：
// 用户A上传 file1.docx → 分块为 [B1, B2, B3]
// 用户B上传 file2.docx → 分块为 [B1, B4, B5]
// B1 内容相同（hash 相同）→ 只存储一份
//
// 存储结构：
// blocks 表：
// block_hash | storage_url | ref_count
// hash_1     | s3://b1     | 2         (A和B都引用)
// hash_2     | s3://b2     | 1         (只有A引用)
// hash_4     | s3://b4     | 1         (只有B引用)
//
// file_blocks 表：
// file_id | block_index | block_hash
// file_A  | 0           | hash_1
// file_A  | 1           | hash_2
// file_A  | 2           | hash_3
// file_B  | 0           | hash_1
// file_B  | 1           | hash_4
// file_B  | 2           | hash_5
//
// 去重率：典型文件系统的去重率为 10%-30%
// 对于10EB的总存储，去重可以节省 1-3EB
// 按 $0.023/GB/月计算，节省 $23-69M/月

// 冲突场景：
// 设备A：离线编辑 file.txt → 修改了第1行
// 设备B：离线编辑 file.txt → 修改了第2行
// 设备A上线 → 上传修改 → 服务端版本 v2
// 设备B上线 → 上传修改 → 冲突！
//
// 问题：两个修改基于同一个 v1，但内容不同

// 向量时钟（Vector Clock）：
// 每个设备维护一个向量，记录自己的操作次数
// 向量可以判断两个版本是否有因果关系
//
// 示例：
// 设备A的向量：{A: 3, B: 1}  → A操作了3次，B操作了1次
// 设备B的向量：{A: 2, B: 2}  → A操作了2次，B操作了2次
//
// 比较规则：
// {A:3, B:1} vs {A:2, B:2}
// A: 3 > 2, B: 1 < 2
// 互不大于对方 → 并发修改 → 冲突！
//
// {A:3, B:1} vs {A:2, B:1}
// A: 3 > 2, B: 1 = 1
// 前者大于后者 → 有因果关系 → 不冲突
// {A:3, B:1} 是 {A:2, B:1} 的新版本

// 策略1：Last-Write-Wins（LWW）
// 以最后写入的版本为准
// 优点：简单
// 缺点：可能丢失用户的修改
// 适用：不重要的文件

// 策略2：创建冲突副本
// 保留两个版本，让用户选择
// Dropbox 的做法：创建 "filename (conflict).txt"
// 优点：不丢失数据
// 缺点：需要用户手动处理

// 策略3：操作合并（Operational Transformation）
// Google Docs 的做法
// 将修改表示为操作序列，自动合并无冲突的操作
// 优点：自动合并
// 缺点：实现复杂，只适用于特定格式（如文档）

// 策略4：CRDT（Conflict-free Replicated Data Type）
// 数据结构层面保证无冲突合并
// 适用：特定数据类型（计数器、集合、文本）

-- 文件元数据表
CREATE TABLE files (
    file_id VARCHAR(36) PRIMARY KEY,
    name VARCHAR(255) NOT NULL,
    parent_id VARCHAR(36),
    owner_id BIGINT NOT NULL,
    file_type ENUM('file', 'folder') NOT NULL,
    size_bytes BIGINT DEFAULT 0,
    version INT DEFAULT 1,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
    is_deleted BOOLEAN DEFAULT FALSE,
    INDEX idx_parent (parent_id),
    INDEX idx_owner (owner_id),
    INDEX idx_updated (updated_at)
);

-- 文件块表
CREATE TABLE file_blocks (
    file_id VARCHAR(36),
    version INT,
    block_index INT,
    block_hash VARCHAR(64) NOT NULL,
    block_size INT NOT NULL,
    PRIMARY KEY (file_id, version, block_index),
    INDEX idx_hash (block_hash)
);

-- 块存储表（去重）
CREATE TABLE blocks (
    block_hash VARCHAR(64) PRIMARY KEY,
    storage_url VARCHAR(512) NOT NULL,
    ref_count INT DEFAULT 1,
    size_bytes INT NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

-- 文件版本表
CREATE TABLE file_versions (
    file_id VARCHAR(36),
    version INT,
    size_bytes BIGINT,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    PRIMARY KEY (file_id, version)
);

// 设备A修改了 file.txt：
//
// 1. [Sync Engine A] 检测到文件变更
//    → 计算新文件的块 hash
//    → 对比本地缓存的旧块 hash
//    → 发现 Block2 变化
//
// 2. [Sync Engine A] 上传变化的块
//    → 上传 Block2' 到 Block Service
//    → Block Service 检查 hash 是否已存在
//    → 不存在 → 存储到 S3
//
// 3. [Sync Engine A] 更新元数据
//    → 调用 Metadata Service
//    → 更新 file_blocks 表
//    → 创建新的 file_version
//
// 4. [Notification Service] 通知其他设备
//    → 推送变更事件给设备B
//    → { file_id: "xxx", new_version: 3, changed_blocks: [1] }
//
// 5. [Sync Engine B] 收到通知
//    → 下载变化的块（Block2'）
//    → 替换本地文件的 Block2
//    → 更新本地元数据
//    → 同步完成

// 设备A和B同时离线编辑 file.txt：
//
// 初始状态：file.txt v1, 向量时钟 {A:1, B:1}
//
// 设备A编辑 → v2_A, 向量时钟 {A:2, B:1}
// 设备B编辑 → v2_B, 向量时钟 {A:1, B:2}
//
// 设备A先上线：
// → 上传 v2_A → 服务端接受 → file.txt = v2_A
//
// 设备B后上线：
// → 上传 v2_B
// → 服务端检测到冲突（{A:1,B:2} 和 {A:2,B:1} 并发）
// → 创建冲突副本：
//   - file.txt → v2_A（主版本）
//   - file.txt (A's conflict) → v2_B（冲突副本）
// → 通知用户有冲突需要处理