上一篇
分布式数据库术语
分布式数据库是一种将数据存储在多个物理节点上的数据库系统，通过数据分片、复制和分布式事务管理实现高可用与扩展性，核心挑战包括数据一致性（如CAP定理）、节点通信开销及故障恢复机制
分布式数据库核心术语详解
基础架构与核心组件
| 术语 | 定义 | 示例 |
|---|---|---|
| 节点（Node） | 分布式系统中的独立计算单元，存储数据或处理请求 | 单台物理服务器或容器实例 |
| 副本（Replica） | 数据冗余拷贝，用于高可用或负载均衡 | 主节点（Primary）+ 从节点（Secondary） |
| 主从复制（Master-Slave Replication） | 主节点处理写操作，从节点同步数据 | MySQL主从架构 |
| 无共享架构（Shared Nothing） | 各节点独立存储和计算，无共享资源 | Google Spanner、CockroachDB |
| 分区（Partition） | 数据按规则划分到不同节点 | 按用户ID哈希分区 |
数据模型与分片策略
| 术语 | 定义 | 适用场景 |
|---|---|---|
| 水平分片（Horizontal Sharding） | 按行拆分数据到不同节点 | 海量用户数据（如电商订单） |
| 垂直分片（Vertical Partitioning） | 按列拆分数据表 | 热卖商品信息与历史订单分离 |
| 键值分片（Key-based Sharding） | 按主键哈希或范围分配数据 | Redis Cluster集群 |
| 地理分区（Geo-Partitioning） | 按地理位置分配数据节点 | 全球化电商平台的本地化服务 |
分片策略对比表：
| 策略 | 优点 | 缺点 |
|——|——|——|
| 哈希分片 | 负载均匀 | 范围查询效率低 |
| 范围分片 | 支持范围查询 | 热点数据易倾斜 |
| 目录分片 | 灵活策略 | 维护复杂度高 |
一致性与事务管理
| 术语 | 定义 | 典型协议 |
|---|---|---|
| CAP定理 | 一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance）不可兼得 | 选择CP（如HBase）或AP（如Cassandra） |
| BASE理论 | 牺牲强一致性的互联网分布式理论 | 基本可用（Available）、软状态（Soft State）、最终一致（Eventually Consistent） |
| 两阶段提交（2PC） | 协调者+参与者完成分布式事务 | XA协议实现跨库事务 |
| Paxos/Raft协议 | 分布式一致性算法 | Raft（etcd、Consul）更易理解 |
ACID vs BASE对比表：
| 特性 | ACID（传统数据库） | BASE（分布式系统） |
|——|———————-|———————-|
| 一致性 | 强同步保障 | 最终一致 |
| 可用性 | 单点故障影响全局 | 允许临时不可用 |
| 场景 | 金融交易 | 社交媒体点赞 |
容错与高可用机制
| 术语 | 实现方式 | 作用 |
|---|---|---|
| 心跳检测（Heartbeat） | 定期发送存活信号 | 节点故障快速感知 |
| 故障转移（Failover） | 自动切换备用节点 | 主节点宕机时业务无感知 |
| Quorum机制 | 多数派确认读写 | 防止脑裂（Split Brain） |
| 反熵（Anti-Entropy） | 定期校验数据一致性 | 修复节点间数据差异 |
性能优化技术
| 术语 | 原理 | 代表系统 |
|---|---|---|
| 读写分离 | 主节点写操作，从节点读操作 | MySQL读写分离架构 |
| 缓存层（Cache Layer） | 热点数据前置存储 | Redis作为MySQL缓存 |
| 异步批处理 | 合并小请求为批量操作 | Kafka消息队列消费 |
| 向量化执行 | SIMD指令并行处理数据页 | ClickHouse列存引擎 |
部署与运维概念
| 术语 | 说明 | 工具示例 |
|---|---|---|
| 滚动升级（Rolling Update） | 逐个节点重启更新 | Kubernetes Deployment |
| 蓝绿部署（Blue-Green Deployment） | 双环境切换实现零停机 | 阿里云HSF框架 |
| 混沌工程（Chaos Engineering） | 主动注入故障测试韧性 | Chaos Monkey工具 |
| 多活数据中心（Multi-Active Data Center） | 多个数据中心同时提供服务 | TiDB多活架构 |
FAQs
Q1：CAP定理中为什么不能同时满足三者？
A1：在分布式系统中，当发生网络分区（Partition）时，若保证一致性（Consistency），则必须拒绝部分请求（牺牲可用性Availability）；若保证可用性，则可能返回旧数据（牺牲一致性），电商大促时，跨境订单系统可能选择AP模式（允许短暂数据延迟）而非CP模式。
Q2：如何选择合适的分片策略？
A2：需结合业务特征：
- 哈希分片：适合均匀分布的随机访问（如用户ID查询）
- 范围分片：适合时间序列或连续范围查询（如日志数据）
- 混合分片：对高频访问字段哈希分片，对分析字段范围分片（如订单状态+时间）
需评估查询模式、数据增长量及运维复杂度，例如滴滴出行可能对订单ID哈希分片，对行程轨迹按时间范围
