Day31-18｜10.6.7 大型网站系统架构演化实例（七）：分布式文件与数据库系统

一、教材定位

当大型网站的图片、视频、附件和日志不断增长，单机文件系统会受到容量、吞吐、可靠性和扩展方式限制；当单一数据库和读写副本也无法承受数据量、写入量或访问范围时，需要引入分布式文件系统和分布式数据库系统。它们通过分片、复制、分布式路由和多节点协作扩展存储与计算能力。

分布式存储不是简单地把数据放到多台机器上。数据被拆分和复制后，会出现分片键、数据倾斜、副本一致性、跨节点事务、节点故障、重平衡、网络分区和运维复杂度等问题。考试案例常要求说明为什么需要分布式存储、如何选择分片、如何保证可靠性和一致性，以及如何在扩容和故障时保持服务。

二、分布式文件系统

1. 适用场景

分布式文件系统适合保存大规模图片、视频、音频、安装包、备份、日志和归档文件。它通常提供统一命名空间，文件被切分为块并分布在多个存储节点，多个副本用于容错和读取。

2. 基本组成

通常包括元数据服务、数据节点、客户端、复制和一致性管理、监控与调度。元数据记录文件、目录、块位置和副本状态；数据节点负责实际存储和读写。元数据服务本身需要高可用，否则数据节点健康也无法访问文件。

3. 文件访问流程

客户端先向元数据服务查询文件块位置，再直接访问数据节点读取或写入。大文件分块有利于并行和扩展，但会增加元数据、网络和副本管理成本。小文件过多可能导致元数据膨胀和随机访问开销。

4. 可靠性和一致性

文件副本应分布在不同节点、机架或可用区，防止单故障域同时丢失。写入要明确确认策略，是写入一个节点即返回，还是等待多个副本确认。副本失效后要自动补副本，但重建过程要控制带宽和磁盘压力。

三、分布式数据库系统

1. 分库分表与分片

分库分表可以按照用户、租户、区域、时间或业务对象把数据分到不同节点。分片键应具有高基数、分布均匀、查询常用和稳定等特征。选择错误会造成热点、跨分片查询和迁移困难。

2. 水平和垂直拆分

水平拆分把同一表的记录分到多个分片，适合数据量和写入量增长；垂直拆分按列或业务领域分离，适合冷热数据、敏感数据和职责边界。两者可以组合，但需要处理跨表和跨分片访问。

3. 分片路由

应用、代理或数据库中间件根据分片键把请求路由到目标节点。路由规则要支持版本、扩容、迁移和故障。查询缺少分片键时可能广播到所有节点，必须限制范围、建立索引或改变访问模型。

4. 副本与读写

分片通常拥有多个副本，用于高可用和读扩展。同步、半同步和异步复制的选择影响延迟、数据丢失和可用性。跨副本读取要处理延迟、会话一致性和故障切换。

四、分片设计的关键问题

1. 分片键选择

分片键应尽量避免热点和倾斜。例如按用户ID可以保证用户数据集中，但大客户或超级用户可能形成热点；按时间分片便于归档，但当前时间段可能写入集中。可采用复合键、哈希、分区和热点拆分。

2. 跨分片查询

跨分片聚合、排序、连接和事务成本高。可以通过冗余字段、汇总表、搜索索引、数据仓库或异步物化视图减少跨分片操作。不能为了保持旧查询习惯而让每次请求广播所有节点。

3. 跨分片事务

分布式事务协调复杂，性能和可用性成本高。优先重新划分业务边界，使核心原子操作落在同一分片；跨分片流程采用事件、状态机、幂等、补偿和对账。对账和人工接管是必须的兜底机制。

4. 重平衡和扩容

增加节点后需要迁移数据和更新路由。迁移期间必须保持读写正确，控制带宽、锁和业务影响。可采用一致性哈希、虚拟分片、在线迁移、双写和逐步切流。扩容完成后要验证数据完整性和负载均衡。

五、一致性和可用性权衡

分布式系统面对网络分区时，不能同时无条件保证所有节点立即一致和持续可用。业务要明确哪些数据需要强一致，哪些允许最终一致，哪些可以返回旧值或降级。

支付、账务和库存扣减通常需要严格的不变量和可追溯状态；内容、推荐和统计结果可以接受短暂延迟。最终一致并不等于不需要一致性设计，仍要有事件可靠性、幂等、重试、补偿、对账和收敛时间目标。

