软考架构师·分布式数据库全体系详解（单一总文档）

适用：软考「系统架构设计师」备考
覆盖：种类/应用场景/理论/案例方案/选型比较/质量属性/易混点/避坑/关联/思维导图/口诀/Redis专题深挖
口诀风格：顺口溜 + 谐音双轨，过目不忘

目录

1. 整体思维导图
2. 理论基石
3. 数据分布三大手段
4. 分布式事务六大方案
5. 主流产品分类与选型
6. 应用场景→技术方案映射
7. 技术选型比较与质量属性
8. 易混淆知识点
9. 易踩坑实践
10. 知识点关联图
11. 过目不忘口诀
12. Redis专题深挖
13. 一页纸速记总表

一、整体思维导图

分布式数据库
├── 理论基石
│   ├── CAP定理（三选二）
│   ├── BASE理论（最终一致）
│   ├── ACID vs BASE（事务权衡）
│   └── 一致性模型（强/最终/因果/读己写/单调读）
├── 数据分布
│   ├── 分片Sharding（哈希/范围/一致性哈希/目录）
│   ├── 复制Replication（主从/多主/无主/同步/异步）
│   └── 分区Partition（水平/垂直）
├── 分布式事务
│   ├── 2PC（两阶段提交）
│   ├── 3PC（三阶段提交）
│   ├── TCC（Try-Confirm-Cancel）
│   ├── Saga（长事务拆分）
│   ├── Paxos / Raft（共识算法）
│   └── 本地消息表 / 最大努力通知
├── 产品分类
│   ├── NewSQL（TiDB/OceanBase/CockroachDB/Spanner/GaussDB-for-openGauss）
│   ├── KV型（Redis Cluster/DynamoDB/Memcached）
│   ├── 文档型（MongoDB分片/CouchDB）
│   ├── 列族型（HBase/Cassandra/Bigtable）
│   ├── 图型（Neo4j分布式/JanusGraph）
│   └── 分析型MPP（Greenplum/ClickHouse/Doris/Druid）
├── 应用场景
│   ├── 金融核心交易→NewSQL强一致
│   ├── 电商商品/订单→分库分表+最终一致
│   ├── 社交关系→图数据库
│   ├── 时序IoT→列族/专用TSDB
│   ├── 海量日志→列族+对象存储
│   └── 实时分析→MPP列存
└── 质量属性映射
    ├── 性能→分片+缓存+列存
    ├── 可用性→多副本+故障转移
    ├── 一致性→Paxos/Raft+同步复制
    ├── 可扩展性→水平分片+无状态
    └── 可靠性→WAL+副本+异地容灾

二、理论基石详解

1. CAP定理

定义：分布式系统最多同时满足三者中的两个：

• C（Consistency）：所有节点同一时刻看到相同数据（线性一致性）
• A（Availability）：每个请求都能收到非错误响应（不保证最新）
• P（Partition Tolerance）：网络分区时系统仍能运转

关键结论：网络分区不可避免，故实际是 CP 或 AP 二选一。

⚠ 易混淆：CAP的C是"线性一致性"（所有节点看到同一值），不是ACID的C（事务前后约束完整）。二者同名不同义，软考常考。

2. BASE理论

CAP在AP分支的工程化妥协：

• Basically Available：基本可用（允许部分失败、响应降级）
• Soft state：软状态（允许中间状态存在，不要求时刻一致）
• Eventually consistent：最终一致（无新更新后最终达到一致）

与ACID对比：

3. 一致性模型谱系（从强到弱）

线性一致性 > 顺序一致性 > 因果一致性 > 读己写一致 > 单调读一致 > 最终一致

• 线性一致性：所有操作像在单机原子执行，且有全局时间约束（最严，Spanner用TrueTime实现）
• 顺序一致性：全局顺序一致，但无时间约束
• 因果一致性：有因果关系的操作顺序一致，无因果的可乱序
• 读己写（RYW）：自己写的自己能读到（最常用，MongoDB writeConcern=majority+readConcern=majority）
• 最终一致：停止更新后最终收敛

