架构思维：如何设计一个支持海量数据存储的高扩展性架构_数据分片、存储、复制与一致性的原理性问题

文章目录

PRE
引言
1. 数据分片策略
- Hash取模分片
- 一致性Hash分片
- Range分片
- - 分片设计原理
  - 核心设计模块
  - - 分片规则定义
    - 动态分片调整
    - 路由与负载均衡
  - 应对热点的关键技术
  - - 多级分片（Hierarchical Sharding）
    - 副本分散策略
    - 缓存层配合
  - 典型应用场景
  - 优缺点分析
2. 应对热点数据
3. 数据复制与一致性
4. 分片元数据管理
5. 一致性算法对比
6. 扩展性与容灾
总结

在这里插入图片描述

PRE

每日一博 - 一致性哈希：分布式系统的数据分配利器

分布式存储 - 那些关于分布式缓存的一二事儿

深入浅出分布式缓存：原理与应用

引言

如何设计一个支持海量商品存储的高扩展性架构？

在做分库分表时，基于 Hash 取模和一致性 Hash 的数据分片是如何实现的？
如何对热点商品数据做存储策略？
强一致性和最终一致性的数据共识算法是如何实现的？

在分布式系统中设计支持海量商品存储的高扩展性架构，需综合考虑数据分片、复制策略及一致性算法

在这里插入图片描述

1. 数据分片策略

Hash取模分片

将商品ID通过哈希函数取模，均匀分布到节点。例如，4个节点时，商品ID%4决定存储位置。优点：数据分布均匀；缺点：扩展性差，节点增减导致大规模数据迁移。

在这里插入图片描述

一致性Hash分片

节点和数据映射到哈希环，数据顺时针找到最近节点存储。通过虚拟节点（如10个虚拟节点对应4个物理节点）减少数据倾斜。优点：节点增减仅影响相邻数据，迁移量小；缺点：仍存在单一热点问题。

在这里插入图片描述

当我们新增一台服务器，即节点 E 时，受影响的数据仅仅是新服务器到所处环空间中前一台服务器（即沿着逆时针方向的第一台服务器）之间的数据。只有商品 100 和商品 101 从节点 A 被移动到节点 E，其他节点的数据保持不变。此后，节点 A 只存储 Hash 值为 2 和 3 的商品，节点 E 存储 Hash 值为 0 和 1 的商品

在这里插入图片描述

Range分片

虽然一致性 Hash 提升了稳定性，使节点的加入和退出不会造成大规模的数据迁移，但本质上 Hash 分片是一种静态的分片方式，必须要提前设定分片的最大规模，而且无法避免单一热点问题，某一数据被海量并发请求后，不论如何进行 Hash，数据也只能存在一个节点上，这势必会带来热点请求问题。比如某些商品卖得非常火爆，通过 Hash 分片的方式很难针对热点商品做单独的架构设计。

所以，如何解决单一热点问题？答案是做 Range（范围）分片

分片设计原理

基于范围的数据划分
将数据按照键的范围（如时间戳、主键区间等）划分为连续区间，每个区间对应一个分片（Shard）。
- 示例：分片1（0-1000）、分片2（1001-2000）…
- 允许动态调整分片边界，支持热点范围的二次拆分。
与 Hash 分片的对比优势
- 灵活扩展：无需预先定义分片数量，可动态增减。
- 范围查询高效：相邻数据天然聚集在同一分片，适合扫描类操作（如 BETWEEN 查询）。
- 热点分散：可将单一热点范围拆分为多个子分片，分散负载。

核心设计模块

分片规则定义

分片键（Shard Key）
选择具有业务意义且可排序的字段（如订单ID、时间戳、地理位置编码）。
- 示例：电商场景可选择「商品ID前缀+时间戳」作为组合键。
分片元数据管理
维护全局分片映射表（Shard Map），记录每个分片的起止键、所属节点、负载状态等。
- 存储方式：独立元数据库（如 etcd/ZooKeeper）或配置中心。

动态分片调整

分裂（Split）
当单个分片数据量或请求量超过阈值时，自动将其拆分为多个子分片。
- 触发条件：数据量 > 阈值（如 10GB）或 QPS > 单节点承载能力。
- 操作流程：
  1. 暂停分片写入（短暂不可用）。
  2. 按中间键（Mid Key）分裂数据。
  3. 更新元数据并恢复服务。
合并（Merge）
相邻分片负载较低时，合并以降低管理开销。
- 触发条件：数据量 < 合并阈值（如 1GB）且 QPS 持续低位。