六、分布式存储的故障处理

1. 节点故障

故障节点要被检测、摘除和替换，副本数量要恢复。读请求可以转移到健康副本，写请求要根据仲裁和一致性规则处理。恢复节点不能直接重新接收全部流量，需先同步和校验。

2. 网络分区

网络隔离可能导致多个节点认为自己是主节点或各自接受写入。要使用租约、仲裁、版本和安全拒写防止脑裂。分区恢复后，冲突合并不能只依赖最后写入时间，必须依据业务版本和人工规则处理。

3. 磁盘和数据损坏

使用校验和、快照、日志、多个副本和定期校验发现静默损坏。恢复要记录损坏范围和修复来源，不能只看节点进程正常。

4. 元数据故障

分布式文件系统的元数据服务、数据库的路由和配置中心都是关键依赖，需要集群、备份、选主和恢复演练。元数据丢失可能比单个数据节点故障影响更大。

七、分布式文件系统与数据库的运维

监控文件系统的容量、块分布、副本数、重建、热点、元数据延迟和小文件数量；监控分布式数据库的分片负载、热点键、复制延迟、事务冲突、跨分片请求、迁移进度和数据差异。

运维操作要有权限、审计、限速和回滚。扩容、重平衡和副本修复可能与正常业务争用资源，应设置窗口、带宽和暂停条件。重要数据要定期执行恢复演练，验证备份不是“能生成”而是“能恢复并可用”。

八、案例分析：图片与订单数据分布式化

某内容电商平台图片和视频增长到数百 TB，订单表也达到单库容量和写入瓶颈。项目组计划把文件复制到多台服务器，并按月份拆分订单表。

文件系统改造需要统一对象标识和元数据服务，文件内容分块存储并跨故障域复制；上传先写临时对象，校验摘要后提交元数据，下载通过 CDN 或边缘缓存；副本不足、校验失败和节点故障进入自动修复队列。小文件要合并或采用对象存储，不能让元数据服务承受大量目录操作。

订单数据库不能只按月份拆分。历史查询、跨月订单、用户维度查询和支付状态更新都要分析。可以按用户或订单ID进行主分片，再通过时间索引和归档处理历史数据；对于跨分片报表使用离线汇总。订单创建、支付和库存扣减尽量保持业务聚合内原子，跨分片流程使用事件和补偿。扩容时采用虚拟分片、在线迁移和灰度路由，检查记录数、摘要、金额、状态和业务对账。

九、综合知识练习

题1

分布式文件系统为什么需要元数据服务？

参考答案：元数据服务记录文件、目录、块位置、副本状态和权限，帮助客户端定位数据并管理复制、迁移和故障恢复。元数据服务本身是关键依赖，也需要高可用和备份。

题2

选择分片键时应考虑哪些因素？

参考答案：数据分布均匀、避免热点、查询常用、值稳定、便于路由、支持扩容和迁移，并评估跨分片查询、事务和历史归档需求。

题3

为什么分布式数据库扩容不能只增加节点？

参考答案：已有数据和路由仍可能集中在旧节点，需要重平衡和迁移；迁移还会影响一致性、性能、事务和业务读写。必须设计在线迁移、灰度切流、数据校验、限速和回滚。

十、论文写作素材

论文中可以这样描述分布式存储演化：

“针对文件和业务数据规模增长导致单机容量、吞吐和故障恢复能力不足的问题，我分别设计分布式文件和分布式数据库方案。文件按块分布并跨故障域复制，元数据服务高可用，上传采用临时对象、校验和提交，故障后自动补副本；数据库根据业务访问和所有权选择分片键，使用副本、路由和在线重平衡扩展容量。对跨分片事务采用事件、幂等、补偿和对账，监控热点、复制延迟、迁移进度、副本健康和数据差异，扩容和故障恢复均通过灰度和演练验证。”

十一、今日复盘

分布式文件和数据库通过分片、副本和多节点扩展容量与吞吐。
分布式存储必须处理元数据、路由、热点、复制、一致性和重平衡。
分片键决定访问效率、数据均衡、跨片查询和迁移难度。
跨分片事务应优先重划边界，并使用事件、幂等、补偿和对账。
节点、网络、磁盘、元数据和副本故障都要有检测、切换和恢复方案。
案例答题要写清存储对象、分片策略、一致性、扩容迁移和验证证据。