三、数据分布三大手段

1. 分片（Sharding / 水平拆分）

一致性哈希核心：节点和key都映射到0~2³²环上，key顺时针找最近节点。加节点只影响相邻段，虚拟节点解决数据倾斜。

2. 复制（Replication）

Quorum公式：N个副本，写需W个确认，读需R个确认，W+R>N 则强一致。常用 N=3, W=2, R=2。

3. 分片 vs 分区 vs 复制（易混淆）

• 分片Sharding：把不同数据放不同节点（水平拆分，解决容量/性能）
• 分区Partition：分片的同义词，但NoSQL中常指单节点内的数据分块（如Kafka partition、HBase region）
• 复制Replication：把同一数据存多份（解决可用性/容错）

口诀：分片分数据，复制抄数据；分片扩容量，复制保可用。

四、分布式事务六大方案

方案对比表

1. 2PC（两阶段提交）

• 阶段一Prepare：协调者问所有参与者"能否提交"，参与者锁资源回yes/no
• 阶段二Commit/Rollback：全yes则commit，任一no则rollback

致命缺陷：

• 同步阻塞：参与者锁资源全程等待
• 协调者单点：协调者宕机，参与者永久阻塞
• 脑裂/数据不一致：部分commit部分abort无法挽回

2. 3PC

在2PC基础上加CanCommit阶段 + 超时机制。理论上解决阻塞，但网络分区下仍可能不一致，工程中几乎不用（开销大），考理论为主。

3. TCC（Try-Confirm-Cancel）

业务层面补偿，三阶段：

• Try：预留资源（冻结额度）
• Confirm：确认执行（扣款）
• Cancel：取消释放（解冻）

优点：无锁、高性能；缺点：业务侵入大，每个操作都要写三套。金融场景首选。

4. Saga

将长事务拆成N个子事务T₁…Tₙ，每个Tᵢ有补偿Cᵢ。失败时反向执行已成功事务的补偿。

两种实现：

• 编排式(Orchestration)：中央协调器（适合复杂流程）
• 协同式(Choreography)：事件驱动（适合简单流程）

5. Paxos / Raft（共识算法，非事务但支撑复制）

• Paxos：多数派达成一致，最难懂但最严谨，ZooKeeper ZAB是其变种
• Raft：Paxos的工程化简化，强领导者+日志复制，etcd、TiDB、CockroachDB都用

⚠ 易混淆：Paxos/Raft解决的是副本间日志一致（复制层），不是业务事务。分布式事务在其上叠加2PC/TCC。TiDB = Raft(复制) + 2PC(跨分片事务)。

五、主流产品分类与选型

1. NewSQL（兼顾SQL+水平扩展+强一致）

共同特征：兼容SQL、水平扩展、分布式事务、自动高可用。

2. NoSQL分类

3. 分析型MPP（列存+向量化）

六、应用场景→技术方案映射

七、技术选型比较与质量属性对应

选型决策矩阵

质量属性→技术手段映射

性能      ← 分片(并行) + 缓存 + 列存(压缩) + 向量化执行
可用性    ← 多副本 + 故障自动转移 + 跨机房 + 无中心架构
一致性    ← Paxos/Raft + 同步复制 + 2PC + Quorum(W+R>N)
可扩展性  ← 水平分片 + 无状态协调层 + 一致性哈希(平滑扩容)
可靠性    ← WAL预写日志 + 副本 + 异地备份 + 持久化刷盘
安全性    ← 传输加密 + 字段加密 + 审计日志 + RBAC

八、易混淆知识点（软考高频陷阱）

陷阱1：CAP的C ≠ ACID的C

• CAP的C：多副本间线性一致性（同一时刻同值）
• ACID的C：事务前后业务约束完整（外键、唯一、check约束）
• 同名"C"不同义，软考最爱考

