分布式块存储：支撑云原生存储的基础设施

可视化演示

展示分布式块存储的核心机制：数据分片与多副本复制拓扑、条带化并行IO与IOPS/吞吐性能随节点数的线性扩展能力。

1. 块存储基础：认识“块”这块砖

馆长把《城市百科》拆成分册后，发现分册还不够“细”：如果一次只改一页，难道要把整册书重新抄一遍？于是馆员规定：所有藏书统一按 4KB 一“页”管理，借阅、抄录、清点都以页为最小单位。这个“页”就是块存储中的“块”（Block）——一个大小固定、可独立读写的数据单元，常见的块大小有 4KB、16KB、64KB。

把概念搬回计算机世界：块存储是三种存储形态中最“底层”的一种。文件存储关心“文件名和目录”，对象存储关心“钥匙和元数据”，而块存储只回答一个问题——“第几号块里放了什么数据？”。它不管上面是文件系统还是数据库，就像图书馆不管读者用这本百科写论文还是做剪报。一个“卷”（Volume）就是一组连续块的逻辑集合，通过 iSCSI 或 NVMe 等协议挂载给一台云主机，主机把它当成一块裸磁盘，格式化后才能在它上面建文件系统。

一个卷需要多少块，由容量和块大小共同决定：

有了“页”这个标准零件，分布式存储这座大机器才可能高效运转——分片、副本、一致性，都是在一页一页的粒度上操作的。块虽小，却是整座图书馆唯一的地基。

2. 数据分片：把分册均匀撒向各分馆

书拆成分册后，下一个问题是：这些分册放哪？如果全部堆在东馆一层楼，馆员找书依然费劲，读者也全挤在同一区。馆长的方案是让编号 1-100 的分册去东馆、101-200 的去西馆、201-300 的去南馆……这就是数据分片：把数据打散到多台节点，让每台节点只承担一部分读写压力，整座图书馆的容量也因此可以无限扩张。

分布式块存储里最主流的分片策略是哈希取模。每个数据块有一个全局唯一的块 ID，把它丢进哈希函数得到一个均匀分布的整数，再对节点数取模，就得到了“这本分册该放哪家分馆”的答案：

除了哈希映射，系统还会把大块 I/O 做“条带化”——把一个大的读写请求切成多份，同时发给多个节点并行处理，就像把整册书的复印任务分给十台复印机同时开工；节点之间还会不停做负载均衡，防止某个分馆的书架爆满而隔壁空空如也。分册撒得越均匀，整座图书馆的吞吐能力就越强。

3. 副本机制：每册书都复印多份

东馆的一场小火警让馆长惊出一身冷汗：如果那 100 册书真的被烧了，百科就永远缺了一块。于是馆长定下铁规矩——每一册书都必须复印三份，分别放到三个互不相邻的分馆，这样哪怕一个分馆被火烧了，另外两处仍能借出完整内容。这就是副本机制：为每个数据块保存多份拷贝，并且把它们放到不同的故障域（不同机架、不同可用区）中，避免“同一个灾难一锅端”。

在分布式块存储中，每个块通常保存 2 到 3 份副本，其中一个是主副本（Primary），负责接收写入，其余是从副本（Secondary）。当一个节点的副本损坏或失联，系统会自动从其他副本把数据“补印”一份，恢复到目标副本数。副本带来的可靠性提升可以用一个公式衡量：

注意：副本数从 1 加到 3，可用性从 0.9 跳到 0.999；但继续加到 5，收益就越来越小，而空间和同步开销却在线性增长。复印机虽多，也要算算房租和电费，副本是可靠性与成本之间的精妙平衡。

4. 一致性协议：分馆间的同步铁律

复印件多了，新的麻烦随之而来：读者在东馆借到的册子，和西馆那份会不会不一样？馆长规定，任何修改必须先在“主分馆”完成，再按编号顺序同步到各分馆；同时，每次读写都要遵守一条“过半数确认”规则，确保无论读者从哪个分馆借，看到的都是最新版本。这套馆际协作规则，就是一致性协议。

具体到工程实现，写入数据时，主副本负责协调：它把新数据发给所有从副本，要求至少 W 个副本确认写入成功，才向应用返回成功；读取数据时，客户端会并行读取 R 个副本，以内容最新的那份为准。只要读写涉及副本集合有重叠，就能保证读到最新数据，规则如下：

一致性协议还要防住一个经典灾难——“脑裂”。如果两个分馆之间的通信断了，它们各自以为自己是总馆，同时接受写入，等通信恢复就对不上账。解决办法是引入心跳和租约：只有持有“馆长令牌”的节点才能对外提供写服务，令牌过期必须重新竞选。同步铁律越严密，图书馆在极端情况下越不容易精神分裂。

5. 快照功能：给书库拍一张全景照片

图书馆每周五闭馆后，馆长都会让馆员给所有书架拍一张“全景照片”留档。如果接下来某天有书被撕毁、系统瘫痪，大家就能拿着上周五的照片，把书库还原成那一刻的样子。这张照片在存储世界里叫快照（Snapshot）——它把整个卷在某个时间点的状态完整保存下来，用于灾难恢复、测试和克隆新卷。

