附录 a 核心参数与数量级速查

本附录是全书 36 章的参数与数量级收敛点，面试前用它做最后一轮记忆校准。

使用说明

本附录只做速查，不重复推导。每个数值都标注了口径或版本区间；机制细节回到对应章节。

A.1 延迟数量级表（面试心算基准）

单位统一为秒的十进制前缀：1 ns = 10⁻⁹ s、1 μs = 10⁻⁶ s、1 ms = 10⁻³ s。倍率列以 L1 缓存命中为 1× 的基准。

常用换算（面试官爱让现场算）：

1
2
3
4
5
6
7
8
9

1 次同机房调用 ≈ 0.3 ms ≈ 300 000 ns
1 次同机房调用 ≈ 3000 次主存访问 ≈ 300 000 次 L1 缓存命中
1 次同机房调用 ≈ 3 次 SSD 随机读（0.1 ms × 3）
1 次机械盘随机读 ≈ 20 次同机房调用
1 次跨大洲调用 ≈ 300 次同机房调用

内存访问墙：约 100 ns
网络墙：同机房约 0.1 ms，跨地域 ≥ 30 ms（光速下限）
磁盘墙：SSD 约 100 μs，机械盘约 10 ms

A.2 Linux 内核参数与资源限制默认值

以下默认值以 Linux 5.x/6.x 主线内核为口径；发行版（尤其是 RHEL 系与容器镜像）常带自己的 sysctl 覆盖，容器里看到的可能是宿主机或 runtime 注入的值。

相关观测命令（口径要对）：

1
2
3
4
5
6
7
8
9

# 看进程真正的软/硬限制，而不是当前 shell 的
cat /proc/<pid>/limits | grep -i 'open files'

# 看内核实际生效的 somaxconn 与队列溢出计数
sysctl net.core.somaxconn
nstat -az TcpExtListenOverflows TcpExtListenDrops

# 脏页回写相关
sysctl vm.dirty_ratio vm.dirty_background_ratio vm.dirty_expire_centisecs

A.3 磁盘与文件系统

A.3.1 ext4 与 xfs 速查

A.3.2 容量与 inode 观测

创建 inode 数量与"平均文件大小"相关：

1
2
3

ext4 默认 inode 数 ≈ 卷容量 / 16 KB（bytes-per-inode 默认 16384）
例：1 TB 卷 ≈ 6553.6 万个 inode
放 100 万个小文件绰绰有余；放十亿级小文件必须显式调小 -i 或改用 xfs

A.3.3 常用挂载选项

A.3.4 RAID 级别对照（含写惩罚）

写惩罚（write penalty） 指一次逻辑随机写引发的物理 I/O 次数，是评估 RAID 随机写 IOPS 的核心：

写惩罚换算有效 IOPS：

1
2
3
4
5
6
7
8
9

RAID5 有效随机写 IOPS ≈ 物理盘 IOPS 总和 / 4
RAID6 有效随机写 IOPS ≈ 物理盘 IOPS 总和 / 6
RAID10 有效随机写 IOPS ≈ 物理盘 IOPS 总和 / 2

算例：8 块盘，单盘 150 随机写 IOPS
RAID5  ≈ (8 × 150) / 4 = 300 IOPS
RAID6  ≈ (8 × 150) / 6 = 200 IOPS
RAID10 ≈ (8 × 150) / 2 = 600 IOPS
结论：数据库随机写场景，RAID10 常以一半容量换两倍以上写 IOPS

A.3.5 IOPS、块大小与队列深度

A.3.6 SSD 写放大与 TRIM

A.4 TCP/IP 参数与常量

A.4.1 报文头与 MTU/MSS

为什么必须做窗口扩大：带宽时延积（BDP）决定"在途数据量"上限。

1
2
3
4
5
6
7