陷阱2：强一致 ≠ 同步复制

• 同步复制是实现手段，强一致是对外语义
• 异步复制+读主也能实现读己写一致
• Spanner用原子钟+Paxos实现线性一致，不靠"同步复制"字面

陷阱3：分片 ≠ 分区

• 分片Sharding：跨节点拆数据（分布式）
• 分区Partition：单节点内分块（如HBase Region、Kafka Partition、MySQL Partition）
• 软考语境下"数据分片"=“水平拆分”，"分区"有时混用，看上下文

陷阱4：2PC ≠ Paxos

• 2PC：分布式事务提交协议（跨分片原子提交）
• Paxos：分布式共识算法（副本间日志一致）
• TiDB同时用：Raft(复制) + 2PC(事务)，二者正交

陷阱5：最终一致 ≠ 不一致

• 最终一致 = 暂时不一致但保证收敛
• 不等于"随便丢数据"，仍要保证：读己写、单调读等子模型

陷阱6：NewSQL ≠ 分布式MySQL中间件

• NewSQL（TiDB/OceanBase）：原生分布式存储，自动分片+事务
• 中间件分库分表（ShardingSphere/MyCat）：上层路由，跨库事务弱、需应用配合
• 软考常把二者并列，原生NewSQL事务能力更强

陷阱7：BASE的"基本可用" ≠ 不可用

• 基本可用 = 允许响应时间变长、允许部分功能降级，不是"挂了"
• 如大促时关闭退款、返回历史数据

陷阱8：Quorum W+R>N 的N是副本数不是节点数

• N=同一数据的副本数（replication factor）
• 不是集群总节点数，审题要看清

陷阱9：Raft的"强领导者" ≠ 单点

• Leader可重新选举，任期(Term)防脑裂
• 比Paxos更易理解但等价于Paxos(Multi-Paxos)

陷阱10：列族 ≠ 列式存储

• 列族Column Family（HBase）：行内按列族分组存储，行存变体
• 列式存储Columnar（ClickHouse）：按列物理连续存储
• 二者不同，HBase是"宽行稀疏"非纯列存

九、易踩坑实践

十、知识点关联图

CAP ──分支──→ CP ──→ 强一致 ──→ Paxos/Raft ──→ NewSQL(TiDB/OceanBase)
  │                                         └→ 2PC事务
  └──分支──→ AP ──→ 最终一致 ──→ BASE ──→ Cassandra/DynamoDB
                                    └→ Quorum(W+R>N可调一致)

分片(容量/性能) ─┐
复制(可用/容错) ─┼─→ 共同支撑分布式DB
共识(一致)     ─┘

事务层：2PC/3PC/TCC/Saga ─→ 建立在复制层(Raft/Paxos)之上
存储层：行存(RDBMS) / 列存(MPP) / 列族(HBase) / KV / 文档 / 图
查询层：SQL / NoSQL API / 图查询(Cypher) / OLAP(SQL on 列存)

质量属性闭环：
  分片→可扩展性+性能
  复制→可用性+可靠性
  共识→一致性
  三者权衡→CAP约束

十一、过目不忘口诀（顺口溜 + 谐音双轨）

1. CAP三选二

• 顺口溜：一致性可用性，分区来了二选一；要稳就选CP，要活就选AP
• 谐音：C吃A爱P胖 → 一致吃、可用爱、分区胖，三者不可兼得

2. BASE四字

• 顺口溜：基本可用软状态，最终一致才实在
• 谐音：BASE = B不A全S松E终 → 不强求全、松状态、终一致

3. 一致性模型从强到弱

• 顺口溜：线性顺序因果，读己写后最终到
• 谐音：线顺因己终 → “先顺一己终”（先顺从一个自己，终究……）

4. 分布式事务六方案

• 顺口溜：两阶段锁死，三阶段理论美；TCC三段补，Saga长事务拆；本地消息表，最大努力通知
• 谐音：2T3S本地力 → 2PC、TCC、3PC、Saga、本地消息表、最大努力

