3. 分布式存储基石：分布式文件系统（GFS架构启发）、对象存储与块存储的区别、数据分片与路由策略
好，咱们今天聊点硬核的。分布式系统里，存储是绕不开的基石。你想想看，没有靠谱的存储，上层那些花里胡哨的计算、调度、服务发现，全得塌。
我个人习惯把存储比作「地基」。地基不稳，楼盖得再高也是危房。这一章，咱们就深挖一下分布式存储的三大核心：GFS 架构的启发、对象存储与块存储的差异、以及数据分片与路由策略。
3.1 分布式文件系统：GFS 架构的启发
说到分布式文件系统，GFS（Google File System）是绕不开的经典。我当年刚接触分布式时，读 GFS 论文读了好几遍。说实话，第一遍没太看懂，只觉得它设计得「怪」。后来在项目中踩了坑，才明白它为什么这么设计。
GFS 的核心思想，说白了就是：把故障当成常态。它假设节点会挂、磁盘会坏、网络会断。基于这个前提，它做了几个关键设计：
- 单一 Master 节点：管理所有元数据。很多人觉得这是单点瓶颈。嗯，确实有风险。但 GFS 通过把数据流和控制流分离，让 Master 只负责「指路」，不负责「搬砖」。客户端直接从 Chunk Server 读写数据，Master 的压力就小了很多。
- 大 Chunk 设计：默认 64MB 一个 Chunk。为什么这么大？我刚开始也觉得奇怪。后来明白了，大 Chunk 能减少元数据量，让 Master 的内存能装下更多信息。同时，客户端一次请求能读写更多数据，减少网络交互次数。
- 追加写入为主：GFS 对随机写入的支持很弱，但追加写入（append）性能极好。这跟很多业务场景是匹配的，比如日志收集、数据分析。我在项目中遇到过类似场景，当时就借鉴了 GFS 的思路，把随机写改成了追加写，性能直接翻倍。
核心启发：GFS 告诉我们，分布式文件系统不是「把单机文件系统搬到多台机器上」。它需要重新思考数据布局、一致性模型、以及故障恢复策略。
避坑指南：我曾经在一个项目里，试图用 HDFS（受 GFS 启发）来存储大量小文件。结果 Master 的内存爆了。后来才意识到，GFS 的设计初衷是处理大文件，小文件场景需要额外优化，比如合并小文件、使用分层命名空间。
3.2 对象存储与块存储的区别
很多新手容易把对象存储和块存储搞混。其实它们俩的定位完全不同。我打个比方：
- 块存储：就像你家的硬盘。操作系统可以直接读写「块」，但你需要自己管理文件系统、目录结构。典型代表：SAN、Ceph RBD。
- 对象存储：就像云盘。你上传一个文件，它给你一个 URL。你不需要关心数据存在哪个磁盘、哪个目录。典型代表：AWS S3、MinIO、Ceph RGW。
它们的关键区别，我整理了一张表：
| 维度 | 块存储 | 对象存储 |
|---|---|---|
| 访问方式 | 通过块设备接口（SCSI、iSCSI） | 通过 HTTP API（RESTful） |
| 数据组织 | 按块（Block）组织，通常 4KB-64KB | 按对象（Object）组织，包含数据、元数据、ID |
| 适用场景 | 数据库、虚拟机磁盘、高性能计算 | 静态文件、备份归档、大数据分析 |
| 扩展性 | 受限于块设备协议，扩展较复杂 | 天然支持海量数据，扩展性好 |
| 一致性 | 强一致性 | 最终一致性（部分实现支持强一致性） |
你想想看，为什么对象存储能支持海量数据？因为它把元数据和数据分离了。每个对象有一个唯一的 ID，通过这个 ID 就能定位到数据。不需要维护复杂的目录树结构。这跟 GFS 的 Master-Chunk 设计有异曲同工之妙。
注意：对象存储不适合需要频繁修改小部分数据的场景。比如数据库的随机读写，用对象存储会非常痛苦。我见过有人把 MySQL 的数据文件放到 S3 上，结果性能惨不忍睹。块存储才是这类场景的正解。
3.3 数据分片与路由策略
数据分片，说白了就是把数据「切」成多份，分散到不同的节点上。为什么要分片？因为单机存不下，也扛不住那么高的并发。
常见的分片策略有三种：
- 范围分片：按某个字段的值范围来分。比如用户 ID 1-10000 在节点 A，10001-20000 在节点 B。优点是范围查询效率高。缺点是容易产生热点，比如新用户注册集中在某个范围。
- 哈希分片：对分片键做哈希，然后取模。比如 hash(user_id) % 4。优点是数据分布均匀。缺点是不支持范围查询，而且节点增减时需要重新哈希。
- 一致性哈希：把哈希空间组织成一个环，每个节点负责环上的一段。节点增减时，只影响相邻节点。这是目前最流行的方案，很多分布式系统都在用。
路由策略，就是客户端怎么知道数据在哪个节点上。常见的有：
- 客户端路由：客户端自己维护路由表，直接跟目标节点通信。性能好，但客户端需要感知集群变化。
- 代理路由：客户端请求先到代理层，代理层转发到目标节点。对客户端透明，但代理层可能成为瓶颈。
- 重定向路由：客户端先问一个节点，节点告诉它数据在哪儿，客户端再去访问。GFS 用的就是这种方案。
实战经验：我在做一个分布式缓存系统时，用了一致性哈希 + 虚拟节点。为什么加虚拟节点？因为物理节点少的时候，哈希分布不均匀。虚拟节点能让数据分布更均匀。嗯，这个细节很多人容易忽略。
最后，聊一下分片键的选择。这是个大坑。我见过有人用时间戳做分片键，结果所有新数据都写到一个节点上，其他节点闲着。选分片键的原则是：访问模式要均匀。比如用户 ID、订单 ID 这种天然随机的字段，就比较适合。
小技巧：如果你不确定选什么分片键，可以先做数据采样，看看字段的分布情况。我曾经用这个办法，帮团队避免了一次严重的分片不均问题。
好了，这一章的内容就到这里。分布式存储是个大话题，咱们今天只聊了冰山一角。下一章，咱们聊聊分布式计算的核心——MapReduce 和流处理。敬请期待。