Ceph / RADOS 存储内核：从 Map 到 BlueStore
内容提要
本文介绍Ceph RADOS内核系列，共18篇，涵盖Map传播、OSD Messenger、CRUSH、PG Peering、BlueStore读写、恢复、EC路径及RBD/CephFS/RGW接入。旨在帮助工程师理解延迟与失败点，提供阅读路径和选型建议，对比MinIO、云块和SPDK，明确何时使用Ceph。
延伸解读
阅读路径设计：按需取用而非通读
系列提供多条阅读路径，如核心必读（1→2→5→6→8→10→16）和本地落盘（7→8→9），便于不同需求的工程师快速定位。这种模块化设计避免了线性通读的负担，适合已有分布式存储基础、希望深入特定环节（如BlueStore或接入层）的读者。
版本锚定与内容边界
系列明确锚定Ceph Squid v19.2.5，并声明不覆盖安装、编排、性能实测等主题，避免与站内其他文章重复。这种严谨的边界设定有助于读者预期内容深度，同时提示Tentacle（20.x）特性需显式标注，避免混淆。
选型视角：何时不选Ceph
系列不仅讲解Ceph内部机制，还专门对比MinIO、云块和SPDK，明确何时分布式对象栈的税不值得付。这种选型导向的内容对架构师尤为实用，帮助在自建Ceph与替代方案间做出理性决策，而非盲目推崇Ceph。
Q&A
Ceph RADOS 内核系列文章主要覆盖哪些内容？
该系列共18篇文章，涵盖Map传播、OSD Messenger、CRUSH、PG Peering、BlueStore读写、恢复、EC路径以及RBD/CephFS/RGW接入，旨在帮助工程师理解延迟与失败点，提供阅读路径和选型建议。
Ceph 中一次客户端写的延迟和失败点可能出现在哪些层？
延迟和失败点可能出现在MON/MGR map传播、OSD Messenger、CRUSH映射、PG Peering、BlueStore写入等环节，具体可参考系列第1-9和16篇。
PG peering 和 recovery/backfill 各自保证什么？
PG peering 保证PG内副本的一致性，确定权威日志和活动集；recovery/backfill 负责在故障后恢复数据副本，backfill 用于新OSD或缺失数据，recovery 用于副本间差异修复，两者都有限速机制。
BlueStore 相比 FileStore 消除了什么？小写如何落到 WAL？
BlueStore 消除了FileStore的双写问题（数据先写文件系统再写日志），直接管理裸设备。小写（小于min_alloc_size）会先写入BlueFS上的WAL（预写日志），再异步刷入数据区，以提高小写性能。
RBD、CephFS、RGW 分别如何将数据映射到 RADOS 对象？
RBD将image按striping规则切分为多个对象；CephFS通过MDS将文件元数据存储在RADOS对象中，数据也按对象存储；RGW将S3对象映射为RADOS对象，使用索引池和数据池，支持multipart上传。
何时应该选择 Ceph 而不是 MinIO、云块存储或本机 SPDK？
当需要统一存储平台、支持多种接口（块、文件、对象）、要求高可靠性和可扩展性时，选择Ceph；若仅需简单对象存储且规模小，MinIO更轻量；若追求极致低延迟且数据量小，本机SPDK更合适；云块存储适合公有云环境。
Ceph 系列文章推荐的快速建立坐标系的阅读路径是什么？
推荐路径为：1 → 2 → 5 → 6 → 8 → 10 → 16，即从概述、Map传播、PG Peering、客户端写路径、BlueStore写路径、恢复到排障，快速建立整体认知。