BDP = 带宽 × RTT
100 Mbps × 100 ms = 10 Mb = 1.25 MB 在途
若窗口上限只有 64 KB，则吞吐上限 = 64 KB / 100 ms ≈ 5.2 Mbps
⟹ 链路再快也跑不满，所以 RFC 1323 引入窗口扩大因子

同一链接下的理论上限 = 窗口大小 / RTT
想跑满 1 Gbps、RTT 100 ms，需要窗口 ≈ 12.5 MB，远超 64 KB

A.4.2 TIME_WAIT 与 MSL

A.4.3 RTO 与重传

A.4.4 拥塞窗口与阈值初值

拥塞控制算法要点对照：

正确口径：cwnd 初值 1 个 MSS 出自 RFC 2001，10 个 MSS 出自 RFC 6928（2013 年）。面试答"1 个 MSS"不算错，但必须说清这是旧口径，并补一句"现代实现按 RFC 6928 用 10 个 MSS"。

A.5 MySQL / InnoDB 默认值与关键常量

A.5.1 结构常量

A.5.2 关键参数与丢数据窗口

一处高发口径错误：在 MySQL 8.0.30 之后仍说 innodb_log_file_size 默认 48 MB 属于过时回答。新参数是 innodb_redo_log_capacity，默认 100 MB，它把多个 redo 文件统一成容量管理；老参数在 8.0.30 起被弃用。

A.5.3 redo log 环形结构与两阶段提交

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

redo log 环形结构（write pos 追着 checkpoint 跑）

       checkpoint                       write pos
          ↓                                ↓
  ┌───────┬────────────┬────────────┬──────────┐
  │ 已刷盘 │  可覆盖区域  │  待刷脏页区  │ 可写入区  │
  └───────┴────────────┴────────────┴──────────┘
          └──── 已写入但未刷脏的数据页 ────┘

write pos 追上 checkpoint ⟹ 无处可写 ⟹ 必须停下来推 checkpoint（刷脏页）
⟹ 这是"redo 太小导致写入抖动"的根因

两阶段提交时序（innodb_flush_log_at_trx_commit = 1、sync_binlog = 1）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17

阶段一：redo prepare
  1. 写 redo log，标记 prepare
  2. 刷 redo（fsync）
阶段二：写 binlog
  3. 写 binlog
  4. 刷 binlog（fsync）
  5. 写 redo log，标记 commit（不需要立刻 fsync，靠组提交合并）

崩溃点分析：
  A. 步骤 2 之前崩：redo 无记录、binlog 无记录 ⟹ 事务丢失，一致
  B. 步骤 2 之后、步骤 4 之前崩：
     redo 有 prepare 但无 commit，binlog 不完整
     ⟹ 恢复时发现 redo prepare 但 binlog 缺失 ⟹ 回滚该事务
  C. 步骤 4 之后、步骤 5 之前崩：
     binlog 完整，redo 处于 prepare
     ⟹ 恢复时按 binlog 补提交（commit 该事务）
  判定依据：redo 的 XID 是否出现在 binlog 中

A.5.4 B+ 树树高估算算例

假设：主键 BIGINT 占 8 字节，页内指针占 6 字节，页头/页尾等开销约 100 字节（按 16 KB 页扣减）。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

单页可容纳的键数量：
  每对 (键, 指针) = 8 + 6 = 14 字节
  (16384 − 100) / 14 ≈ 1163，取整约 1170 个键（含页目录等开销的常见口径）

叶子层：每行按 1 KB 估算，一页放 16 行

树高（h 层）可索引的行数：
  非叶层数 = h − 1，每层放大 1170 倍
  h = 1：16 行
  h = 2：1170 × 16 ≈ 1.87 万行
  h = 3：1170 × 1170 × 16 ≈ 2190 万行
  h = 4：约 256 亿行

结论：三层 B+ 树可索引约 2000 万行量级。
查询一次主键等值：3 次页访问；根节点常驻 buffer pool，实际磁盘 I/O 通常只有 0~1 次。

A.5.5 key_len 计算所需的字段宽度

1
2
3
4
5