5. 2PC两阶段

• 顺口溜：一问二令，Prepare先锁Commit后行；协调一挂全员卡死
• 谐音：PC = P怕C挂 → Prepare怕Coordinator挂

6. TCC三阶段

• 顺口溜：Try预留Confirm确认Cancel回滚
• 谐音：TCC = T试C成C撤 → 试一试、成则确认、撤则取消

7. Quorum公式

• 顺口溜：写加读大于副本数，强一致就有数；N三W二R二，常用配置记心头
• 谐音：W+R>N = W我R认N难 → 我(写)和认(读)加起来难(>副本)才一致

8. 分片策略四类

• 顺口溜：哈希均匀范围查，一致哈希扩容佳，目录路由灵活但单点怕
• 谐音：哈范一目 → 哈希、范围、一致、目录

9. 复制三模式

• 顺口溜：同步强但慢，异步快但旧，半同步折中用
• 谐音：同半异 = 同(强)半(中)异(快) → 同步强、半同步中、异步快

10. NoSQL四类

• 顺口溜：KV存键值，文档存JSON，列族存稀疏宽行，图库存节点边
• 谐音：K文列图 → “K文列图"联想"看文列图”（看文章列出图）

11. NewSQL五将

• 顺口溜：TiDB开源HTAP，OceanBase金融扛，Cockroach全球跑，Spanner原子钟，GaussDB政企强
• 谐音：钛海蟑谷高 → Ti(钛)、Ocean(海)、Cockroach(蟑)、Spanner(谷)、Gauss(高)

12. 质量属性对应

• 顺口溜：分片扩容又提速，复制保活又容错，共识保一致，三者权衡CAP来约束
• 谐音：分复共 = 分(扩+快)复(活+错)共(一致) → “分复共"联想"分福共”（分福气共享）

13. 易混十大陷阱

• 顺口溜：CAP的C非ACID的C；强一致非同步复制；分片非分区；2PC非Paxos；最终一致非不一致；NewSQL非中间件；基本可用非不可用；Quorum的N是副本非节点；Raft强Leader非单点；列族非列存
• 谐音：十坑 = C复片事新基N领列 → “C复片事新基N领列"联想"重复片事件新基础引领列队”

14. 一致性哈希

• 顺口溜：环上映节点，顺时针找最近；加节点只动相邻，虚拟节点解倾斜
• 谐音：环顺只虚 → 环上顺时针、只动相邻、虚拟节点

15. 内聚七级（关联模块化设计，软考常配套考）

• 顺口溜：偶然逻辑时间过程，通信顺序功能；从弱到强七级升
• 谐音：偶逻时过通顺功 → “我老师过通顺功”（我老师考过，通顺立功）

十二、Redis专题深挖（软考高频）

Redis 是软考架构师缓存/NoSQL/分布式协调三大方向的高频考点，单独深挖。

1. Redis 本质与定位

• 内存型 KV 数据库，单线程命令执行（6.0+ IO 多线程，命令仍单线程，保证无锁线程安全）
• AP 系统：Cluster 分区时返回旧数据，牺牲强一致换高可用
• 非真正"分布式数据库"，但常作为分布式系统的缓存层/会话层/协调层被考察
• 单机 QPS 约 10 万，瓶颈是内存与网络 IO，非 CPU

2. 数据结构与底层编码（软考数据结构高频对应）

⭐ 跳表（SkipList）：软考数据结构高频考点。Redis ZSet 用 skiplist + dict 双结构：

• skiplist 支持范围查询（ZRANGEBYSCORE），O(logN)
• dict 支持单点查询（ZSCORE），O(1)
• 为何不用红黑树：实现简单 + 范围查询高效（顺序遍历链表）+ 内存可调（概率层数）+ 并发友好（局部锁）

3. 持久化三种方式

AOF 三种刷盘策略：