聪明的你可能马上问：一个 1TB 的卷，拍快照难道要立刻复制 1TB 数据？馆长才不会这么笨。快照采用的是“写时复制”（Copy-on-Write）技术：拍照那一刻，什么都不复制，只记录一份元数据清单；只有当某个块在快照之后被修改时，系统才先把“旧块”复制到快照区域，再允许新数据覆盖原位置。这样一来，快照初始成本几乎为零，之后只随修改量缓慢增长：

快照还可以串联成“快照链”，每张新照片只记录与上一张的差异，节省大量空间；而基于快照可以秒级生成一个独立的新卷（克隆），供测试或生产使用。照片看似轻巧，却为数据灾难恢复上了最结实的一道保险。

6. 云盘应用：读者随借随还的借阅体验

对读者来说，他根本不需要知道书存在哪个分馆、有几份拷贝——只要到前台报出册号，几分钟内书就送到手上。云盘（云硬盘）就是分布式块存储面向云主机提供的这种“读者体验”：一台云主机就像一位读者，云盘就是它专属的借阅证，随时可以挂载、卸载，容量也能弹性伸缩。

云硬盘在云平台上承担着几个关键职责：一是作为云主机的系统盘和数据盘，操作系统、应用程序都跑在它上面，提供持久化存储——云主机宕机重启后数据依然在；二是支持在线扩容，业务增长时无需停机就能把卷从 100GB 扩到 1TB，就像读者把借阅额度从 10 本升到 100 本；三是共享盘，允许把同一个卷同时挂载给多台云主机，让集群中的多个节点像几位学者共读同一册珍贵文献一样协作。

块存储集群的性能通常用 IOPS（每秒读写次数）和吞吐量衡量，分布式架构通过条带化把多个节点的能力聚合起来：

云盘的体验如此自然，以至于很多开发者都没意识到：自己随手创建的一块系统盘，背后是一个会在几百毫秒内完成多副本同步、故障切换和负载均衡的庞大分布式系统。

7. 数据库支撑：最挑剔的学术研究室

如果把云主机比作普通读者，那数据库就是图书馆里最挑剔的学术研究室：它要求每一本参考书（数据页）必须在极短时间内取到，任何一次借阅记录（事务日志）都必须立刻登记在案，绝不能丢。数据库的持久化与高可用，深深依赖底层块存储的可靠性。

数据库在提交一个事务时，会先把日志写入 WAL（Write-Ahead Logging，预写日志），确保宕机后能通过日志重放恢复数据。这份 WAL 日志就存放在分布式块存储提供的卷上。块存储的每一次写确认延迟，直接决定了数据库每秒能提交多少事务：

除了 WAL，数据库还利用块存储的弹性扩展能力——数据量增长时在线扩容数据卷；利用快照能力做定期备份；存储层发生故障时，底层的副本切换对数据库透明，数据库几乎察觉不到。学术研究室的桌椅板凳可能很普通，但它脚下的大楼地基，必须足够坚固。分布式块存储就是那栋大楼最可靠的地基。

AI 应用场景

Python 演示

import hashlib  class Block:    """一个数据块，模拟固定大小的一块数据"""     def __init__(self, block_id, data):        self.block_id = block_id        self.data = data  class DistributedBlockStore:    """模拟分布式块存储：哈希分片 + 多副本写入"""     def __init__(self, node_count, replica_count):        self.nodes_map = [{} for _ in range(node_count)]        self.replica_count = replica_count        self.write_count = 0     def _targets(self, block_id):        """返回该块应写入的节点列表（主副本 + 从副本）"""        start = int(hashlib.md5(str(block_id).encode()).hexdigest(), 16) % len(self.nodes_map)        result = []        for i in range(self.replica_count):            result.append((start + i) % len(self.nodes_map))        return result     def write_block(self, block):        targets = self._targets(block.block_id)        for node_id in targets:            self.nodes_map[node_id][block.block_id] = block.data        self.write_count += 1        return targets     def read_block(self, block_id):        for node_id in self._targets(block_id):            if block_id in self.nodes_map[node_id]:                return self.nodes_map[node_id][block_id]        return None     def kill_node(self, node_id):        """模拟节点故障：清空该节点的所有块"""        self.nodes_map[node_id] = {}  def main():    store = DistributedBlockStore(node_count=4, replica_count=3)     for bid in range(10):        data = b"block-%d" % bid        targets = store.write_block(Block(bid, data))        print("write block %d -> nodes %s" % (bid, targets))     print("read block 0:", store.read_block(0))     store.kill_node(2)    print("after node 2 down, read block 0:", store.read_block(0))    print("after node 2 down, read block 1:", store.read_block(1))    print("total writes:", store.write_count)  if __name__ == "__main__":    main()

1. self.nodes_map = [{} for _ in range(node_count)]每个节点用字典保存块数据，模拟一台存储节点。
2. start = int(hashlib.md5(...), 16) % len(self.nodes_map)对块 ID 哈希取模，决定主副本落在哪台节点。
3. result.append((start + i) % len(self.nodes_map))从主副本起轮转选择从副本，把副本分散到不同节点。
4. for node_id in targets: self.nodes_map[node_id][block.block_id] = block.data同一份数据写入多个副本，模拟冗余存储。
5. def read_block(self, block_id)读取时从主副本开始尝试，失败则顺延到下一个副本，模拟容错转移。
6. store.kill_node(2)模拟节点 2 宕机，验证其他副本仍能提供数据。

常见误区

面试题