算例：KEY idx_a (a INT NOT NULL, b VARCHAR(20) NULL) CHARSET utf8mb4
  只用 a：                       4
  a + b：                        4 + (20 × 4 + 2) + 1 = 87
  EXPLAIN 的 key_len = 4  ⟹ 只用到 a
  EXPLAIN 的 key_len = 87 ⟹ a、b 都用到

A.6 Redis 默认配置与阈值

A.6.1 编码转换阈值

1
2
3
4

为什么是 44 字节：
  jemalloc 最小分配档位 64 字节
  redisObject = 16 字节（类型 + 编码 + LRU + 引用计数 + 指针）
  64 − 16 = 48，SDS 头需 3 字节 + 结尾 '\0' 1 字节 ⟹ 可用 44 字节

A.6.2 持久化

A.6.3 内存淘汰策略（八种）

A.6.4 集群、统计与过期删除

另一个容易漏的默认值：maxmemory 默认是 0（不限制），此时淘汰策略形同虚设 —— 内存会一直涨到被 OOM killer 杀掉。上线必设 maxmemory + maxmemory-policy，这是缓存服务最容易漏的一步。

A.7 JVM 默认值与关键常量

A.7.1 GC 与堆

1
2
3
4
5
6
7

32 GB 压缩指针分界线的由来：
  压缩指针用 4 字节表示引用，寻址单位是 8 字节（对象对齐）
  2³² × 8 字节 = 32 GB
  ⟹ 堆 ≤ 32 GB 时可寻址全部对象，引用只占 4 字节，缓存友好
  ⟹ 堆 > 32 GB 时改用 8 字节引用，同样的对象图占用更多内存
  ⟹ 所以 31 GB 常比 33 GB 更划算："32 GB 不是上限，是拐点"
  补充：可用 -XX:ObjectAlignmentInBytes=16 把上限提到 64 GB，但有对齐浪费

A.7.2 集合与常量

版本口径要答全：JDK 8 服务端默认 Parallel GC，JDK 9 ~ JDK 20 默认 G1；JDK 21 起分代 ZGC 成为 ZGC 的默认模式（JDK 21 中分代尚需显式开启，JDK 23 起直接默认），所以"JDK 21 默认 ZGC"这句话必须带版本前提才成立。

A.8 分布式与 MQ 关键参数

A.8.1 Kafka

A.8.2 RocketMQ

A.8.3 Raft、Snowflake 与一致性哈希

1
2
3
4
5

取模 vs 一致性哈希（N → N+1 个节点）：
  取模：      键映射几乎全部改变 ⟹ 需迁移约 N/(N+1) 的键（N=9 时约 90%）
  一致性哈希：只有落在新节点环区间的键需迁移 ⟹ 约 1/(N+1) 的键（N=9 时约 10%）

这就是"扩容抖动量级差一个数量级"的由来。

A.8.4 分布式事务方案的不一致窗口

A.9 端口、协议与默认值对照

A.9.1 常用端口

A.9.2 UDP 与 TCP 的使用场景

A.9.3 HTTP 状态码速查（含语义陷阱）

1
2
3
4
5
6
7

502 vs 504 的判据（面试常问"线上大量 5xx 你怎么查"）：
  502 Bad Gateway  ⟹ 网关连不上上游（进程没了 / 端口没监听 / 连接被拒）
  504 Gateway Timeout ⟹ 连上了，但上游在超时时间内没返回（慢查询 / 下游雪崩）

重试语义：
  502、504、503、429 通常可重试（配合退避与幂等）
  400、401、403、404、422 重试无意义，只会放大流量

499 是 Nginx 自定义状态码（客户端提前关闭连接），不是 HTTP 规范的一部分。面试里说"499 表示客户端取消"要带上"Nginx 定义"这个限定。

A.10 一句话记忆锚点