路由与负载均衡

客户端路由
客户端通过查询元数据确定目标分片位置。
- 优化：本地缓存分片映射表，减少元数据访问延迟。
代理层路由
通过中间件（如 Proxy 或 Coordinator）转发请求，实现透明分片。
- 示例：TiDB 的 Placement Driver（PD）负责分片调度。
热点重定向
实时监控分片负载，动态将热点分片请求分流至副本或新分裂的子分片。

应对热点的关键技术

多级分片（Hierarchical Sharding）

主分片（Primary Shard）管理整体范围，子分片（Sub-Shard）处理热点区间。
- 示例：某热门商品ID范围 2000-3000 可拆分为 2000-2500 和 2501-3000，分布到不同节点。

副本分散策略

为热点分片创建多个只读副本（Read Replica），分布在多个节点。
写入仍由主分片处理，读取流量分散到副本。

缓存层配合

结合 Redis 或内存缓存，将热点数据提前加载至应用层，减少对底层分片的直接访问。

典型应用场景

时序数据
- 按时间范围分片（如日志、监控数据），天然支持按时间过滤查询。
热销商品
- 将热门商品ID区间拆分到多个分片，结合缓存分散请求。
多租户 SaaS 系统
- 按租户ID分片，确保同一租户数据局部性。

优缺点分析

优点	挑战
灵活应对数据增长与热点	分片键选择不当易导致数据倾斜
高效处理范围查询	动态分片需复杂元数据管理
支持业务语义分片（如按地域、时间）	跨分片事务一致性实现成本较高

通过 Range 分片的动态性和灵活性，结合副本、缓存和自动化调度策略，可有效解决单一热点问题，同时为业务提供高效的范围查询能力。

2. 应对热点数据

读热点：引入缓存（如Redis）分担数据库压力，结合本地缓存减少网络开销。
写热点：
- Range分片：将热点类目拆分为多个分片，结合垂直扩展（提升单节点性能）。
- 分片元数据服务：通过ETCD集群管理分片信息，动态路由请求，灵活调整热点分片分布。

3. 数据复制与一致性

主从复制：数据副本提升可用性，主节点故障时从节点接管。
一致性算法：
- 强一致性（Raft/Paxos）：确保数据变更原子性。ETCD使用Raft，选举Leader处理请求，日志复制保证多数节点一致。
- 最终一致性（Gossip）：节点间异步传播数据，容忍临时不一致。适用于AP场景，如Cassandra。

4. 分片元数据管理

元数据服务：独立集群存储分片规则、节点状态，通过ETCD保证高可用和一致性。
客户端路由：请求先查询元数据获取分片位置，结合缓存减少元数据访问延迟。

5. 一致性算法对比

在分布式系统中，造成系统不可用的场景很多，比如服务器硬件损坏、网络数据丢包等问题，解决这些问题的根本思路是多副本，副本是分布式系统解决高可用的唯一手段，也就是主从模式，那么如何在保证一致性的前提下，提高系统的可用性，Paxos 就被用来解决这样的问题，而 Paxos 又分为 Basic Paxos 和 Multi Paxos，然而因为它们的实现复杂，工业界很少直接采用 Paxos 算法。

Raft 是 Multi Paxos 的一种实现，是通过一切以领导者为准的方式，实现一系列值的共识，然而不是所有节点都能当选 Leader 领导者，Raft 算法对于 Leader 领导者的选举是有限制的，只有最全的日志节点才可以当选。正因为 ETCD 选择了 Raft，为工业界提供了可靠的工程参考，就有更多的工程实现选择基于 Raft，如 TiDB 就是基于 Raft 算法的优化

除此之外，还可以有一种思路：分片元数据服务毕竟是一个中心化的设计思路，而且基于强一致性的共识机制还是可能存在性能的问题，有没有更好的架构思路呢？

既然要解决可用性的问题，根据 Base 理论，需要实现最终一致性，那么 Raft 算法就不适用了，因为 Raft 需要保证大多数节点正常运行后才能运行。这个时候，可以选择基于 Gossip 协议的实现方式。

Gossip 的协议原理有一种传播机制叫谣言传播，指的是当一个节点有了新数据后，这个节点就变成了活跃状态，并周期性地向其他节点发送新数据，直到所有的节点都存储了该条数据。这种方式达成的数据一致性是 “最终一致性”，即执行数据更新操作后，经过一定的时间，集群内各个节点所存储的数据最终会达成一致，很适合动态变化的分布式系统。

在这里插入图片描述