本章探讨分布式存储系统的数据寻址方式，从数据寻址以及 I/O 流程入手，逐步揭开Ceph存储系统的神秘面纱。
2.1 数据寻址方案
存储系统的核心功能是数据的存取，实现这一目标的前提是正确、高效的数据寻址策略，即存储系统首要解决的问题是数据写到哪里去，数据从哪里读出。
经过学术界和工业界多年的探索和实践，数据寻址的方式基本被归结为两大类，分别 是查表型寻址方式（有中心的非对称式架构）与计算型寻址方式（无中心的对称式架构），下面将对两类方案做详细对比。
2.1.1 查表型寻址方式
在早期的数据系统中，基于查表的数据寻址是很自然且有效的方式，至今诸多系统都仍在使用。
比如单机文件系统，从创建至今，依然是以该方式为主，不论是像 Ext4、Zfs这类基于多级数组的方式，还是Btrfs这类基于B-Tree的方式，本质上都是基于查表的实现，区别仅仅在于优化查表的时间效率和空间利用率上。在数据系统的另一大领域——数据库 系统中，当今流行的不论是基于B-Tree或是基于LSM-Tree的存储引擎，都没有绕开使用查表这一方式来解决数据位置映射问题。
对于分布式存储系统，较早时期的系统架构设计中会很自然地沿用这种由单机系统延 伸出来的已有特性，所以查表方式也被分布式存储系统广泛采纳并加以实现。这类系统中 的典型代表是大家比较熟悉的由Google发表在 SOSP'03上的GFS（GoogleFileSystem）分布式存储系统，GFS是一个具有松散POSIX语义的文件系统，面向大文件场景进行优化，它的典型特征是数据与索引分离进行存储，即数据面的核心操作不会经过索引面，而索引 面解决的问题就是人们关心的数据寻址问题。
GFS将所有元数据存储于所谓的 Master节点上，Master 节点应对前端对数据路由的查询和更新操作，是全局寻址信息的权威记录，这样的设计称为“中心化索引”，中心化索引的架构具备简单且高效的特性，基于数据、索引分离的设计理念使得 Master 节点不会成为整个系统 I/O操作的瓶颈，而面向大文件的设计场景也使得元数据的规模不会非常大， 有效地规避了拓展性问题。GFS 这类系统架构并不完美，在应对海量小文件的场景下会产生诸多问题。当然，GFS通过层级存储（LayeringStorage）的设计依靠 BigTable缓解了这一问题，但在海量小文件存储场景下，中心化索引面临的性能问题和架构劣势仍会逐步凸显出来。
值得肯定的是，GFS这类架构引领了分布式存储 10年的风向标，有大量的系统追随这一架构。或者说，GFS 更像是那个时代最佳的分布式存储系统元数据索引解决方案。
后来，随着业界对基于中心索引架构带来的一系列如SPOF（SinglePointofFailure）、元数据性能/规模等问题的探索，大家越来越倾向于使用shared-nothing的方式来解决分布式存储的架构问题，这一阶段大量的系统涌现出来，包括 Swift、Ceph、Dynamo等，它们都采用了所谓的“去中心化索引”的方式进行架构设计，也就是基于计算的寻址方式。
2.1.2 计算型寻址方式
如果将CPU-Intensive的索引寻址操作置于中心节点，中心节点必然面临性能瓶颈，如果我们能够采用分而治之的方式，将寻址操作分散到更多甚至集群中所有的存储节点中 去，就可以有效地解决这个问题。“分而治之”即要求各节点能够基于本地状态进行寻址自治，而在分布式系统中，特别是使用普通商用服务器进行部署的大规模系统，各节点具有 天生的故障可能性，当一个节点掉线，其数据 / 状态就有可能无法恢复，所以必须设计出一套能够具有让数据在无状态节点之间进行寻址能力的系统，显然，只有基于计算才具备 实现这一能力的可能。当然，从本书后文对 Ceph存储系统的CRUSH算法描述来说，存储节点并不是完全的无状态，存储系统需要依赖一小部分集群信息进行数据存储位置的计 算寻址。
有很多的算法致力于解决该问题，比如 Swift和 Dynamo 中被广泛应用的一致性Hash算法，该算法能够较好地解决普通 Hash 算法被人诟病的故障后数据迁移规模的问题。但其本身依然有诸多缺点，比如对异构设备 / 容灾域管理不便、数据路由稳定性等问题，容易在分布式存储系统中形成无谓的数据搬迁流量。
开源项目 Ceph在其分布式文件系统的实现中提出了 CRUSH算法（ControlledScalableDecentralizedPlacementofReplicatedData，可控的、可扩展的、分布式的伪随机数据分布算法），该算法不仅吸收了一致性Hash算法的随机性，也对一致性Hash算法面临的诸多问题提出了可行的解决方案，并付诸工程实现，这使得 CRUSH成为计算寻址方式的代表算法。
对于该算法的详细描述本书后续章节会详细展开，本节重点描述该算法的创新。CRUSH 算法通过伪随机的方式，在数据分布过程中提供较好的节点均衡，同时通过对节点拓扑的管理，能够在节点不可用、上下线过程中提供较低的数据迁移率，保持存储系统数据分布的局部稳定性。
CRUSH 算法的出现为数据系统的设计提供了全新的思路，似乎为海量数据的系统提供了一条明路。但以 CRUSH为核心的Ceph 系统似乎在多年以后，还是没有在超大规模系统实践中证明自身价值，本书也从实践的角度对此提出了一些见解。而与此相反，在 GFS系统诞生10年之后，我们发现这样一个不争的事实：基于中心化索引进行设计的存储系统在面对海量数据、大规模节点部署的场景下依然保持了很好的伸缩性，且运维以及系统可观测性上都要表现得更好、更直观。
2.1.3 鹿死谁手，犹未可知
在大型系统设计中，经常会看到一种“三十年河东，三十年河西”的反差现象。举个例子，在早期的系统开发中，为了简化应用开发者对系统操作、数据操作的复杂度，人们抽象出了操作系统和文件系统这些概念，而随着近些年底层开发者对性能越来越极致的追求，越来越多的系统开始采用 kernel-bypass、去文件系统等设计理念。
类似地，在近 10 年对去中心化设计思潮的追求之后，似乎越来越多的系统又走回了中心化设计的道路上。比较有代表性的是微软的 AzureStorage和阿里巴巴的盘古存储系统， 两者都是对 GFS 这一模型的延伸和强化，它们都在海量的数据和业务下得到了验证，是适合超大规模存储系统使用的设计模式。