• 归零不是删除：deleted 标记位只是隐藏，purge 才真删。
• %util 不是利用率：队列非空即接近 100%，并发 I/O 下会失真。
• RR 的幻读只在当前读出现，快照读靠 ReadView 天然防幻读。
• show index 看的是基数不是精确值，Cardinality 是采样估算。
• ABA 用版本号，不是再比一次值。
• Time Wait 属于主动关闭方，服务端堆 TIME_WAIT 说明它先关的。
• CLOSE_WAIT 堆积是代码没 close，与内核参数无关。
• MSS 在传输层、分片在网络层，两者不可互换。
• RTO 有最小值 200 ms，别把 RTT 直接当重传超时。
• 快重传靠 3 个重复 ACK，超时重传才是最后手段。
• cwnd 初值 10 个 MSS 是 RFC 6928 的现代口径。
• 窗口扩大因子最大 14，上限是 65535 × 2¹⁴。
• vm.swappiness = 0 不等于禁用 swap。
• overcommit = 1 会让 malloc 骗过你，触碰时才 OOM。
• dirty_ratio 触发同步回写，dirty_background_ratio 是异步。
• RAID5 随机写惩罚为 4，RAID6 为 6，RAID10 为 2。
• %i 用满也会 No space left，df -h 看不出来。
• du 与 df 不一致：删了文件但进程还持有。
• noatime 几乎无副作用，是低风险高收益的挂载项。
• innodb_redo_log_capacity 默认 100 MB，8.0.30 起取代旧参数。
• redo 是环形，write pos 追上 checkpoint 就得停下来刷脏。
• 两阶段提交靠 XID 对齐，binlog 有就补提交。
• 三层 B+ 树约 2000 万行，根节点常驻内存。
• key_len 可空加 1、varchar 加 2、utf8mb4 乘 4。
• RR 是 MySQL 默认，PostgreSQL 默认是 RC。
• innodb_lock_wait_timeout 默认 50 s，超时不等于回滚。
• hash 128 条 64 字节是 listpack 转 hashtable 的界。
• String 44 字节是 embstr 与 raw 的分界。
• maxmemory 默认 0，不设淘汰策略等于没设。
• 16384 槽让集群心跳位图只有 2 KB。
• HyperLogLog 误差 0.81%，固定 12 KB。
• 32 GB 是压缩指针拐点，不是堆内存上限。
• MaxTenuringThreshold 默认 15，因为年龄位只有 4 位。
• MetaspaceSize 是首次 GC 阈值，不是初始大小。
• HashMap 树化 8、退化 6、最小容量 64。
• Integer 缓存 -128~127，超出即新对象。
• acks=all 必须配 min.insync.replicas，否则等于 acks=1。
• HW 取 ISR 最小 LEO，消费者只能读到 HW。
• 18 级延时消息是 RocketMQ 的固定档位。
• 选举超时要大于 10 倍心跳，否则选主抖动。
• 一致性哈希扩容迁移约 1/(N+1)，取模是 N/(N+1)。
• 502 是连不上，504 是等超时。
• 301 会被缓存，短链要用 302 保留统计。
• 401 是没认证，403 是没权限。

附：本附录的口径与版本约定

延伸阅读

• RFC 793《Transmission Control Protocol》、RFC 6298《Computing TCP’s Retransmission Timer》、RFC 6928《Increasing TCP’s Initial Window》、RFC 5681《TCP Congestion Control》。
• Linux 手册页：man 7 tcp、man 5 proc、man 8 sysctl、man 5 limits.conf。
• MySQL 官方手册：InnoDB 参数、InnoDB 事务模型与锁、innodb_redo_log_capacity 变更说明。
• Redis 官方文档：内存优化（memory-optimization）、持久化、集群规格（cluster-tutorial）、键过期（EXPIRE）。
• Oracle 官方文档：java 命令参考（-XX 选项与默认 GC）、HashMap 与 Integer 的 API 说明。
• Apache Kafka 官方文档：生产者配置（acks、min.insync.replicas、max.in.flight）与复制设计。