• always：每条命令 fsync，最安全最慢
• everysec：每秒 fsync，默认，最多丢 1 秒
• no：交由 OS，最快最不安全

RDB 与 AOF 应用场景详解（软考常考对比）

RDB 适用场景：

1. 灾难恢复/冷备份：文件紧凑，适合定期备份、跨机房传输、异地容灾
2. 大数据集重启加载：恢复速度远快于 AOF，适合重启后快速恢复服务
3. 主从全量同步：主从复制首次全量同步就用 RDB（bgsave → 传 rdb → 从库加载）
4. 数据迁移/远程复制：rdb 文件小，适合跨环境迁移
5. 容忍分钟级丢失：如缓存场景，丢几分钟可接受（可从 DB 重建）

AOF 适用场景：

1. 数据安全性要求高：不能丢数据，如会话、订单状态（everysec 最多丢 1 秒）
2. 误操作恢复：AOF 是命令日志，可人工编辑删除误操作命令（如误 flushall）后重放恢复
3. 实时持久化：always 模式每条命令刷盘，适合金融级零丢失（性能代价大）
4. 配合 RDB 做混合持久化：4.0+ 推荐 aof-use-rdb-preamble，RDB 全量 + AOF 增量，兼顾速度与安全

生产推荐：混合持久化（4.0+）= RDB 全量（快速加载）+ AOF 增量（少丢数据），appendonly yes + aof-use-rdb-preamble yes。

⚠ 易混：RDB 的 save 配置是"周期+变更数"触发（如 save 900 1 = 900s 内 1 次变更则快照），不是定时；AOF 的 appendfsync everysec 是"每秒刷盘"，不是每秒写一次（写是实时的，刷盘每秒）。

4. 高可用三种架构

Cluster 核心：

• 16384 个槽位（hash slot），CRC16(key) % 16384 定位槽
• 每节点负责一部分槽，节点间 Gossip 协议通信
• 客户端缓存槽→节点映射，MOVED 重定向更新
• 最少 3 主 3 从（6 节点）保证高可用
• 无中心，每节点存部分数据 + 集群元数据

⚠ 易混：Redis Cluster 用固定槽位分片（CRC16 取模 16384），不是一致性哈希！虽类似但本质不同，扩容需手动迁移指定槽。

哨兵 Sentinel 故障转移：主观下线与客观下线（软考高频）

哨兵通过两阶段故障发现 + 领导者选举 + 故障转移四步完成主库自动切换，核心是 SDOWN → ODOWN 升级机制。

① 主观下线（Subjectively Down, SDOWN）

• 定义：单个哨兵主观判定某 Redis 实例下线
• 判定：哨兵每秒向实例发 PING，若在 down-after-milliseconds（默认 30s）内未收到有效回复，该哨兵单方面标记实例为 SDOWN
• "主观"含义：仅代表这一个哨兵的看法，可能误判（如该哨兵与实例间网络抖动，但实例实际正常、其他哨兵能正常通信）
• 后续：SDOWN 不直接触发故障转移，需升级为 ODOWN

② 客观下线（Objectively Down, ODOWN）

• 定义：足够多哨兵达成共识，客观判定某实例下线
• 判定：某实例被标 SDOWN 后，哨兵通过 Gossip 协议询问其他哨兵，若有 ≥ quorum 个哨兵都报告该实例 SDOWN，则升级为 ODOWN
• "客观"含义：多哨兵投票共识，降低单点误判风险
• 后续：ODOWN 后发起领导者选举（Raft-like，需多数派哨兵同意），选出的 leader 哨兵执行故障转移

③ 故障转移执行（leader 哨兵）

1. 在从库中选最优者提升为新主：优先级（slave-priority）高 → 复制偏移量大（数据新） → runid 小
2. 提升该从库为新主库（SLAVEOF NO ONE）
3. 通知其他从库复制新主库
4. 通知客户端主库地址变更（通过 pub/sub 通知）

SDOWN vs ODOWN 对比：

