Ceph数据路径总览
# Ceph数据路径总览
如果说 Ceph架构设计 解决的是“Ceph 有哪些组件、它们怎么分工”，那这篇更关注另一件事：
一次读写请求进入 Ceph 之后，数据究竟沿着什么路径流动？
这篇文章的目标，是把 客户端 -> CRUSH/PG -> Primary OSD -> 副本 OSD -> BlueStore/底层设备 这条主线先串起来，并把它和你前面已经整理好的 Page Cache / fsync / 块层 / blk-mq / NVMe 骨架接上。
# 1. 为什么 Ceph 的数据路径值得单独看
Ceph 的数据路径和普通单机文件 I/O 最大的不同在于：
- 它不是“应用直接写本机文件系统”
- 它先经过对象映射和副本放置
- 它要处理主副本协调、一致性确认和恢复逻辑
- 它的底层存储路径又会继续落到 BlueStore、块设备、网络和设备队列
所以 Ceph 的性能和一致性问题，通常不会只停留在某一层，而是会横跨：
- 客户端路径
- 集群映射路径
- OSD 内部处理路径
- 底层设备路径
# 2. 一个最简化的写路径脑图
把 Ceph 写路径先压缩成一句话：
客户端把对象写入请求发给 Primary OSD，Primary OSD 协调副本 OSD 完成复制和提交，再由各 OSD 的存储引擎把数据落到本地设备。
展开后大致是：
- 客户端拿到集群 map
- 客户端根据对象名计算 PG
- 客户端通过 CRUSH 计算 PG 对应的 OSD 集合
- 客户端把请求发给 Primary OSD
- Primary OSD 协调副本 OSD 执行复制和确认
- OSD 把对象数据和元数据交给 BlueStore 一类的后端
- BlueStore 再把数据推进到底层块设备
这里真正值得盯住的，不只是“有没有写进去”，而是：
- 什么时候算副本都收到了
- 什么时候算提交完成
- 什么时候算真正落到稳定存储
# 3. 一个最简化的读路径脑图
读路径通常比写路径短一些，但同样经过映射和定位：
- 客户端根据对象名计算 PG
- 通过 CRUSH 算出目标 OSD 集合
- 一般由 Primary OSD 负责请求处理或协调
- 对应 OSD 从 BlueStore / 底层设备读取对象数据
- 数据返回客户端
如果只是看“功能正确”，这条路径不复杂；但一旦看延迟和抖动，问题就会分散到：
- 对象映射
- 网络往返
- OSD 线程模型
- RocksDB / BlueStore 元数据访问
- 底层块设备和 NVMe 队列
# 4. Ceph 数据路径的几个关键分层
为了后面能继续深挖，我建议把 Ceph 数据路径拆成 5 层看。
# 1. 客户端与集群视图层
这一层关心的是：
- 客户端如何拿到最新的集群状态
- OSD Map、CRUSH Map、PG 映射如何参与路径选择
- 为什么 Ceph 客户端可以直接定位数据，而不需要集中式元数据服务来决定对象放哪
对应笔记：
# 2. Primary OSD 协调层
这一层关心的是：
- 为什么客户端通常先找 Primary OSD
- Primary OSD 如何把请求复制给其他副本 OSD
- 一次写请求的确认边界在哪里
- 一次恢复、重平衡或故障切换会怎么改变路径
这是 Ceph 一致性和尾延迟经常出现问题的地方。
# 3. OSD 内部对象管理层
这一层关心的是：
- 对象到了某个 OSD 之后，怎么找到自己的内部位置
- PG、对象、object metadata 之间如何组织
- BlueStore / Filestore 后端如何管理数据和元数据
对应笔记：
# 4. 存储引擎与本地持久化层
这一层已经开始和你前面整理的底层机制骨架接轨：
- BlueStore 是否使用 Page Cache
- 数据和元数据怎样组织到 RocksDB / block device
- 提交语义和 WAL / DB / main block 之间是什么关系
fsync、写回、块层、设备 flush 在这里各自扮演什么角色
这也是 Ceph 和“普通文件系统写文件”真正分叉的地方。
# 5. 底层设备与高速路径层
这一层关心的是：
- 底层是 HDD、SSD 还是 NVMe
blk-mq、队列深度、中断亲和是否成为瓶颈- 是否存在 BlueStore + RocksDB + 设备多队列之间的耦合问题
到了这里，Ceph 问题就已经不再只是 Ceph 本身的问题，而会直接落到 Linux I/O 栈。
# 5. 为什么这篇能把 Ceph 和底层机制骨架接起来
你前面在 02.IO语义与持久化 和 03.块层与高速路径 里整理的内容，本质上回答的是：
- 单机 I/O 路径如何走
- 缓存和刷盘语义如何理解
- 块层和多队列怎样影响性能
- 高速设备时代软件路径为什么要变
Ceph 这篇总览的作用，就是把这些“单机 I/O 机制”重新挂回分布式对象存储场景。
比如：
- Ceph 的提交语义，会回到 fsync、写回与刷盘语义
- BlueStore 落盘路径，会回到 块层与I-O调度总览
- NVMe 场景下的 OSD 表现，会回到 blk-mq多队列模型 和 高速存储路径总览
也就是说，Ceph 数据路径不是独立知识点，而是系统专题和底层机制的连接器。
# 6. 后面最适合继续拆开的专题
如果沿着这篇继续扩，最适合往下长的是：
04.Ceph写请求确认路径12.Ceph读路径与Primary OSD13.BlueStore提交路径14.PG状态变化如何影响数据路径15.Ceph尾延迟从哪几层来
第一篇承接文章：