quorum 参数：

• 配置：sentinel monitor <master-name> <ip> <port> <quorum>
• 含义：判定 ODOWN 所需最少哨兵同意数
• 建议：quorum = 哨兵总数/2 + 1（多数派），如 3 哨兵设 quorum=2
• ⚠ 区分：quorum 用于判定 ODOWN（故障发现）；哨兵数/2+1 用于领导者选举（故障转移执行）

完整流程图：

哨兵A PING 主库 → 超时(down-after-milliseconds)未回复
  → 哨兵A 标记主库 SDOWN（主观，单方面）
  → 哨兵A 通过 Gossip 问其他哨兵
  → ≥ quorum 个哨兵都报告 SDOWN
  → 升级为 ODOWN（客观，共识）
  → 哨兵集群选举 leader（Raft-like，多数派）
  → leader 执行故障转移（选最优从库提升为主）
  → 通知客户端主库地址变更

⚠ 软考易考点：

1. SDOWN 是单哨兵主观判断，ODOWN 是多哨兵客观共识
2. ODOWN 需 ≥ quorum 个哨兵同意
3. SDOWN 不触发故障转移，ODOWN 才触发（且需先选 leader）
4. quorum 通常 = 哨兵数/2+1（多数派）
5. down-after-milliseconds 是 SDOWN 判定超时阈值
6. 主观/客观下线是故障发现两阶段，领导者选举+故障转移是后两阶段

5. 缓存三大问题及解决

6. 分布式锁四种实现

Redisson 看门狗：默认 30s 锁，每 10s 续期，业务完成才释放；客户端宕机则看门狗停止，30s 后自动过期。

7. 内存淘汰策略 8 种（4.0+）

⚠ Redis 的 LRU 是近似 LRU（采样默认 5 个候选），非严格 LRU，为省内存；LFU 防偶发热点污染（某 Key 偶尔被访问不会长期占位）。

8. Redis 事务（与分布式事务区别，软考易混）

• MULTI 开启 → 多条命令入队 → EXEC 原子执行
• WATCH 实现乐观锁(CAS)，被 watch 的 key 被修改则 EXEC 失败
• Redis 事务不是 ACID 事务：无回滚、无隔离级别、非真原子（单条运行时错误不中断其余）
• Cluster 下事务需同 slot（用 hash tag {tag}），跨 slot 失败

⚠ 易混：Redis 事务（单机命令批处理） ≠ 分布式事务（2PC/TCC/Saga，跨节点原子提交）。

9. 应用场景速查

10. Redis vs Memcached

11. Redis 高频考点（软考选择/案例）

1. 单线程为何快：内存操作 + IO 多路复用(epoll) + 无上下文切换 + 6.0 IO 多线程
2. 跳表为何不用红黑树：实现简单 + 范围查询高效 + 内存可调 + 并发友好
3. Cluster 为何 16384 槽：CRC16 够用且心跳包小；作者原话：心跳包携带槽位 bitmap，16384/8=2KB，节点 200 内性价比最优
4. Pipeline vs 事务：Pipeline 减少 RTT 不保证原子；事务保证原子(同节点)不减少 RTT
5. 缓存与 DB 一致性：延迟双删、binlog 订阅(Canal)刷缓存、Cache Aside(先更 DB 再删缓存)

12. Redis 计算题型（软考可能出）

题型 1：缓存命中率/容量

例：读 QPS=10 万，缓存命中率 95%，DB 单机承载 2 万 QPS，问 DB 是否扛住？
解：DB 读 QPS = 10 万×(1-95%) = 5000 < 2 万，扛住。
变式：命中率降到 80%？DB 读 = 10 万×20% = 2 万，刚好临界，需加 DB 或提命中率。

题型 2：内存容量估算

例：1 亿用户签到 Bitmap，需多少内存？
解：1 亿 bit = 1 亿/8 Byte = 12.5MB。
变式：用 Hash 存 1 亿用户每天签到(365 天)？每用户 365 bit≈46 Byte，1 亿×46B≈4.3GB，远大于 Bitmap。

题型 3：HyperLogLog 误差

例：HLL 统计 UV，实际 100 万，误差范围？
解：标准误差 0.81%，100 万×0.81%=±8100，即 [991900, 1008100]。
变式：合并多个 HLL（PFMERGE），误差不叠加（仍 0.81%）。

题型 4：集群槽位

例：6 主 Cluster，16384 槽如何分？key=“user:123” 路由到哪？
解：6 主均分 ≈ 2731 槽/主；slot = CRC16(“user:123”) % 16384，查槽→节点映射表。
变式：扩容到 8 主，需迁移槽位，每个新主从现有节点迁移约 2048 槽。

题型 5：分布式锁续期

例：Redisson 锁默认 30s，看门狗每 10s 续期，业务执行 45s，锁是否安全？
解：业务 45s>30s，看门狗在 10s/20s/30s/40s 续期，每次重置 30s，业务完成才释放，安全。
变式：客户端宕机，锁何时释放？看门狗停止续期，30s 后自动过期释放。

13. Redis 易混点辨析

14. Redis 避坑实践

15. Redis 双轨口诀

• 顺口溜·数据结构：串列哈集序，流图位超地（String/List/Hash/Set/ZSet/Stream/Bitmap/HLL/Geo）
• 顺口溜·持久化：RDB 快照小快丢，AOF 日志大慢全，混合兼顾生产用
• 顺口溜·高可用：主从读写分，哨兵自动切，集群分片扩
• 顺口溜·三大问题：穿透布隆空值挡，击穿互斥锁重建，雪崩抖动加降级
• 顺口溜·淘汰八策：不退 LRU LFU TTL 随机，挥发全发各四种
• 顺口溜·分布式锁：SETNX 过时不用，SET NX EX 原子加，Redisson 看门狗，RedLock 争议大
• 顺口溜·哨兵故障转移：主观单兵PING超时，客观quorum共识；SDOWN不切ODOWN切，选完leader再换主
• 顺口溜·持久化场景：RDB备份灾恢快加载，AOF安全可改误操作；混合兼顾生产用，everysec默认丢一秒
• 谐音·哨兵下线：主客quorum → 主观(SDOWN单兵)→客观(ODOWN quorum共识)→“主客"联想"主客”（主人客人投票）
• 谐音·五大类型：串列哈集序 → “川列哈集序”（四川列举哈集序）
• 谐音·淘汰策略：不退挥发 → noeviction(不退)+volatile(挥发)+allkeys(全发)
• 谐音·三大问题：穿击崩 → 穿透、击穿、雪崩 → “穿机崩”（穿机崩溃）

十三、一页纸速记总表

附：背诵路线建议

按 理论→分布→事务→产品→选型→Redis→避坑 顺序背诵，配合口诀：

1. 理论层：CAP/BASE/一致性模型 → 口诀"C吃A爱P胖"“B不全S松E终”
2. 分布层：分片/复制/Quorum → 口诀"哈范一目"“W+R>N我认难”
3. 事务层：2PC/3PC/TCC/Saga → 口诀"2T3S本地力"
4. 产品层：NewSQL五将/NoSQL四类/MPP → 口诀"钛海蟑谷高"“K文列图”
5. 选型层：质量属性映射 → 口诀"分复共"
6. Redis层：结构/持久化/高可用/三大问题/锁/淘汰/事务 → 口诀"串列哈集序"“不退挥发”“穿击崩”
7. 避坑层：十大陷阱+Redis十混 → 口诀"C复片事新基N领列"

核心记忆锚点：CAP是纲，BASE是目，Quorum是尺，Paxos/Raft是基，2PC/TCC是术，选型权衡是道，避坑是验；Redis是缓存之王，跳表是其魂，16384槽是其骨，看门狗是其锁。

文档结束·祝软考顺利通过