Redis 主要提供 RDB（快照持久化） 和 AOF（日志持久化） 以防止数据丢失。

1️⃣ RDB（Redis Database Snapshot）

• 机制：定期快照（Snapshot）存储整个 Redis 内存数据 到磁盘。

• 优点： ✅ 适合 大规模数据恢复（冷启动场景）。 ✅ 影响主线程较小，因为快照由子进程 fork 处理。

• 缺点： ❌ 可能导致数据丢失，因为 RDB 是定期快照，崩溃时会丢失最近的修改。

• 触发方式

  ：

  • SAVE（同步，阻塞）
  • BGSAVE（异步，子进程）
  • save 900 1（900秒内至少 1 次写入）

2️⃣ AOF（Append Only File）

• 机制：记录每次写操作（SET、HSET、INCR）到日志文件，定期重写优化。

• 优点： ✅ 数据更安全，默认 fsync every second，最多丢失 1 秒数据。

• 缺点： ❌ AOF 文件更大，恢复速度较慢。 ❌ 写入操作更多，影响性能。

• 配置方式

  ：

  • appendfsync always（每次写入同步，最安全，最慢）
  • appendfsync everysec（默认，每秒同步）
  • appendfsync no（由 OS 决定同步时机）

跳表的操作

(1) 查找（O(log n)）

假设要查找 20：

1. 从最高层开始，沿着索引层查找，直到找到最接近但不大于 20 的节点。
2. 降级到下一层，继续从该节点往后找。
3. 重复步骤 1-2，直到到底层。

示例（查找 20）：

lessCopyEditLevel 4:  [1]---------------------->[50]   (跳过)
Level 3:  [1]--------->[10]-------->[50]   (跳过)
Level 2:  [1]-->[5]-->[10]-->[20]-->[50]   (找到)
Level 1:  [1] -> [2] -> [3] -> [5] -> [10] -> [15] -> [20] -> [50]  (找到)

最终在 Level 2 找到 20，比逐个遍历快得多。

(2) 插入（O(log n)）

插入元素 x 时：

1. 查找插入位置（与查找过程类似）。
2. 随机决定 x 的层级（采用抛硬币策略）。
3. 从底层到对应层级插入 x，并调整索引。

层数如何决定？

采用 随机概率，如果 p = 0.5，则：

• 50% 的概率只出现在 底层。
• 25% 的概率出现在 两层。
• 12.5% 的概率出现在 三层。

这样保证跳表的结构接近平衡二叉树。

(3) 删除（O(log n)）

1. 查找 x 的所有层级位置（与查找过程类似）。
2. 从每层链表删除 x，如果某层的索引变空，则删除该层。

示例（删除 20）：

lessCopyEditLevel 3:        [1]--------->[10]-------->[50]
Level 2:        [1]-->[5]-->[10]--------->[50]  (删除 20)
Level 1:  [1]->[2]->[3]->[5]->[10]->[15]------->[50] (删除 20)

悲观锁（Pessimistic Lock）

假设并发冲突是常态，因此在访问数据前，会强制加锁，防止其他事务修改数据，从而保证数据的安全性。

• 适用于高并发写入时，防止数据被修改（如银行转账）。

• 实现方式：

  • 数据库锁（如 S 锁和 X 锁）
  • 分布式锁（如 Redis 分布式锁、Zookeeper 分布式锁）
  • synchronized 关键字 或 ReentrantLock

  示例：

  javaCopyEditsynchronized(lock) {
      // 访问共享资源
  }
  

乐观锁（Optimistic Lock）

假设并发冲突很少，因此不加锁，而是通过版本号（Version） 或 CAS（Compare And Swap）机制来保证数据的正确性。

• 适用于读多写少的场景，比如商品库存扣减、用户数据修改等。

• 实现方式：

  • 版本号机制（数据库 version 字段）
  • CAS（Compare And Swap） 机制（如 Java AtomicInteger）

  示例（版本号）

  sqlCopyEditUPDATE product
  SET stock = stock - 1, version = version + 1
  WHERE id = 1 AND version = 当前版本;
  

  如果 version 发生变化，表示数据已被修改，更新失败，客户端需要重试。

QUIC（Quick UDP Internet Connections） 是 Google 开发的一种基于 UDP 的传输协议，旨在提高网络传输效率，并解决 TCP 的一些性能问题，特别是在高延迟和丢包环境下。

🔹 QUIC 是 “TCP + TLS + HTTP/2” 的结合体，但它不基于 TCP，而是基于 UDP，并在应用层实现了：

• 连接多路复用
• 0-RTT 连接建立
• 内置加密（TLS 1.3）
• 更好的丢包处理
• 避免队头阻塞

消息队列（Message Queue, MQ）详解

消息队列（MQ）是一种用于异步解耦和流量削峰的架构模式，广泛应用于高并发系统、微服务架构、日志处理、事件驱动系统等。

1. 为什么需要消息队列？

(1) 解耦（Decoupling）

在传统的同步调用中，服务 A 调用服务 B，两者强耦合：

A ---> B

如果 B 发生故障，A 也会受影响。

使用消息队列后，A 只需要发送消息到 MQ，B 异步消费：

A ---> [MQ] ---> B

✅ A 和 B 完全解耦，即使 B 挂掉，消息仍然保留在 MQ 中。

(2) 削峰（Traffic Shaping）

假设秒杀场景：

• 高并发时，数据库 DB 承受瞬间巨大流量，导致崩溃。
• MQ 作为缓冲区，让请求排队，均匀写入 DB：

用户请求  --->  [MQ]  --->  处理服务  --->  DB

✅ 削峰填谷，避免 DB 瞬间过载。

(3) 异步处理

有些任务 不需要同步等待结果（如发送邮件、日志存储），可以异步执行：

A（下单）  --->  [MQ]  --->  邮件服务（异步消费）

✅ 提升系统响应速度。

2. 消息队列的核心概念

3. 消息队列的常见模型

(1) 点对点（P2P，Queue）

• 一个生产者，一个消费者（或者多个消费者竞争消费消息）。
• 消息被消费后即删除，不会被其他消费者再次消费。

Producer  --->  [Queue]  --->  Consumer

✅ 适用于任务队列，如订单处理、秒杀。

(2) 发布订阅（Pub/Sub，Topic）

• 一个生产者，多个消费者。
• 每个消费者都会收到相同的消息。

Producer  --->  [Topic]  --->  Consumer1
                         --->  Consumer2
                         --->  Consumer3

✅ 适用于：

• 日志存储（多个系统订阅日志）
• 事件驱动架构（如用户注册后触发多个操作）

4. 常见的消息队列

5. MQ 可靠性保障

(1) 消息丢失问题

如何保证 MQ **“不丢消息”？ 💡 解决方案： ✅ 生产者保证：

• 消息确认（ACK）：确保 MQ 收到消息，否则重试。
• 事务消息：RabbitMQ、RocketMQ 支持本地事务+回滚。

✅ Broker（MQ）保证：

• 消息持久化（Kafka、RocketMQ 支持 磁盘存储）。
• 多副本机制（Kafka 支持 Leader-Follower 复制）。

✅ 消费者保证：

• 手动 ACK 机制：消费完成后手动确认，否则消息重试。

(2) 消息重复消费

MQ 可能发生“消息重复消费”（如消费者超时未 ACK，被重新投递）。 💡 解决方案： ✅ 幂等性设计：

• 使用 全局唯一 ID，避免重复执行。
• Redis 去重（存储已处理 ID）。

生产者为每条消息生成全局唯一 messageId；消费者在处理前先去 Redis 占坑。 如果占坑成功＝第一次见到 → 允许执行业务；占坑失败＝重复 → 直接 ACK 丢弃。

Redis Key 设计

• mq:processed:{messageId} → 1（设置一个合理 TTL，如 2~7 天 ≥ MQ 最大重试/保留期）

(3) 消息积压

如果消费者消费太慢，消息堆积在 MQ： 💡 解决方案： ✅ 增加消费者数量（提高消费速率）。 ✅ 消息分区（Kafka），让多个消费者并行消费。

6. MQ 在实际业务中的应用

(1) 秒杀系统

✅ MQ 削峰限流，避免数据库崩溃：

用户请求  --->  [MQ]  --->  订单服务  --->  数据库

(2) 订单处理

✅ MQ 解耦，订单创建后异步通知：

下单  --->  [MQ]  --->  库存扣减
                --->  物流通知
                --->  发票系统

(3) 分布式事务

✅ 基于 RocketMQ 的事务消息

1. 生产者发送事务消息（Pending）。
2. 本地事务执行（扣库存）。
3. MQ 确认事务成功，消息才正式投递。

7. MQ 面试常见问题

🔹 MQ 和数据库之间如何保证数据一致性？

✅ 方案 1：本地事务 + MQ

• 先写数据库（本地事务），再发送 MQ 消息。
• 问题：如果 MQ 发送失败，如何回滚？
• 优化：使用 RocketMQ 事务消息，确保最终一致性。

✅ 方案 2：MQ 先发，业务后执行

• 先发送消息到 MQ，再执行业务逻辑（如写数据库）。
• 问题：如果业务失败？
• 优化：使用 MQ 事务消息 或 消息补偿机制。

🔹 Kafka 为什么比 RabbitMQ 吞吐量高？

✅ Kafka 采用 顺序写磁盘 + PageCache 读写（比随机写快 10 倍）。 ✅ RabbitMQ 采用 传统 AMQP 协议，基于 Erlang，消息必须存入内存/磁盘，影响性能。

8. 总结

✅ 消息队列用于解耦、削峰、异步处理。 ✅ 常见 MQ：RabbitMQ（事务）、Kafka（高吞吐）、RocketMQ（事务+金融）。 ✅ 保证消息可靠性（幂等性、事务消息、ACK）。 ✅ 优化高并发场景（秒杀、订单、日志处理）。

💡 面试时重点关注 MQ 的应用、消息一致性、消息丢失、重复消费等问题！ 🚀

InnoDB 的 B+ Tree 实现方式：

• 每个表的 主键索引 是一个 聚簇（clustered index）
  • 数据存储在 B+ Tree 的叶子节点上
  • 叶子节点中不仅有主键，还有整行数据

聚簇索引是一种特殊的索引，它决定了数据在表中的物理存储顺序。 换句话说：

• 表中的数据 按照聚簇索引的顺序存放；
• 索引和数据“长在一起”，索引叶子节点存的就是实际的数据行。

这和普通索引（非聚簇索引）不同，普通索引的叶子节点存放的是“指向数据行的地址（指针/主键）”。

1. 所有数据都在叶子节点，非叶子节点只做索引

• 非叶节点仅存 key，不存 value，单个节点可以容纳更多关键字
• 树高更低，磁盘 I/O 更少

2. 叶子节点天然有序 + 双向链表

• B+ 树叶子节点是按大小排序的链表，支持：
  • 范围查询
  • 区间扫描（WHERE x BETWEEN 10 AND 100）
  • 排序操作（ORDER BY）
• 这是 哈希索引做不到的

3. 更好的磁盘局部性（Cache Friendliness）

• B+ 树的一个节点可以恰好等于一个页（Page）大小（如16KB）
• 一个节点中可存多个 key，一次读入一个节点可以比较多个 key

对比：

• 红黑树一个节点只存一个 key，导致节点数量多，树高更高，磁盘访问更频繁。

4. 查询效率稳定

• 所有数据都在叶子节点，查找路径长度固定，便于优化缓存
• 即使更新/删除也不会大幅度破坏树的平衡性

B+树是一种多路搜索树（多叉平衡树），它的特点包括：

• 每个节点最多有 m 个子节点（m阶 B+树）
• 所有叶子节点高度一致，数据都存储在叶子节点
• 非叶子节点只存索引，不存数据

B+ 树在 插入或删除 时可能导致以下变化：

1. 插入

• 如果目标页（节点）有空间：直接插入，树结构不变
• 如果页满了：分裂节点（Split），只影响当前页和父节点，局部变化

2. 删除

• 如果删除后页还能维持最小占用：直接删除，不动结构
• 如果删除导致页“太空”（小于一半）：
  • 尝试向兄弟节点借数据
  • 如果兄弟也太小：合并节点（Merge）
  • 最多会调整当前页及其父节点，仍是局部影响

🔍 一、B 树 vs B+ 树 的核心区别

磁盘访问友好：每次 I/O 更值钱

数据库核心瓶颈是 磁盘 I/O（即页读写）：

• B 树：节点数据量少，树高更高 → 访问磁盘次数更多
• B+ 树：非叶节点只存 key，一个节点可以存 更多 key
  • → 树更矮
  • → 查找路径更短
  • → I/O 次数更少

👉 每次磁盘访问能用得更“值”，性能高

查找路径更稳定统一

• B 树：查找可能在叶子，也可能在中间节点
  • → 缓存命中复杂，优化困难
• B+ 树：所有查找都到叶子节点终止
  • → 查找路径一致、稳定，便于 统一优化 和 预读缓存

数据更容易批量读入内存

由于叶子节点是链表有序排列：

• B+ 树支持顺序预读，可以一次性将多个连续页加载入内存
• 利于处理 ORDER BY、范围查询、分页等操作

HashMap 是 Java 中最常用的集合之一，其底层结构结合了 数组（Array） 和 链表（LinkedList），从 Java 8 开始还引入了 红黑树（Red-Black Tree） 来优化性能。

计算 hash 值：

int hash = hash(key);  // 通过扰动函数计算 hash

定位数组下标：

index = (table.length - 1) & hash;  // 取模（效率高）

处理冲突：

• 如果该位置为空，直接放入；
• 如果已存在节点（哈希冲突）：
  • 使用 equals() 判断 key 是否相同，相同则覆盖；
  • 否则，添加到链表尾部或插入到红黑树中。

链表转红黑树的条件：

• 链表长度 ≥ 8 且数组长度 ≥ 64 时，链表 → 红黑树；
• 反之，如果树节点数量降到 6 以下，则红黑树 → 链表。

✅ 1. 缓存穿透（Penetration）

📌 定义：

用户请求的数据 在缓存中查不到，数据库中也没有，请求不断打到数据库上。

布隆过滤器（Bloom Filter）是一种非常经典的概率型数据结构，常用于集合成员测试（判断一个元素是否在集合中）。

🌱 基本定义

• 目标：快速判断“某个元素是否存在”。
• 特点：
  1. 可能会误判存在（False Positive）：说“在集合里”但可能其实不在。
  2. 绝不会误判不存在（No False Negative）：如果说“不在”，那一定真的不在。

换句话说： 👉 “不在”=100% 准确； 👉 “在”=有一定概率错误。

⚙️ 它是怎么工作的？

1. 准备一个长度为 m 位的位数组（初始全是 0）。
2. 定义 k 个哈希函数。
3. 当要插入元素时：
   • 用这 k 个哈希函数分别计算位置，把位数组相应位置标记为 1。
4. 当要查询元素时：
   • 同样用这 k 个哈希函数算位置，检查对应的位是否都是 1。
   • 如果有某个位是 0 → 一定不在集合。
   • 如果全部是 1 → 可能在集合（但可能是多个元素“凑巧”碰撞导致的误判）。

✅ 2. 缓存击穿（Breakdown）

📌 定义：

某个热点 key 失效，此时大量请求打到数据库上。

✅ 3. 缓存雪崩（Avalanche）

📌 定义：

大量 key 同时过期或 Redis 故障，导致请求全部打到数据库上。

✅ Redis 不会“立即”删除过期 key，而是通过“定时 + 惰性 + 定期”三种策略组合实现的。

✅ 1. 惰性删除（Lazy Deletion）【核心机制】

当客户端访问某个 key 时，Redis 会检查该 key 是否已过期，如果过期了就立刻删除。

📌 特点：

• 性能开销小，只有在访问时才检查
• 但缺点是：不会主动清除未访问的过期 key

✅ 2. 定期删除（Active Expire Cycle）

Redis 每隔一定时间（默认 100ms）随机抽取一批设置了过期时间的 key 进行检查和删除。

📌 特点：

• 通过采样 + 限时循环控制 CPU 占用
• 删除频率越高，Redis 删除过期 key 越及时

每个带过期时间的 key，会被存入一个“过期字典（expire dict）”中：

• 主字典（dict）保存 key-value 对
• 过期字典（expire dict）保存 key 的过期时间戳（以毫秒为单位）

🔍 当 Redis 执行任何操作如 GET/SET，先检查 expire dict 决定是否已过期。

synchronized 是 JVM 层面的原生锁机制，简单但功能有限； Lock 是 Java API 提供的显示锁接口，更灵活、功能更强。

🔐 一、synchronized 的优化机制（JVM 层优化）

synchronized 在 JDK 1.6 以后性能大幅提升，主要得益于 JVM 实现的 “锁升级策略”：

🚦 偏向锁 → 轻量级锁 → 重量级锁

🟢 1. 偏向锁（Biased Lock）

✅ 场景：

• 单线程反复进入同步块（比如只有一个线程访问某个对象）

✅ 原理：

• 对象的头部（Mark Word）中记录线程 ID
• 下一次进入同步块时，如果还是同一个线程，无需再加锁（认为偏向该线程）

✅ 优点：

• 完全不加锁，无需 CAS 操作 → 性能几乎等于无锁

❌ 缺点：

• 如果其他线程来竞争，就需要升级为轻量级锁（产生成本）

🟡 2. 轻量级锁（自旋锁）

✅ 场景：

• 多线程访问，但不存在真正的并发竞争

✅ 原理：

• 每个线程会在进入 synchronized 时尝试用 CAS 将对象头的锁信息改成指向自己的栈帧（Lock Record）
• 如果 CAS 成功 → 获得锁
• 如果 CAS 失败 → 说明有竞争，进入自旋阶段（尝试一段时间后升级为重量级锁）

✅ 优点：

• 使用 CAS 操作避免线程阻塞（减少上下文切换）
• 自旋几次成功 → 快速拿到锁

🔴 3. 重量级锁（Monitor 锁）

✅ 场景：

• 多线程真正同时竞争锁，CAS + 自旋失败

✅ 原理：

• JVM 使用 Monitor（监视器锁） 实现，线程进入阻塞队列（WaitSet）
• 使用操作系统的 互斥量（mutex） 实现线程挂起、唤醒

❌ 缺点：

• 线程上下文切换代价大 → 性能最差89现场

CAS 是一种无锁（lock-free）机制，用于多线程并发下的安全数据更新，核心逻辑是：

👉 “如果内存中的值等于预期值，那么就将其更新为新值；否则什么也不做。”

❓原文：

每个线程会在进入 synchronized 时尝试用 CAS 将对象头的锁信息改成指向自己的栈帧（Lock Record）

✅通俗解释：

👉 你想用会议室，就先试着把门上的牌子改成写你的名字（用 CAS）。 👉 这个“贴牌子”的过程是 原子操作：要么一瞬间贴上成功，要么完全失败。 👉 这个动作就是 CAS：如果门上的名字是空的，就让我贴；不是空的，我就失败。

❓原文：

如果 CAS 成功 → 获得锁

✅通俗解释：

👉 你成功把门上的牌子换成自己的名字，那就说明没人用，你进屋开会就行了（加锁成功）

❓原文：

如果 CAS 失败 → 说明有竞争，进入自旋阶段（尝试一段时间后升级为重量级锁）

✅通俗解释：

👉 如果你发现门上已经贴了别人的名字（锁被别人抢了），你不急着离开，而是先在门口等一等，看看他是不是很快就出来 👉 如果他很快出来了，你就马上贴上你的名字进去（自旋成功） 👉 如果等了几轮他还不出来，你就放弃等，去前台登记排号排队等通知（进入等待队列，升级为重量级锁）

✅ 所以“需要等谁就让谁 join”

• 想让 A 等 B： 在 A 里调用 threadB.join()
• 想让 B 等 A： 在 B 里调用 threadA.join()
• 想让主线程等子线程： 在 main() 中调用 threadX.join()

join() = “等你干完活我再干”

await() 会让线程 挂起等待，直到某个条件满足时，由其他线程通过“通知”唤醒它。

String（字符串类型）

• 是 Redis 中最基础、最常用的数据结构
• 实际上不仅仅能存字符串，还能存数字、二进制、JSON

SET name "Alice"
GET name                 # "Alice"

INCR count              # 自增操作（数值）
APPEND name " Smith"    # 字符串追加

key        →       value
"name"     →       "Alice"
"count"    →       "100"
"token:uid:1" →    "abc123xyz"

List（列表）

• 有序的字符串列表，支持从头部/尾部插入和弹出
• 类似于 Java 的 LinkedList，双端队列

LPUSH queue task1
RPUSH queue task2
LPOP queue       # 出队
RPOP queue       # 出栈

Set（集合）

• 无序、去重的字符串集合
• 自动去重、支持集合运算（交、并、差）

SADD tags "java"
SADD tags "redis"
SISMEMBER tags "java"     # 判断是否存在
SMEMBERS tags             # 获取所有成员

Hash（哈希）

• 类似于对象或字典（Map）结构
• 一个 key 下面可以有多个 field-value 对

HSET user:1001 name "Alice"
HSET user:1001 age 23
HGET user:1001 name       # "Alice"
HGETALL user:1001    

key           →       hash表（field-value对）
"user:1001"   →      {
                        name: "Alice",
                        age: "24",
                        email: "alice@example.com"
                     }

ZSet（有序集合）

• 每个元素关联一个分数（score），元素按分数排序
• 元素唯一，分数可重复

ZADD ranking 100 Tom
ZADD ranking 80 Alice
ZRANGE ranking 0 -1       # 按分数升序返回所有人
ZREVRANGE ranking 0 2

数据结构组成

• 哈希表（dict）
  • 负责存储 成员（member） → 分值（score） 的映射。
  • 用来快速判断某个元素是否存在，以及拿到它对应的分值。
  • 查找复杂度是 O(1)。
• 跳表（skiplist）
  • 负责按照 分值（score） 以及 成员名（member，作为 tie-breaker） 排序。
  • 用来支持范围查找、排名（rank）、按顺序遍历等操作。
  • 插入、删除、范围查找复杂度都是 O(logN)。

Redis 设计得很巧妙： 👉 插入一个元素时，会同时写进 哈希表（方便查找）和 跳表（方便排序和范围操作）。 👉 删除时，也会在这两个结构里都删掉。

1. HashMap 扩容时链表转红黑树的阈值为什么是 8？退化为 6 的原因？

• 阈值是 8： 当链表长度达到 8 且数组长度 ≥ 64 时，会将该链表转换成红黑树。
  • 原因：
    • 链表查询时间是 O(n)，而红黑树是 O(log n)，性能更优。
    • 8 是经验值，是在性能与空间权衡下选择的折中值。太小容易浪费内存，太大性能劣化。
• 退化为 6： 当链表长度从红黑树缩减到 ≤ 6（并且容量不能再缩小时），会退化回链表。
  • 原因：
    • 树结构维护成本较高，小规模数据不值得用树。
    • 防止频繁转换造成抖动，设置 6 是为了避免边界频繁变化。

🔹3. G1 垃圾回收器如何预测停顿时间？

• G1 的目标是控制每次 GC 的最大停顿时间，如设置 -XX:MaxGCPauseMillis=200。
• 预测机制：
  • G1 会根据历史数据统计回收每个 Region 所需的时间。
  • 然后选择一组 Region，使得总回收时间不会超过目标。
• 通过以下因素预测：
  • Region 的类型（Eden/Survivor/Old）
  • 之前回收该类型 Region 所花时间
  • 活跃数据比例
  • 并行线程数量

4. Region 大小如何设置？

• G1 会自动设置 Region 大小，默认范围是 1MB 到 32MB，总共 2048 个 Region。
• 可以手动设置：

🧠 一、什么是“可见性”？

在并发编程中，“可见性”指的是：

一个线程对共享变量的修改，能否被其他线程立即看见。

如果没有保证可见性，就可能出现：

• 线程 A 修改了某个变量的值，
• 线程 B 却仍然看到旧值（因为缓存没有刷新）。

❓二、volatile 能做什么？

java


CopyEdit
volatile int a;

• 保证：
  • 写操作后，其他线程能立即看到新值（可见性）
  • 禁止指令重排序
• 不保证：
  • 操作是原子的（比如 a++）

🔹6. ThreadLocal 内存泄漏的根本原因？JDK 改进方案？

• 根本原因：
  • ThreadLocalMap 的 key 是弱引用（WeakReference<ThreadLocal>），value 是强引用。
  • 当 ThreadLocal 对象被回收，但线程未结束时，value 会一直存在于 Thread 中，无法访问但无法回收 → 泄漏。

6. ThreadLocal 内存泄漏的根本原因？JDK 改进方案？

• 根本原因：
  • ThreadLocalMap 的 key 是弱引用（WeakReference<ThreadLocal>），value 是强引用。
  • 当 ThreadLocal 对象被回收，但线程未结束时，value 会一直存在于 Thread 中，无法访问但无法回收 → 泄漏。
• 改进方案（JDK 8 及以后）：
  • ThreadLocalMap 的 set()、remove()、get() 都会自动清理 key 为 null 的 entry。
  • 但仍然推荐使用后显式调用 remove()：

⚠️ 四、ABA 问题

什么是 ABA？

一个线程看到 top 还是 A，以为没变，但实际上它已经变成 B 又变回 A —— 导致 CAS 错误成功！

🌰 示例场景：

• 线程 A：读到 top = A，准备 CAS 替换成 X
• 线程 B：把 A 弹出，再压入 A（top 又变成 A）
• 线程 A CAS 成功 → 但中间结构已变 → 数据错乱 ❌

✅ 五、解决 ABA 问题：引入版本号（stamp）

✅ 背景问题：缓存与数据库如何保持一致？

我们常见的一致性策略是：

写库的时候，把缓存删了

比如你要更新一个商品价格：

1. 更新数据库价格
2. 删除 Redis 缓存中的这条数据（如 item:12345）

这是典型的：更新数据库 + 删除缓存

❗但是，这种方式会在高并发下出问题！

❓为什么会出问题？——读写并发冲突

假设发生如下时序：

cssCopyEdit1. 请求 A：更新商品价格（update DB）
2. 请求 B：读取商品信息（从 Redis）
3. 请求 A：删除缓存

❗风险点：

• 请求 B 在缓存删除之前读取了旧数据（缓存未失效）
• 此时请求 B 会把旧数据写回 Redis（如果设置了缓存穿透保护）
• 结果就是：缓存数据比数据库还旧，形成“脏缓存”！

✅ 怎么解决？——延迟双删机制！

📌 核心思路：

删两次缓存，中间隔一段时间（比如 1 秒）再删一次。

✅ 延迟双删流程如下：

markdownCopyEdit1. 更新数据库（保证源数据正确）
2. 删除缓存（第一次）
3. 等待一段时间（如 1 秒）
4. 再删一次缓存（第二次，防止并发脏读）

这样，即使中间有并发读操作把旧值写回缓存，第二次删除也会清掉它。

为什么三者不能同时满足？

因为 一旦发生网络分区（P），你必须在 C 和 A 之间做出权衡。

情况一：选择 CP（放弃 A）

• 系统保证数据一致性，但部分请求会因为分区而失败或挂起（牺牲可用性）
• 示例：ZooKeeper、Etcd

情况二：选择 AP（放弃 C）

• 系统保证请求可用，但可能返回“旧数据”或不同步的数据（牺牲一致性）
• 示例：DNS、Cassandra、Dynamo、Redis（主从异步）

情况三：选择 CA（放弃 P）

• 只适用于单机系统或网络永不出错的理想环境，现实中几乎不可能实现

事务 = 数据库执行的原子性工作单元

隔离级别 决定事务内部读到的数据一致性 vs 最新性

“不可重复读”不是绝对坏事，取决于业务需求

• 统计、结算 → 通常希望可重复读
• 查询最新状态 → 读已提交也OK

在 Java 的线程池（ThreadPoolExecutor）中，当线程池和任务队列都满了，无法再接收新的任务时，就会触发拒绝策略（RejectedExecutionHandler）。

单库/单表的性能瓶颈：

• 数据量大（单表千万行后查询效率急剧下降）
• 单表索引过多，维护开销大
• 主从复制延迟无法满足写入压力
• 数据库连接数限制
• 事务锁冲突严重

🔥 分库分表的目标：

• 降低单表数据量 → 提高查询性能
• 减少热点数据竞争
• 支撑高并发、高可用、高可扩展性

虚拟内存是一种操作系统提供的机制，它让每个进程都认为自己拥有一整块连续、完整的内存空间，实际上这些地址被映射到物理内存 + 硬盘中的某些区域。

就像一个人租了一整层楼（4GB 虚拟空间），但实际上只住了一间（实际使用的物理页），其他的房间（地址）可能在仓库（硬盘），需要时再搬进来。

Hash的计算 int h = key.hashCode(); int hash = h ^ (h »> 16); // 扰动，混合高低位 目的：把 hashCode() 的 高位信息下沉，避免只用低位导致分布不均。

你能做的“避免/减轻碰撞”的手段

• 写好 hashCode/equals
  • 相等对象必须同 hashCode；确保哈希分布均匀（别只用一两个字段，别返回常数）。
  • Key 不要可变（放入后改变字段会“找不着”）。
• 合适的容量与装载因子
  • 预计元素数 m → 预估容量 cap ≈ ceil(m / loadFactor)，让它 接近且不超过阈值，降低链长/树化概率。
  • 例如：要放 10w，cap ≈ 100000 / 0.75 ≈ 133334，构造时会向上取 2 的幂（tableSizeFor）。
• 选择分布更好的 Key
  • 比如用不可变、离散性强的 ID（UUID/雪花），或为业务复合 Key 设计合理哈希。
• 避免过度装载
  • 装载因子越大越省内存但碰撞越多；对延迟敏感场景可降到 0.5。
• 必要时选别的容器
  • 高并发用 ConcurrentHashMap；极端低冲突需求可考虑开放寻址或布谷鸟哈希（第三方/其他语言）。

扩容（resize）到底干了啥？（JDK 8 细节）

触发条件：size > threshold（阈值 = capacity * loadFactor）

步骤：

1. 新表容量 = 旧容量 * 2（到上限 1<<30）。
2. 阈值同步翻倍（newThreshold = newCap * loadFactor）。
3. 重新分布每个桶的节点，但不重算完整哈希：
   • 关键位是 oldCap 这个二进制最高新增位。
   • 对桶内每个节点，看 (node.hash & oldCap)：
     • 为 0 → 留在原 index；
     • 为 1 → 去新位置 index + oldCap。
   • 这样把一个桶 一分为二，且 保持相对顺序。树节点用 TreeNode.split 对应拆分。

复杂度：一次 resize 需要把每个桶走一遍，O(n)；但均摊到多次插入，平均摊销仍近似 O(1)。

初始容量、装载因子、阈值

• 默认初始容量：16（懒分配；第一次 put 时分配）。
• 默认装载因子：0.75（时间/空间的折中）。
• 阈值：threshold = capacity * loadFactor，超过就扩容。
• 最大容量：1 << 30。

静态代码块的执行顺序规则

1. 父类 → 子类（先执行父类的静态代码块，再执行子类的）
2. 同一个类中：
   • 按源码出现顺序执行： 静态变量显式赋值 和 static {} 是合并在一起、从上到下依次执行的
   • 不区分“变量赋值”和“静态块”优先级，谁在前谁先执行
3. 执行完静态部分 → 再执行构造代码（构造代码块 & 构造方法）

JVM 加载一个类时，会按以下顺序执行：

1. 加载（Loading） → 读 .class 文件进内存
2. 验证 / 准备 / 解析（Linking） → 给静态变量分配内存并设默认值（不是赋初值）
3. 初始化（Initialization） → 执行静态变量的显式赋值 & static {} 静态代码块（按源码顺序）

初始化阶段才会执行静态代码块，且只会执行 一次（类第一次主动使用时）。

• AVL 树：
  • 插入/删除后可能触发多次旋转（O(log n) 最坏需要旋转 log n 次）
  • 维护平衡的代价更高
  • 适合查找多、更新少的场景
• 红黑树：
  • 插入/删除后旋转次数少（最多 2 次）
  • 恢复平衡的成本低
  • 更适合插入/删除频繁的场景（工业界普遍选择）

什么是慢查询

• 在 MySQL 里，long_query_time（默认 10 秒）以上的 SQL 会被记录到 慢查询日志。
• 慢查询通常意味着：扫描数据量大、索引失效、执行计划不佳、锁等待等。

SELECT s.name, c.class_name FROM students s INNER JOIN classes c ON s.class_id = c.id; 结果（只显示匹配的行，class_id=3 的 Carol 被过滤掉）：

name class_name Alice Math Bob English

单例模式（Singleton Pattern）是一种创建型设计模式，它的目标是：

在整个程序运行期间，某个类只会被创建一个实例，并且提供一个全局访问点。

为什么要用单例模式

• 全局唯一性：某个对象在业务上只需要一个（如配置管理器、线程池、日志管理器、数据库连接池等）。
• 全局访问：程序中任意位置都能方便访问这个实例。
• 节省资源：避免重复创建和销毁带来的性能开销。

核心特点

1. 构造方法私有化：外部不能直接 new。
2. 类内部持有一个静态实例。
3. 提供一个静态方法/属性获取实例。

可重入锁（Reentrant Lock） 的意思是：

👉 同一个线程 在已经持有锁的情况下，可以再次获取这把锁，而不会发生死锁。

1. 为什么要可重入？

假设我们有下面的情况：

public synchronized void outer() {
    inner();  // inner() 也需要同一把锁
}

public synchronized void inner() {
    // do something
}

• outer() 被某个线程调用时，已经获取了对象锁。
• 在执行过程中又调用了 inner()，如果没有“可重入”机制，那线程会被自己阻塞住 → 死锁。
• 有了可重入锁后，线程在调用 inner() 时发现“这把锁自己已经持有了”，就可以 直接再次进入，锁的计数器 +1。 vvvvvvvvvvvv

1️⃣ 红黑树是什么

红黑树（Red-Black Tree）是一种自平衡二叉搜索树（BST），用于在插入、删除等操作后依然保持近似平衡，以保证查找、插入、删除的时间复杂度都是 O(log n)。

它的特点是给每个节点加了一个颜色属性（红或黑），并且必须满足一定的红黑性质。

2️⃣ 红黑树的五条性质（保持平衡的关键）

假设 NIL（叶子外部的空节点）视为黑色：

1. 每个节点非红即黑
2. 根节点是黑色
3. 所有叶子节点（NIL）是黑色
4. 红色节点的子节点必须是黑色（不能有两个连续的红节点）
5. 从任一节点到其所有后代叶子的路径上，黑色节点数量相同（黑高一致性）

这五条性质共同作用，防止树在操作后退化成链表。

3️⃣ 它如何保持平衡

红黑树通过局部调整 + 颜色翻转保持平衡，调整策略主要有：

• 颜色翻转（Color Flip） 当父节点和叔叔节点都是红色时，将父和叔改成黑色，祖父改成红色（可能需要继续向上调整）。
• 旋转（Rotation） 分为左旋（Left Rotate）和右旋（Right Rotate），用于减少某一侧过深的高度。
  • 左旋：让右子树上移，适用于右倾情况。
  • 右旋：让左子树上移，适用于左倾情况。

插入和删除时会触发这两种操作的组合：

• 插入：先按 BST 规则插入为红色 → 如果违反性质 4 或 5 → 旋转/变色修正。
• 删除：如果删除黑色节点会破坏黑高 → 通过兄弟节点变色、旋转修正黑高。

红黑树并不是“完全平衡”的，而是保证最长路径不超过最短路径的两倍，足以保证 O(log n) 的性能。

2️⃣ 程序运行 & 虚拟内存分配

1. 加载器（Loader）
   • 程序运行时，操作系统把可执行文件的各个段（代码段、数据段、BSS 段等）映射到进程的虚拟地址空间。
   • 给栈和堆分配虚拟地址区域。
2. 变量地址
   • 你在代码里看到的“地址”其实是 虚拟地址（VA），进程自己看到的是连续的地址空间。

3️⃣ 虚拟地址到物理地址的转换（MMU & 页表）

1. CPU 访问变量时，会把虚拟地址交给 内存管理单元（MMU）。
2. MMU 通过 页表（Page Table） 查找虚拟页号 → 物理页号的映射。
   • 页表存在内存中，但 页表缓存（TLB, Translation Lookaside Buffer）里可能已经有了映射。
3. 如果 TLB 命中 → 直接得到物理地址。 如果 TLB 未命中 → 硬件/操作系统查页表；若该页不在内存，还会触发缺页中断，从磁盘加载。

4️⃣ 物理地址到 CPU 缓存/内存访问

1. 拿到物理地址后，CPU 会先查 多级缓存（L1 → L2 → L3）：
   • 如果缓存命中（cache hit） → 直接取值，延迟很低（L1 只有几个 CPU 周期）。
   • 如果缓存未命中（cache miss） → 去下一层缓存，最后可能访问主存（几十到几百个 CPU 周期）。
2. 如果数据不在内存（比如被换出到磁盘的 swap 区） → 操作系统触发磁盘 I/O 把数据页读回内存。

原子类（AtomicInteger、AtomicLong、AtomicReference 等）底层的核心是 CAS（Compare-And-Swap/Compare-And-Set） + volatile 保证可见性 + Unsafe 类直接操作内存。我帮你分成几个层面解释：

1. 原子类的组成原理

1.1 CAS（比较并交换）

• 逻辑：

  1. 读取当前值（旧值 oldValue）
  2. 比较当前值是否还是 oldValue
  3. 如果是，更新为新值 newValue
  4. 如果不是，说明被其他线程改过，更新失败，重新尝试

• 类似于：

  “你柜子里现在是苹果3个吗？是的话我就换成4个，不是就放弃这次改。”

• 硬件支持： 通过 CPU 指令（如 x86 的 CMPXCHG）保证这个操作是原子的，执行过程中不会被打断。

1.2 volatile 保证可见性

• 原子类内部用 volatile 修饰值（如 private volatile int value;）
• 确保一个线程修改 value 后，其他线程立刻能看到最新值（避免 CPU 缓存里的旧值）。

1.3 Unsafe 类直接操作内存

• AtomicInteger 内部用 sun.misc.Unsafe 来直接访问对象内存地址。
• Unsafe.getAndAddInt(Object obj, long offset, int delta) 等方法调用底层 CAS。
• offset 是变量在对象中的内存偏移量，通过 Unsafe.objectFieldOffset 获取。

Java GC（复制算法，Copying GC）里分两个区的原因、好处和缺点我帮你分开说一下，你就能完全理解了。

1️⃣ 为什么要分两个区

复制算法的核心思想是：

只在一块区域分配对象，回收时将存活对象复制到另一块空区域，然后一次性清空原区域。

在 HotSpot 的 新生代（Young Generation）里，这两个区就是 From 区 和 To 区（有时候还会加一个 Eden 区，形成 Eden + From + To 的组合）。

原因：

1. 避免内存碎片化
   • 复制算法直接把活对象压缩到另一块连续内存，剩下的整块空间一次性清掉，内存自然是连续的，没有碎片。
2. 分配速度快
   • 复制后，下一次分配只要用指针碰撞（Bump-the-pointer），即从连续内存的头部往后分配，速度很快，不需要复杂的空闲链表。
3. 实现简单
   • 不用维护空闲块列表，只需要知道From → To怎么切换。
4. 适合新生代高回收率场景
   • 新生代对象朝生夕死，存活率低，大部分空间一次清空，复制成本低。

2️⃣ 为什么是两个区（而不是一个区就直接移动）

如果只有一块区域：

• 你在移动存活对象的时候，很可能会覆盖还没复制过的对象，导致数据丢失。
• 有两个区的话，可以保证：
  • From 区：本次 GC 的扫描源
  • To 区：新放置存活对象的目标区
  • 这样就不会出现数据被覆盖的情况，复制过程安全可控。

3️⃣ 缺点

1. 浪费一半空间
   • 因为必须留出一块空的 To 区来接收对象，意味着同一时间只有一半的新生代可用。
   • 例如新生代 100MB，From + To 各 50MB，实际能用的只有 50MB。
2. 存活对象多时，复制成本高
   • 如果存活对象很多（比如老年代迁入的对象、长生命周期对象），复制算法的效率就下降，因为需要挨个复制。
   • 这也是为什么它适合新生代而不适合老年代。
3. 内存利用率低
   • 在内存紧张的环境下，浪费 50% 会很明显，不如标记-整理（Mark-Compact）节省空间。
4. 需要额外的写屏障处理跨区引用
   • 年轻代 GC 时，如果老年代对象引用了年轻代对象，需要做Card Table 记录，否则复制时会漏掉引用。

1️⃣ 栈（Stack）

• 方向：向低地址增长（地址从大往小走）
• 原因：
  • 栈是连续的内存区域，主要用于存储局部变量、函数参数、返回地址等。
  • 大多数体系结构（如 x86、x86_64）规定栈顶指针（SP/ESP/RSP）往低地址移动来分配空间，往高地址移动来释放空间。

2️⃣ 堆（Heap）

• 方向：向高地址增长（地址从小往大走）
• 原因：
  • 堆是用于动态分配的内存（malloc / new）。
  • 在大多数系统上，堆的起始地址在程序数据段（BSS / data segment）之后，分配新内存时向高地址扩展。

Redis 一般怎么用？在论坛里的落地清单

1) 缓存与反压

• 对象缓存：帖子详情 post:{id}（HASH/STRING）、评论详情 comment:{id}（HASH）。
• 列表/排序缓存：帖子列表、热帖榜、评论列表（ZSET）。
• 多级缓存：本地 Caffeine + Redis，先本地后远程。
• 缓存策略：
  • TTL + 随机抖动（防雪崩）
  • 缓存空值（防穿透）
  • 互斥锁 / 单航标记（防击穿）：SETNX lock:xxx 60s，回源建缓存后释放。

2) 计数与排行榜

• 阅读数、点赞数、评论数：HINCRBY / INCRBY；
• 日/周/月热榜：ZINCRBY hot:post:20250814 postId 1，周期性 ZUNIONSTORE 汇总；
• 评论热度：同理维护 post:{postId}:top。

3) 用户态功能

• 会话/Token：session:{token} -> userId（TTL）；
• 限流：令牌桶 / 漏斗（Lua 实现原子扣减）；
• 去重幂等：SETNX processed:{bizId}，处理成功再 EXPIRE；
• 关注/订阅：SADD follow:{userId}；时间轴 ZSET feed:{userId}（按时间/权重推送）。

4) 搜索与推荐的辅助

• 倒排/轻检索：小规模标签/关键词用 SET/ZSET 拼接；大规模还是上 ES。
• 相似帖子候选：临时集合运算（SINTER, SUNION）做粗筛，细排在服务内完成。

5) 消息与异步

• 通知（评论/回复/点赞）：
  • 使用 Redis Streams：XADD notif:events * {...}；消费者组做多实例消费，保证可追溯；
  • 或 Pub/Sub（不落盘，轻量）。
• 异步计算热度：把“赞/评论”事件写入 Streams，后台批处理更新 ZSET 分值，降低前台写延迟。

6) 防作弊/风控辅助

• 滑动窗口计数：ZADD act:{user}:{action} ts ts，再 ZREMRANGEBYSCORE 清窗口；超阈值封禁或验证码。
• 布隆过滤器（模块/旁路实现）：阻挡异常 ID 请求，减少穿透。

7) 分布式锁与任务协调

• 短事务锁：SET lock:key val NX PX 30000；释放前校验 val（避免误删别的锁）。
• 大任务建议用 Redlock 或把关键流程改为队列化/状态机，减少锁依赖。

键设计

• 文章被谁点赞（用于去重/查询状态）：like:art:{aid}:users（Set，成员=用户ID）

• 用户点过哪些文章（便于用户页）：like:user:{uid}:arts（Set，成员=文章ID）

• 点赞排行榜/计数：like:rank（ZSet，member=文章ID，score=点赞数）

  也可以不用 ZSet，用 INCRBY like:cnt:{aid} 保存计数；但要做榜单时 ZSet 更方便。

线程不安全

• StringBuilder

线程安全

• StringBuffer （方法加了 synchronized）

线程不安全

• ArrayList
• HashMap
• HashSet
• LinkedList

线程不安全

• ArrayDeque
• LinkedList （作为 Queue 使用时）

线程安全

ConcurrentHashMap

1. Hashtable

• 底层结构：数组 + 链表（和 HashMap 类似）。
• 线程安全实现方式：所有公开的方法（如 put、get、remove）都用 synchronized 修饰。
  • 插入：调用 put 时会锁住整个 Hashtable 对象，只有一个线程能进行插入。
  • 读取：get 也加了 synchronized，读取操作同样需要获得锁。
• 特点：
  • 所有操作互斥（全表锁）。
  • 并发性能差，在多线程场景下容易成为瓶颈。

2. ConcurrentHashMap（JDK 1.8 之后的实现）

• 底层结构：
  • 数组（Node[] table）。
  • 每个桶是一个链表或红黑树（当冲突元素多时会转为红黑树）。
• 线程安全实现方式：
  • 不是简单的全表锁，而是分段锁 + CAS 操作结合。
  • 插入（put）：
    1. 如果桶为空，用 CAS 操作直接插入新节点，避免加锁。
    2. 如果桶不为空，会在桶的头节点上加锁（synchronized），只锁冲突的那个桶。
    3. 当链表过长，会转换为红黑树，在加锁下完成。
  • 读取（get）：
    • 读取操作基本是无锁的（直接通过 volatile 语义保证可见性）。
    • 查找时只要定位到 table[index]，就能遍历链表/红黑树。
• 特点：
  • 读操作非阻塞，性能高。
  • 写操作仅对局部桶加锁，不影响全表。
  • 并发扩容时，采用分段迁移机制，多个线程可以协作完成 rehash。

红黑树是不是平衡二叉树？

• 严格答案：红黑树不是严格意义上的“平衡二叉树”，但它是一种自平衡二叉搜索树。
• 平衡二叉树（AVL 树）：通常指任意节点左右子树高度差不超过 1 的树。
• 红黑树的平衡条件：
  1. 每个节点要么是红色要么是黑色。
  2. 根节点必须是黑色。
  3. 红色节点的子节点必须是黑色（不能有两个连续的红节点）。
  4. 任意节点到叶子节点的路径上，黑色节点数量相同。

这样保证了：

• 红黑树的最长路径不超过最短路径的 2 倍。
• 查询、插入、删除操作的时间复杂度为 O(log n)。
• 相比 AVL 树，红黑树更“松弛”，不追求绝对平衡，但旋转次数更少，插入/删除效率更高。

因此： 👉 红黑树是一种近似平衡的二叉搜索树，而不是严格意义上的平衡二叉树。

总结

• 红黑树：更适合内存中的动态数据结构，保证 O(log n) 操作。
• B+ 树：更适合数据库磁盘存储场景，通过多路分叉和页优化，极大减少磁盘 IO。

单例模式的核心思想是： 👉 保证一个类在整个程序运行过程中只有一个实例，并且提供一个全局的访问点。

换句话说：

• 构造函数被隐藏（私有化），外部不能随意 new。
• 只通过类提供的静态方法（如 getInstance()）来获取唯一的对象。
• 整个系统里不管调用多少次，得到的都是同一个实例。

📦 使用场景

单例常用在需要唯一全局对象的地方，比如：

• 配置类（系统配置只需要一份）。
• 日志类（统一输出日志）。
• 线程池/连接池（复用资源，避免反复创建销毁）。
• 缓存类（全局共享数据）。

1️⃣ 最基础的懒汉模式（非线程安全）

public class Singleton {
    private static Singleton instance;   // 没有提前创建
    private Singleton() {}               // 私有构造函数

    public static Singleton getInstance() {
        if (instance == null) {          // 第一次调用时才创建
            instance = new Singleton();
        }
        return instance;
    }
}

• 特点：按需加载（第一次用到才实例化）。
• 问题：在多线程下可能出现 多个线程同时进入 if，导致创建多个对象 → 不安全。

2️⃣ 加锁版懒汉（线程安全，但性能差）

public class Singleton {
    private static Singleton instance;
    private Singleton() {}

    public static synchronized Singleton getInstance() {
        if (instance == null) {
            instance = new Singleton();
        }
        return instance;
    }
}

• synchronized 保证同一时刻只有一个线程能进入方法。
• 缺点：每次获取实例都要加锁，性能低。

4️⃣ 更优雅的懒汉式：静态内部类

public class Singleton {
    private Singleton() {}

    private static class Holder {
        private static final Singleton INSTANCE = new Singleton();
    }

    public static Singleton getInstance() {
        return Holder.INSTANCE;
    }
}

• Holder 在第一次调用 getInstance() 时才加载，INSTANCE 被创建。
• JVM 保证类加载过程的线程安全。
• ✅ 实现简单、懒加载、无锁，常被认为是懒汉的最佳写法。

1. 明确问题现象

• 用户反馈了什么？接口超时、报错、数据不一致、页面打不开？
• 是否能复现？复现条件是什么？
• 问题范围：是个别用户、某个功能、还是全量受影响？

2. 快速确认影响范围

• 看监控（QPS、RT、错误率、CPU、内存、磁盘、网络流量）。
• 日志中是否有大量异常堆栈？
• 是否只影响某些机房、某些版本或某些服务？

3. 定位问题入口

• 从用户请求入口往下追踪（链路追踪、请求 ID、日志上下文）。
• 先确认网关/负载均衡是否正常，再到应用服务，再到数据库/缓存/下游依赖。

4. 分层排查

• 应用层：看错误日志、线程 dump、进程状态。是否有死锁、GC 频繁、线程池耗尽？
• 中间件层：Redis、MQ、Kafka 是否积压？连接是否超时？
• 数据库层：慢查询、锁等待、连接池耗尽？
• 系统层：CPU 飙高、内存不足、磁盘写满、网络丢包？

5. 验证并复现

• 如果是代码逻辑问题，能否在测试环境复现？
• 如果是配置/数据问题，能否通过对比正常和异常环境找到差异？

6. 应急处理

• 先止血：限流、降级、回滚、扩容，优先恢复服务可用性。
• 再修复：定位根因，修改代码/配置/数据，逐步上线。

7. 复盘与预防

• 总结根因：是代码 bug、依赖故障、配置失误还是流量突增？
• 建立监控告警：提前发现问题。
• 补充预案：文档化常见问题排查步骤。

👉 一个口诀是：“先止血，再定位，最后复盘”。

如果你要并发调用十几个下游，线程池参数别拍脑袋配。最靠谱的是用“隔离 + 估算 + 验证”的套路：

一、先做隔离（Bulkhead）

• 按下游拆池：每个关键下游一个独立线程池（或至少同延迟/同SLA的一组下游共用一个池），避免 A 堵死拖垮全局。
• 再配限流/熔断：每个下游单独限并发与超时，配熔断与降级。

二、用数据估算池大小（核心公式）

拿到每个下游的 3 个数：目标 QPS、p95 延迟（或超时上限）、突发系数/冗余比例。 用 Little’s Law 估并发需求：

• 需要并发数 C ≈ QPS × p95（秒）
• 再乘冗余系数（1.2~1.5）吸收抖动

例：某下游 QPS=300，p95=80ms=0.08s C≈300×0.08=24，并发冗余 1.3 → 31

三、如何落到线程池参数

以 Java ThreadPoolExecutor 为例（阻塞式 I/O 场景）：

1. corePoolSize ≈ 上面算出的 C（向上取整）。
   • 业务稳定：取 C
   • 有突发：取 1.1~1.3×C
2. maximumPoolSize = 1.5~2×core，但有上限：
   • CPU 密集：≤ 2×CPU 核心数
   • I/O 阻塞：可以高一些（几十~上百），但要用监控盯上下文切换和 GC
3. 工作队列（非常关键）
   • 对尾延迟敏感：SynchronousQueue（0 队列）+ 合理的 max，失败快、保护下游
   • 需吞吐+吸收小突发：LinkedBlockingQueue(cap)，cap ≈ C ~ 2C
   • 队列太大 = 隐藏拥塞 + 放大尾延迟
4. keepAliveTime 30~60s；流量波动大且想省线程，可 allowCoreThreadTimeOut(true)
5. 拒绝策略
   • AbortPolicy：立刻失败，上报/打点（推荐保护下游）
   • CallerRunsPolicy：向上游反压，但要确保调用方线程能承受
   • 或自定义：记录下游名、池名、当前 in-flight，打点报警
6. 超时（不属于线程池但必须配）
   • 下游调用超时要 小于 你对外 SLA
   • 读超时 ≈ p99 延迟 + 少量余量；连接超时单独设更小
7. 并发上限（替代或补充线程池） 使用信号量隔离（如 Resilience4j Bulkhead）把“同时在途请求数”钳住到 C~1.5C，效果常比仅靠队列更稳定。

给你一份超精简版多机房数据同步攻略（够用且能落地）：

1）先选一种模式（别全都上）

• 单主 + 异步复制（推荐默认） 一地写，多地读；复制是异步的。适合订单、用户资料等大多数 OLTP。 优点：简单稳；缺点：读可能短暂陈旧。
• 多主（active-active）+ 冲突解决 各地可写，最终一致。适合点赞/计数/购物车这类“可合并”的数据。 关键：幂等写、全局ID、版本号/CRDT 合并。
• 强一致（跨机房共识） 少量关键元数据用（例如全局唯一约束/配置主开关）。 成本高、延迟受 RTT 影响，只用在小表。

2）数据库怎么落地（MySQL 举例）

• 默认：每分片单主，跨机房异步复制（GTID）。读本地，写路由到主。
• 切主：用 Orchestrator/MHA；禁止双写，切换时先追平位点再放流量。
• 多主必须分区写（按用户/租户/地域），减少冲突面。

3）缓存 & 消息

• 缓存：只做读加速，主数据仍在 DB；失效通过 消息总线广播。
• 消息/Kafka：用 MirrorMaker/Cluster Linking 选定需要的 Topic 镜像，不要全量跨洋。
• 语义默认“至少一次”，用幂等键去重。

4）最重要的 5 条铁律

1. 幂等：所有跨机房写都带 request_id，DB 上加唯一索引/去重表。
2. Outbox/CDC 代替双写：应用内先写本地 outbox，再异步发 Kafka，同步两地靠日志，不靠应用并行双写。
3. 读写一致性：需要写后立读的请求，绑回同机房/同分片或带版本条件读。
4. 演练切换：有回滚预案（能 5 分钟内切回），季度演练 RTO/RPO。
5. 监控三件套：复制延迟（秒/位点）、Kafka lag、冲突/去重命中率。

5）一分钟落地清单

• 先定：哪类表单主，哪类表可多主（计数/购物车）。
• 给写请求加 request_id，实现幂等。
• 写入旁路改为 Outbox → Kafka → 订阅方。
• 设置跨机房读本地，对强一致小表单独服务化（少量共识）。
• 加复制延迟告警、切主脚本、灰度开关；写一份“切主 SOP”。

记忆法：“默认单主，能异步别同步；能幂等别重试；能日志别双写；能就近读别跨洋。”

线程与进程的区别

1. 基本概念

   • 进程（Process）：操作系统分配资源的最小单位。每个进程都有独立的内存空间（代码段、数据段、堆、栈），以及文件描述符、寄存器等。
   • 线程（Thread）：CPU 调度的最小单位，是进程中的一个执行流。线程共享所属进程的资源（如内存、文件句柄），但有自己独立的栈和寄存器。

2. 区别总结

   对比点	进程	线程
   资源	拥有独立的内存地址空间和资源	共享进程的内存和资源
   开销	创建、销毁、切换开销大	创建、销毁、切换开销小
   通信	进程间通信（IPC）需要特殊机制，如管道、消息队列、共享内存	线程间通信更容易，直接读写共享内存
   稳定性	一个进程崩溃不会直接影响其他进程	一个线程崩溃可能导致整个进程崩溃
   调度	由操作系统调度	同样由操作系统调度，但粒度更小

栈（Stack）

• 分配/释放：由编译器自动分配和释放。
• 存储内容：函数参数、局部变量、返回地址等。
• 空间大小：通常比较小（几 MB），连续分配，可能出现栈溢出（Stack Overflow）。
• 访问方式：先进后出（LIFO），访问速度快。

堆（Heap）

• 分配/释放：由程序员手动申请（如 C 中的 malloc / C++ 的 new），需要手动释放（否则内存泄漏）。
• 存储内容：动态分配的对象或数据。
• 空间大小：通常比栈大得多，不要求连续，可以达到 GB 级。
• 访问方式：自由存取，效率比栈低（需要分配、查找空闲空间）。

区别总结

Redis 中的 Sentinel 模式

如果你是问 Redis Sentinel，那它是 Redis 高可用方案。

核心作用

• Redis 本身是单点的，如果 Master 宕机，整个服务不可用。
• Redis Sentinel 模式提供了一种 自动故障转移 + 监控 + 通知 的机制。

架构组成

1. Sentinel 进程：独立运行，专门负责监控 Redis 节点。
2. Master 节点：主节点，负责写入和复制。
3. Slave 节点：从节点，负责读和备份。

工作机制

1. 监控：Sentinel 定期 ping Master 和 Slave，检查是否存活。
2. 选举：如果 Master 宕机，多数 Sentinel 一致认为“主挂了”，会发起一次 投票选举新的 Master。
3. 故障转移：把某个 Slave 升级为 Master，并通知其他 Slave 去同步它。
4. 通知：Sentinel 还会通过 API 通知客户端“新的 Master 地址”。

👉 打个比方：

• Master 是“国王”，Slave 是“太子”，Sentinel 是“御史大夫”。
• 国王挂了，御史们（Sentinel）开会投票，推选一个太子当新国王，然后全国公告。

ACID 四大特性

1. Atomicity（原子性）
   • 定义：事务中的所有操作要么全部成功，要么全部失败，不会出现“只做了一半”的情况。
   • 例子：银行转账，A 给 B 转 100 块。
     • A 账户减 100
     • B 账户加 100
     • 原子性保证：这两步要么都成功，要么都不执行。不会出现 A 扣钱了但 B 没收到。

1. Consistency（一致性）
   • 定义：事务执行前后，数据库必须保持一致性状态，不会违反数据完整性约束。
   • 例子：转账后，A 和 B 的余额总和应该保持不变（转账前后总额相等），即使发生异常也不能破坏规则。

1. Isolation（隔离性）
   • 定义：多个事务并发执行时，每个事务都应该像自己独占数据库一样，不受其他事务影响。
   • 例子：
     • 如果 A 正在查询商品库存，B 正在修改库存，那么 A 应该要么看到修改前的数据，要么看到修改后的数据，而不是一个“中间状态”。
   • 补充：数据库通过 隔离级别（读未提交、读已提交、可重复读、串行化） 来实现不同程度的隔离。

1. Durability（持久性）
   • 定义：事务一旦提交，修改就会永久保存，即使数据库宕机、断电也不会丢失。
   • 实现：通常依赖 WAL（Write Ahead Log，预写日志）、Redo Log 等机制。
   • 例子：转账事务提交后，即使系统瞬间掉电，重启后也能从日志恢复数据。

泄露的内存什么时候会释放

• 进程退出时，操作系统会回收该进程的虚拟内存页和大多数内核资源（fd、映射等）。
• 但对长跑服务而言，泄露会持续涨内存直到 OOM；并且某些跨进程资源（如未删除的 SysV/Posix 共享内存段、临时文件）可能不会自动清理。
• 因此“交给 OS 回收”只对短命进程勉强成立，服务程序必须修。

IPv4（最常见字段） Version(4) | IHL | DSCP/ECN | Total Length | Identification | Flags | Fragment Offset | TTL | Protocol | Header Checksum | Source IP | Dest IP | Options

IPv6（更简化的主头 + 扩展头） Version(6) | Traffic Class | Flow Label | Payload Length | Next Header | Hop Limit | Source IP(128b) | Dest IP(128b) 其余功能（分片、路由、认证等）放在扩展头链里。

IPv4 头部字段及作用

（标准头部最小 20 字节）

1. Version (4 bit) 表示 IP 协议版本号。常见是 4（IPv4），IPv6 中为 6。
2. IHL (Internet Header Length, 4 bit) 头部长度，单位是 4 字节。最小值 5（即 20 字节），最大 15（即 60 字节）。若有 Options 字段，则 IHL > 5。
3. DSCP/ECN (8 bit)
   • DSCP (Differentiated Services Code Point)：服务质量（QoS），用于流量优先级。
   • ECN (Explicit Congestion Notification)：显式拥塞通知，用于拥塞控制。
4. Total Length (16 bit) 整个 IP 包（头 + 数据）的长度，单位字节，最大 65,535。
5. Identification (16 bit) 分片标识号。分片时所有片的 ID 相同，接收方靠它把分片组装回去。
6. Flags (3 bit) 控制分片：
   • Bit 0：保留（必须为 0）
   • DF (Don’t Fragment)：1 表示禁止分片
   • MF (More Fragments)：1 表示后面还有分片
7. Fragment Offset (13 bit) 当前分片相对于原始数据的偏移量，单位 8 字节。
8. TTL (Time To Live, 8 bit) 存活时间，每经过一个路由器减 1，减到 0 则丢弃，防止环路。
9. Protocol (8 bit) 表示 IP 数据部分使用的上层协议：
   • 6 = TCP
   • 17 = UDP
   • 1 = ICMP
   • 2 = IGMP
10. Header Checksum (16 bit) 只覆盖 IP 头部的校验和，用于检测头部是否损坏。
11. Source IP Address (32 bit) 源主机 IP 地址。
12. Destination IP Address (32 bit) 目标主机 IP 地址。
13. Options (可选, 0–40 字节) 用于测试、路由记录、安全性要求等。现在很少用。
14. Padding 用 0 填充，使头部长度为 4 字节的整数倍。

IPv6 头部字段及作用

（固定 40 字节，更简化）

1. Version (4 bit) 固定为 6。
2. Traffic Class (8 bit) 类似 IPv4 的 DSCP/ECN，用于 QoS、拥塞控制。
3. Flow Label (20 bit) 表示数据流标识，路由器可识别同一流量并保证顺序或 QoS。
4. Payload Length (16 bit) 负载长度（不包括头部），最大 65,535。若更大需扩展头部支持。
5. Next Header (8 bit) 类似 IPv4 的 Protocol 字段，表示紧跟在 IPv6 头后面的协议（TCP/UDP/ICMPv6 等），或扩展头类型。
6. Hop Limit (8 bit) 类似 IPv4 的 TTL，每跳减 1，归零丢包。
7. Source Address (128 bit) 源 IPv6 地址。
8. Destination Address (128 bit) 目的 IPv6 地址。

🔑 总结：

• IPv4 头部复杂（分片、校验、选项等），所以路由器要更多处理。
• IPv6 头部更简洁，许多功能移到扩展头，以减少转发负担。

如何提升服务性能

我一般从几方面考虑：

1. 算法与数据结构：降低复杂度，选合适容器。
2. 并发与架构：用异步 I/O、线程池、减少锁争用。
3. 缓存：本地缓存 + 分布式缓存，减少数据库压力。
4. 数据库优化：建索引、读写分离、批量操作。
5. 网络与系统调优：连接池、零拷贝、参数优化。
6. 可观测性：先监控和定位，再有针对性优化。

两个 800GB 大文件找重复行 —— 思路分层讲

1. 明确限制

• 800GB ≫ 内存，肯定不能直接全读进来。
• 所以必须走 外部存储算法（External Memory Algorithms）。

2. 常见方法

方法一：外部排序 + 归并

• 先对两个文件分别做外部排序（分块、内存排序、归并）。
• 排好序后像 归并两个有序数组 那样同时扫描，遇到相同的行就输出。
• 这是最通用的方法，时间复杂度 ≈ O(N log N)，空间靠磁盘，可靠但比较耗时。

方法二：哈希分桶

• 用哈希函数对行做 hash(line) % N，把两个文件都分桶（写成 N 对小文件）。
• 每对桶里数据规模都小得多，可以进内存处理。
• 在桶内用哈希表/排序找交集。
• 这个方法如果选好 N，可以大大提高效率，还能并行。

3. 辅助优化

• 可以先对一个文件建 Bloom Filter，扫另一个文件时快速过滤掉大部分不可能重复的行（但要二次校验，因为 Bloom Filter 有误判）。
• 注意行格式要统一（换行符、编码、去空格等）。

阻塞（Blocking）与非阻塞（Non-blocking）

阻塞 IO

• 当用户线程发起 IO 调用（如 read、recv）时，如果数据还没准备好，就会 阻塞当前线程，直到数据到来并复制到用户缓冲区。
• 优点：逻辑简单。
• 缺点：线程被挂起，CPU 利用率低。

非阻塞 IO

• 当用户线程发起 IO 调用时，如果数据没准备好，立即返回一个错误码（比如 EAGAIN），不会挂起线程。
• 用户需要不断轮询（polling）检查数据是否就绪。
• 优点：线程不会挂起。
• 缺点：轮询会浪费 CPU，效率不高。

同步（Synchronous）与异步（Asynchronous）

同步 IO

• 用户线程必须自己参与 IO 就绪的等待和数据拷贝。
• 即使使用了非阻塞 IO（反复轮询），最终数据拷贝还是在用户线程上下文中完成，所以这依然是 同步。

异步 IO

• 用户线程发起 IO 请求后，内核负责完成所有等待与数据拷贝工作，完成后再通知用户（回调/事件/信号）。
• 线程完全不用管，像是“下单—送货上门”的模式。
• 典型例子：Linux 的 aio_* 系列函数，Windows 的 IOCP。

1. 先想象一个场景：你点外卖

• 同步： 你打电话点餐之后，必须自己守在餐厅门口等，直到厨师做好并交给你。 👉 不管你是坐着等（阻塞），还是一会儿进去问一声“好了吗”再出来（非阻塞轮询），最后都是你自己负责盯着，食物做好了你自己去取。
• 异步： 你下单后该干嘛干嘛，餐厅会在做好后直接派人送到你家，或者发短信通知你去拿。 👉 等待和把饭送到你手上的过程，都是别人（系统/内核）替你完成的，你不需要一直去盯着。

2. 换到 IO 上

• 同步 IO： 程序要么一直傻等，要么不断问“准备好了吗？” 数据的复制（从内核到你的程序内存）还是你自己去做。
• 异步 IO： 程序只需要说一句：“我要这个数据”。 操作系统自己会等数据准备好，并且把它放到你的内存里，然后告诉你“OK，可以用了”。

3. 关键点区别

• 同步：你（程序）得自己“参与整个等待和拿数据的过程”。
• 异步：你（程序）只需要发请求，剩下的等别人（操作系统）帮你搞定，最后只接个通知。

二者的组合关系

阻塞/非阻塞是“调用时行为”；同步/异步是“完成时通知方式”。所以它们可以组合：

阻塞同步 IO 小规模程序，比如脚本里直接 read 文件。

非阻塞同步 IO + 多路复用 (select/poll/epoll) 高并发服务器常用模式（如 Nginx、Redis）。线程只等待“哪个 socket 就绪”，真正的读写操作还是用户线程完成，所以是同步。

异步 IO 大规模 IO 场景，比如高性能文件服务器、Windows IOCP、libaio。程序只提交 IO 请求，数据到达后由操作系统通知。

一个生活类比

• 阻塞同步：去窗口排队买奶茶，必须等到拿到手才能走。
• 非阻塞同步：去窗口问有没有好啦？没好就回去再问，直到拿到。
• 异步 IO：下单后走开，等店员送到你手上或者通知你来取。

新版 Redis 为何采用「RDB + AOF 混合」策略？

• Redis 4.0 起引入 混合持久化：AOF 重写时，先把现有数据以 RDB 格式写入，再追加增量写命令。
• 原因：
  1. 恢复快：RDB 格式比 AOF 更小更快加载。
  2. 数据全：结合 AOF 追加日志，保证较高的数据完整性。
  3. 折中方案：既避免纯 RDB 的丢数据风险，又避免纯 AOF 文件过大恢复慢。

什么是缓存热点 key？电商秒杀场景下如何减少单 key 高频写入？

• 缓存热点 key：指某个 key 被短时间内大量访问或修改，导致缓存层/数据库层压力过大，甚至成为系统瓶颈。
  • 典型场景：秒杀商品库存、明星直播点赞数等。
• 减少单 key 高频写入的方法：
  1. 分片计数（counter sharding）：把一个库存 key 拆成多个 key，随机写其中之一，查询时再合并求和。
  2. 批量异步写：写操作先打到消息队列/内存队列，异步批量更新数据库或缓存。
  3. 本地缓存 + 定时合并：先在本地（进程内/线程内）累加，定期汇总写回。
  4. 乐观扣减 + 校正：前端或应用层先做预扣减，异步与真实库存对账。

如何把热点 key 拆分或合并请求以降低压力？

• 拆分热点 key（sharding）：
  • 把单个 key 拆成多个，比如库存 stock:1001 拆成 stock:1001:1 ~ stock:1001:N。
  • 写操作随机落到某个分片。
  • 读操作需要合并多个分片（或缓存层做聚合）。
  • 好处：单个 key 不会被写爆。
• 合并请求（request merge / coalescing）：
  • 如果多个用户同时请求更新/查询同一个 key，可以在应用层做 请求合并，减少实际落到 Redis 的次数。
  • 举例：1000 个用户同时点赞，可以先在应用层聚合成“+1000”，再写一次 Redis，而不是 1000 次 INCRBY 1。

MySQL 常见索引分为以下几类：

1. 主键索引（Primary Key）
   • 每个表只能有一个，唯一且非空，通常基于 B+ 树。
   • InnoDB 中，主键索引的叶子节点直接存储整行数据（聚簇索引）。
2. 唯一索引（Unique Key）
   • 保证列值唯一，但允许有一个 NULL。
   • 叶子节点存储的是索引列和主键值。
3. 普通索引（Index / Key）
   • 最基本的索引，加快查询，没有唯一性约束。
4. 联合索引（Composite Index）
   • 在多个列上建立的索引，遵循最左前缀原则。
5. 全文索引（Fulltext Index）
   • 用于大文本字段（如 CHAR、VARCHAR、TEXT），支持分词、模糊搜索。
6. 空间索引（Spatial Index）
   • 基于 R-Tree，主要用于地理空间数据（GIS）。

B+ 树节点大小通常与操作系统页对齐，MySQL 默认页大小是多少？

• InnoDB 默认页大小：16KB
• 一个 B+ 树节点就是一个页，节点大小与页对齐能：
  • 最大化利用磁盘读写（顺序读取一个完整页）。
  • 让单个节点能存放尽可能多的索引 key，从而降低树的高度。

如果让你设计，B+ 树非叶子节点大小应遵循什么原则？

• 原则：非叶子节点应尽量设计成 刚好一个页大小，以便一次 IO 能完整读取一个节点。
• 原因：
  1. 节点越大，每个节点能存储的索引 key 越多，树的高度就越低，减少 IO 次数。
  2. 不能太大，否则一个节点跨多个页，导致读取时仍然要多次 IO，反而降低性能。
  3. 不能太小，否则树层数增加，访问路径变长，IO 变多。
• 实际策略：InnoDB 就是定死 16KB 页大小，每个非叶子节点控制在 16KB 内。

要让“用户 → 正确分片”这件事稳定又可扩展，常见有 4 种做法。你可以任选其一或组合使用。

1) 应用层取模路由（最简单）

• 规则：shard = hash(user_id) % N
• 应用保有一个「分片表」（shard → {host,port}）。
• 例：hash(1008611) % 16 = 7 → 走第 7 号分片。
• 优点：快、实现简单。
• 缺点：N 变化（扩容/缩容）会导致大规模搬家（几乎所有用户都重映射）。

2) 一致性哈希（平滑扩容）

• 把分片节点放在一个“哈希环”上，shard = first_node_clockwise(hash(user_id))。
• 新增/下线分片时，只迁移邻近区间的 Key，修改量小。
• 实现要点：虚拟节点（每个物理分片放多个虚拟点）让负载更均匀。
• 常用于应用层路由或中间件（如某些客户端 SDK）。

3) 代理/中间层路由（对应用透明）

• 典型：Twemproxy、自研代理、或云厂商网关。应用只连代理，代理按哈希把请求转到对应分片。
• 优点：应用无感知，分片拓扑变化由代理维护。
• 缺点：多一跳，有额外延迟与单点风险（需多副本、健康检查）。

4) 存储自带分片（以 Redis 为例）

• Redis Cluster：把键映射到 16384 个 hash slot；slot 分配到不同节点。
  • 路由由客户端/集群完成：客户端发到任意节点，收到 MOVED/ASK 后学到正确节点，之后直连正确分片。
  • 想把同一用户的数据固定在同一 slot，可用哈希标签：inbox:{user_id}（花括号内参与 slot 计算）。
• 优点：原生、成熟；支持在线迁移 slot。
• 缺点：需要 Cluster-aware 客户端；某些命令有跨 slot 限制。

最终一致：在分布式系统里，数据在不同副本之间不会立刻同步，但经过一段时间（秒/分钟）后，一定会收敛到一致的状态。

• 系统允许短暂不一致（比如某个副本“落后”几条数据）。
• 但保证不会无限制不一致，最终大家会看到相同的结果。

Nginx（发音类似 engine-x）是一个高性能的Web服务器和反向代理服务器，同时也可以用作负载均衡器和HTTP缓存。它最初由俄罗斯工程师 Igor Sysoev 在 2004 年开发，目标是解决当时 Apache 在高并发场景下的性能瓶颈。

主要特点

1. 高并发性能
   • Nginx 使用事件驱动的异步非阻塞架构，在处理成千上万并发连接时，资源占用率远低于传统的多进程/多线程服务器（如 Apache）。
2. 反向代理
   • 它可以作为客户端和后端服务器之间的中间层，接收请求并转发到后端应用服务器（如 Tomcat、Node.js、Flask 等）。
   • 常用于隐藏后端服务器 IP、做 SSL 终止、实现请求分流。
3. 负载均衡
   • 支持多种策略（轮询、最少连接、IP hash 等），可将请求分配到多台服务器，从而提升系统的可用性和扩展性。
4. 静态资源服务
   • 对静态文件（HTML、CSS、JS、图片、视频）的处理速度非常快，常用于 CDN 和静态资源服务器。
5. 模块化设计
   • 可以扩展功能，例如支持缓存、限流、安全防护等。

你访问一个大型网站（比如电商平台），前端请求先到达 Nginx。

• 如果请求的是静态图片，Nginx 直接返回。
• 如果是用户下单请求，Nginx 会把请求转发给后端的应用服务器（比如 Java 的 Spring Boot 服务）。
• 如果后端有多台服务器，Nginx 会根据负载均衡策略分配请求。

什么时候不需要锁全表（绝大多数业务）

• 按主键/唯一键更新或删除： UPDATE users SET name=? WHERE id=?; —— 只锁命中的那几行（行锁 / Next-Key 锁），其他用户照常读写。
• 插入： INSERT 只会涉及到插入点及相关索引页的锁，不会锁整表。
• 查询并修改单个用户： 为了防止并发写冲突，用事务 + 行锁即可：
  • MySQL / Postgres：SELECT ... FROM users WHERE id=? FOR UPDATE;
  • 乐观并发也可：加 version 字段或 updated_at 比对。
• 批量操作但按主键或有索引过滤/分批： 分页或按范围分批更新（每批 N 条，提交一次事务），不会锁全表。

哪些情况可能需要“锁全表”或导致看起来像被锁住

这些一般是运维/DDL 级别，而不是普通业务写操作：

1. 某些 DDL（表结构变更）
   • MySQL InnoDB 大多数变更支持 Online DDL（如 ALGORITHM=INPLACE/INSTANT、LOCK=NONE），但并不是所有变更都无锁：
     • 例如 变更主键、修改列类型（复杂改动）、变更存储引擎、DROP/ADD 一些约束 等，可能需要较强的表级锁。
     • 即便 LOCK=NONE，也会有元数据锁（MDL）：在提交前阻止新的 DML/DDL 开始，若处理不当也会“全场卡住”的观感。
   • Postgres 中如 VACUUM FULL、CLUSTER、REINDEX CONCURRENTLY（较温和，但也有约束） 等会对并发有较强影响。
2. 需要全局一致性的运维动作
   • 全量去重/修复唯一性（比如手机号唯一，需要先清洗脏数据再加唯一索引）——为确保一致性，可能短时间阻断写入或加较强锁。
   • 大范围脱敏/回填且必须“一次原子完成”的场景。通常更推荐分批 + 幂等，避免长事务/大锁。
3. 没有合适索引的大批量更新/删除
   • 虽然不一定是“表锁”，但会产生大量行锁 + 间隙锁，把热点区段“锁死”，外界体验像“被锁表”。
   • 解决：先补索引、按主键范围分批、控制事务大小。
4. 老旧或特殊引擎
   • MySQL MyISAM 是表级锁；SQLite 写入时会有较大粒度的锁。生产上一般用 InnoDB/PG 避免这类问题。

Kafka 分区的作用：

场景类比：快递分拣中心

• Topic：相当于一个快递大仓库，比如「订单信息」。
• 分区（Partition）：就像把仓库里的快递分到不同的传送带上（分区数=传送带数）。
• Broker：每个仓库节点，相当于一个快递站点，存储一些传送带上的快递。
• 消费者（Consumer）：快递员，每个人负责一条传送带上的快递。

如果没有分区（只有 1 条传送带）

• 所有订单都堆到一条传送带上。
• 只能安排一个快递员去处理，处理速度受限。
• 仓库吞吐量有限，扩容也没用。

有了分区（比如 3 个分区 = 3 条传送带）

1. 提升吞吐量：
   • 同时有 3 个传送带运转，3 个快递员并行处理，速度快很多。
2. 支持扩展：
   • 如果订单太多，可以增加传送带数量（增加分区）和快递员数量（消费者）。
3. 保证顺序：
   • 同一客户的所有订单会始终进入同一条传送带（同一个分区），这样就能保证顺序不乱。
4. 容错性：
   • 每条传送带旁边都有备用通道（副本）。哪怕一个坏了，还有其他副本能继续处理，不会丢快递。

总结成一句话

Kafka 分区就像把快递分到多条传送带上：既能并行提高速度，又能保证同一条传送带上的顺序，还能方便扩容和容错。

1. 概念层面

• 递归 (Recursion)
  • 一种 编程技巧：函数调用自身，把大问题拆成小问题。
  • 关键点：有终止条件 (base case)，问题规模逐渐缩小。
  • 举例：斐波那契数列、树的遍历、归并排序。
• 回溯 (Backtracking)
  • 一种 算法思想：在递归的基础上，通过“尝试 → 判断 → 撤销”的过程，系统地搜索解空间。
  • 关键点：回退和剪枝，探索所有可能的解。
  • 举例：N 皇后、全排列、子集枚举、数独、图搜索。

2. 区别总结

• 递归是工具，回溯是策略。
• 递归不一定涉及搜索，只要问题可以分解就能用递归；
• 回溯几乎都用递归实现，但它强调“试探 + 撤销”。

3. 各自适合的问题

• 递归适合：
  • 问题能分解成规模更小的子问题；
  • 子问题之间相对独立；
  • 常见场景：树/图遍历、分治算法、动态规划。
• 回溯适合：
  • 需要遍历所有可能解，或从大量候选中找到满足条件的解；
  • 解空间呈树形结构，需要逐步构造解；
  • 常见场景：排列组合、N 皇后、背包问题、数独求解。

7. Redis 集群（Redis Cluster）

作用：把数据分片到多台节点，既扩容内存/吞吐，也提供故障转移（高可用）。

核心机制

• 槽位分片：把 key 的 CRC16 取模到 16384 个槽，每个槽由某个主节点负责；可用 Hash Tag（如 {user:1}:profile）把一组 key 固定到同一槽位/节点。
• 主从复制：每个主节点有 0~N 个从节点；主故障时由从提升为主（投票过半）。
• Gossip + 投票：节点间互探活性、传播元数据；故障需过半主节点认定。
• MOVED/ASK 重定向：客户端访问到非负责节点时收到跳转，智能客户端会更新槽位映射。
• 在线扩缩容：迁移槽位（resharding/rehash）即可把数据在节点间移动。

优点

• 水平扩展（容量与 QPS），分区内顺序自洽，可用性高（主从 + 自动切主）。

注意点 / 踩坑

• 跨槽事务/脚本受限：多 key 操作尽量放同一 hash tag。
• 热 key：单分区热点会拖垮一个主；可做读写分离（读走从）、多副本读、或热点拆分（key 前缀打散 + 聚合）。
• 超大 value：迁槽、复制压力大，建议小而频的键值设计，或把大对象拆字段存。
• 客户端要支持 Cluster：否则不认识 MOVED/ASK。
• 网络分区与选举超时：合理设置 cluster-node-timeout，并监控复制延迟/故障切换时长。

何时用 Cluster 而非单机/哨兵

• 单实例内存接近极限、或单机 QPS 成瓶颈 → 用 Cluster 分片。
• 数据量不大只是要高可用 → 用 Sentinel（主从 + 自动切主）即可。

8. “三大缓存”与缓存一致性

这里常被问的是三种主流缓存模式（有时面试官叫“三大缓存”）+ 如何保证与数据库的一致性：

8.1 三种缓存模式（读/写路径）

1. Cache-Aside（旁路/旁路缓存） – 业务最常用

• 读：先查缓存，未命中再查 DB，结果回填缓存。
• 写：先写 DB，后删缓存（推荐；删除而不是更新，避免并发脏写）。
• 优点：灵活、通用；缺点：一致性要自己保证。

1. Read-Through – 由缓存层代替业务读 DB

• 读：应用只访问缓存；缓存未命中由缓存组件去加载 DB 并回填。
• 写：仍多见 “写 DB、删缓存” 或由组件代理。
• 优点：读路径简单；缺点：需要带 Loader 的中间件/代理。

1. Write-Through / Write-Behind（回写/异步回写）

• Write-Through：写请求先落缓存，再同步写 DB（或由缓存组件负责两边写）。
• Write-Behind：写入缓存后异步批量刷 DB。
• 优点：写性能好（尤其 Behind）；缺点：一致性/丢数据风险更高，需 MQ/落盘队列保障。

面试金句：读多写少 → Cache-Aside；延迟极致 & 接受最终一致 → Write-Behind；有统一的缓存代理/网关 → Read-Through。

8.2 缓存与数据库一致性（强/最终）

目标：避免读到过期数据或“回写覆盖”。

通用实践（按重要性）

1. 写顺序：先 DB，后删缓存（而不是更新）
   • 解决并发下“旧值覆盖新值”的经典问题。
   • 失败重试：删除失败要有重试/补偿（重试队列、任务表）。
2. 延时双删（Double-Delete）
   • 写 DB → 删缓存 → 延时再删一次（例如 200~500ms）。
   • 目的：覆盖并发读导致的“旧值回填”。
3. Binlog 异步订阅修正（强烈推荐）
   • 监听 DB binlog（如 Canal/Debezium），把变更投递到 MQ，消费者精确失效/重建缓存。
   • 优点：最终一致且可靠，对业务入侵小。

在「数据库 + 缓存（Redis）」架构里，常见的痛点是：

• 数据库更新成功了，但缓存没更新/没删除，导致 缓存和数据库数据不一致。
• 如果靠业务代码里写 update db → del redis，就会有业务入侵（每个写数据库的地方都要顺带处理缓存逻辑），而且容易出错。

2. Binlog 异步订阅修正是什么？

• Binlog：MySQL 的二进制日志，记录了所有对数据库的变更（insert、update、delete）。
• 异步订阅：通过类似 Canal（阿里开源）、Debezium（Kafka 社区）这样的工具，订阅 MySQL Binlog 事件。
• 投递到 MQ：把这些变更消息（某条记录更新了/删除了）投递到消息队列（Kafka/RabbitMQ/等）。
• 消费者处理缓存：下游消费者订阅 MQ，然后精确地对 Redis 做失效/重建。

比如：

• 用户 ID=123 的记录更新了 → Binlog 事件 → Canal 捕获 → 推送到 MQ → 消费者收到 → DEL redis:user:123。

3. 优点

1. 最终一致且可靠
   • Binlog 是 MySQL 的事实来源（ground truth），不会漏。
   • 即使业务代码没管缓存，Binlog 订阅也能保证缓存和数据库最终一致。
2. 对业务入侵小
   • 业务代码只管写数据库，不用到处加 del redis。
   • 缓存修正由异步订阅系统负责，和业务解耦。
3. 解耦 + 可扩展
   • 除了缓存修正，还能把 Binlog 投递给别的系统（搜索引擎、实时计算、数据同步等）。

4. 总结一句话

👉 Binlog 异步订阅修正 = 监听数据库 Binlog → 通过 Canal/Debezium 把变更投递到 MQ → 消费者更新/失效缓存。 好处是 最终一致、可靠、低业务入侵，是业界强烈推荐的「DB-Cache 一致性方案」。

1. TTL + 逻辑过期
   • 设置合理 TTL 兜底；对热点可用逻辑过期（值+过期时间），过期后由单协程重建，其余读老值，避免击穿。
2. 防并发写脏
   • 分布式锁/乐观锁（版本号、CAS）防止多写覆盖；
   • 幂等（按业务主键/请求 ID）。
3. 读写隔离与一致性选择
   • 读多写少常选最终一致（性能优先）；金融/下单等关键路径用“强一致”：
     • 写：DB 成功→删缓存成功才返回；
     • 读：强制读 DB 或携带版本戳校验。

8.3 典型故障与治理

• 缓存击穿（单热点 key 过期瞬间大量穿透 DB）
  • 热点互斥重建（锁）、逻辑过期、预热。
• 缓存雪崩（大量 key 同时过期）
  • TTL 加随机抖动；多层缓存；限流/降级；分批加载。
• 缓存穿透（查询不存在的数据）
  • 缓存空值（短 TTL）、布隆过滤器、参数校验。

JVM 内存主要分为 线程私有 和 线程共享 两大类区域：

• 线程私有：每个线程独立拥有，随线程创建/销毁。
  • 程序计数器 (PC Register)
  • 虚拟机栈 (JVM Stack)
  • 本地方法栈 (Native Method Stack)
• 线程共享：所有线程可见，随 JVM 启动/关闭。
  • 堆 (Heap)
  • 方法区 (Method Area，JDK 8 之后改为 Metaspace)

1. 指针

• 和 C 的区别
  • Go 有指针，但 不能做指针运算（比如 p++ 是非法的），只能取地址和解引用。
  • 这样设计是为了安全和简化。
• 值类型 vs 引用类型
  • 值类型：int, float, bool, array, struct —— 赋值时会拷贝一份数据。
  • 引用类型：slice, map, channel, func —— 本质上是一个指针+结构体封装，赋值时拷贝的是“引用”，底层数据共享。
• 常见考点
  • 函数参数如果是值类型，修改不会影响外部；如果传指针或引用类型，外部数据可能被修改。

2. 切片 (slice) & 数组

• 数组：长度固定，属于值类型，[3]int 和 [4]int 是不同类型。

• 切片：动态视图，本质结构：

  type slice struct {
      ptr *T   // 底层数组的指针
      len int  // 当前切片长度
      cap int  // 底层数组容量
  }
  

• 扩容机制

  • append 超过容量时，会重新分配新数组：
    • 小于 1024 时，一般按 2 倍 扩容。
    • 超过 1024 时，按 1.25 倍左右 扩容。
  • 扩容会产生新底层数组，旧的数组数据拷贝过去 → 所以 append 后原切片和新切片可能不再共享数据。

• 常见考点

  • 切片拷贝/append 后原数据是否改变。
  • 切片 reslice 不会复制底层数组。

3. map

• 底层实现
  • Go 的 map 是哈希表，采用 哈希桶（bucket） 存储。
  • 每个 bucket 存最多 8 个 kv 对，溢出时挂溢出链。
• 扩容
  • 当装载因子过大时触发扩容，新建更大容量的 buckets，并逐步迁移数据（增量扩容，避免 STW）。
• 遍历无序
  • Go 特意让 map 遍历无序（每次都打乱），防止开发者依赖遍历顺序。
• 键必须可比较
  • 可以作为 key 的类型：布尔、数值、字符串、指针、channel、接口、struct、array（前提是内部字段都可比较）。
  • 不可作为 key：slice, map, func。

扩容的时候发生了什么？

1. 触发条件：装载因子太大（元素数 / bucket 数超过阈值，大约 6.5）。
2. 扩容方式：哈希表会新建一个 桶数量翻倍 的数组。
   • 原来可能是 8 个 bucket，扩容后变成 16 个 bucket。
3. 数据迁移：旧 bucket 里的 kv 会逐步搬到新 bucket 里（渐进式，避免一次性 STW 卡顿）。

举个例子

• 假设你有一个 map[string]int，初始有 8 个 bucket。
• 每个 bucket 最多 8 个 kv 对（再多就溢出）。
• 当你不停往 map 里插入数据，装载因子超过阈值，就会扩容。
• 扩容后，bucket 数量翻倍，比如从 8 → 16。
• 但 每个 bucket 还是只能放 8 个 kv 对，这个上限不会变。

1. 溢出桶（overflow bucket）

• 当某个 bucket 已经装满 8 个 kv 对，再有新的 key 映射到这个 bucket 时，Go 会在该 bucket 后面挂一个 溢出桶 (overflow bucket)。
• 新的 kv 就存放在溢出桶里。
• 一个 bucket 可以挂多个溢出桶，形成链表。

结构大致像这样（伪图）：

[主 bucket] -> [overflow bucket1] -> [overflow bucket2] -> ...

4. 字符串

• 不可变

  • Go 的 string 是只读字节序列，底层结构：

    type string struct {
        ptr *byte // 指向底层数组
        len int
    }
    

  • 一旦创建不可修改，只能重新构造新字符串。

• 和 []byte / []rune 的关系

  • []byte：字节切片，按 UTF-8 编码存储。

  • []rune：Unicode 码点切片，解决中文/emoji 占多个字节问题。

  • 典型考点：

    s := "你好"
    fmt.Println(len(s))       // 6（UTF-8 占 3+3 字节）
    fmt.Println(len([]rune(s))) // 2（两个 Unicode 字符）
    

5. 接口 (interface)

• 底层实现
  • 接口分两种：
    • 空接口：interface{}，结构体是 (type, data)。
    • 非空接口：带方法表 (itab, data)，itab 里存类型和方法指针。
  • 调用接口方法时通过 动态派发（查 itab）。
• 接口断言
  • x.(T)：断言接口保存的动态类型是 T。
  • x.(T) 会 panic，x.(T, ok) 返回布尔值避免 panic。
• 常见考点
  • 空接口可以装任何值。
  • nil interface 和 interface holding nil 的区别：前者为 nil，后者不为 nil。

6. defer / panic / recover

• defer

  • 先进后出（LIFO）。

  • 会在函数返回前执行，即使遇到 panic 也会执行。

  • 和 return 结合时：先计算返回值 → 再执行 defer → 再返回。

    func f() (x int) {
        defer func() { x++ }()
        return 1  // 返回前 x=1，defer 修改后 x=2
    }
    

• panic

  • 类似抛异常，会中止正常执行，沿调用栈向上传递。

• recover

  • 必须在 defer 中调用，捕获 panic 并恢复程序。
  • 超出 defer 后调用 recover 无效。

1. goroutine

• 定义：Go 的轻量级线程，运行在用户态，由 Go runtime 调度。
• 创建：go f()，开销比 OS 线程小得多（初始栈约 2KB，会动态扩容）。
• 调度模型 GMP：
  • G：goroutine（协程）。
  • M：machine（内核线程，真正执行 G 的载体）。
  • P：processor（逻辑调度器，保存本地运行队列，负责把 G 分配给 M）。
  • 数量关系：M 数量受 CPU 核数 & GOMAXPROCS 限制，P 一般等于 GOMAXPROCS。

👉 考点：为什么 Go 能开成千上万个 goroutine，而 Java/C++ 线程不行？ ➡️ 因为 goroutine 栈很小且可动态增长，调度在用户态完成，开销远小于内核线程。

2. channel

• 定义：Go 的 CSP 模型核心，goroutine 之间通信的管道。

• 无缓冲 channel：

  • 发送 ch <- v 必须等接收 <- ch 同时就绪，否则阻塞。

  • 实现 goroutine 间的同步。

  • ch 是一个 channel。

    ch <- v 表示 把值 v 发送到 channel ch。

    发送之后，另一个 goroutine 可以用 <-ch 把这个值取出来。

• 有缓冲 channel：

  • ch := make(chan int, 3) → 容量 3。
  • 发送时：如果没满，不阻塞；满了才阻塞。
  • 接收时：如果没空，不阻塞；空了才阻塞。

• close 的作用：

  • close(ch) 表示不能再发送，但还能接收剩余数据。
  • 用法：v, ok := <-ch，如果 channel 已关闭且没数据，ok=false。

👉 考点：

• 读一个关闭的 channel → 读到零值，不 panic。
• 写一个关闭的 channel → panic。

1. 无缓冲 channel

特点

• 同步通信：发送必须等接收，就像一个“握手协议”。
• 能天然保证 发送方和接收方在同一时间点交互数据。
• 发送的值不会存储，必须有接收者马上消费。

典型应用场景

1. 任务同步/信号通知

   • 比如一个 goroutine 完成了任务，要通知另一个 goroutine：

   done := make(chan struct{})
   go func() {
       work()
       done <- struct{}{} // 通知完成
   }()
   <-done // 等待通知
   

2. 生产者-消费者一对一传递

   • 适合实时、点对点的数据交付。
   • 确保“谁发的，谁收到了”，不会堆积。

3. 控制并发节奏

   • 用无缓冲 channel 让 goroutine 按顺序执行，而不是乱跑。

👉 可以理解为“电话沟通”：必须两边同时在线才能传话。

2. 有缓冲 channel

特点

• 异步通信：发送方只要缓冲区没满就可以立刻返回。
• 值可以临时存储在缓冲区里，接收方晚点消费也没关系。
• 更像“消息队列”。

典型应用场景

1. 生产者-消费者（异步）

   • 多个生产者 goroutine 往里写，消费者 goroutine 慢慢取：

   ch := make(chan int, 100)
   go producer(ch)
   go consumer(ch)
   

2. 任务队列/工作池

   • 把待处理任务放到有缓冲 channel，工人 goroutine 从中取任务并处理。
   • 类似一个简易版的队列。

3. 削峰填谷

   • 短时间内生产速度快于消费速度，用缓冲来“平滑”压力。
   • 比如日志收集、网络请求缓存。

👉 可以理解为“邮箱”：发信人可以先丢进去，收信人慢慢取。

3. 对比总结

3. select

• 作用：同时监听多个 channel 的收发操作。
• 随机公平性：多个 case 就绪时，会随机选一个执行，避免饥饿。
• default 分支：所有 case 都阻塞时，执行 default。

👉 常见场景：超时控制

select {
case v := <-ch:
    fmt.Println(v)
case <-time.After(1 * time.Second):
    fmt.Println("timeout")
}

4. context

• 作用：跨 goroutine 的取消信号 & 超时控制。
• 常用方法：
  • context.Background()：根 context。
  • context.WithCancel(parent)：手动取消。
  • context.WithTimeout(parent, d)：超时自动取消。
  • <-ctx.Done()：接收取消信号。

👉 典型用法：

ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
defer cancel()

select {
case <-doSomething():
case <-ctx.Done():
    fmt.Println("timeout")
}

5. sync 包

(1) Mutex vs RWMutex

• sync.Mutex：互斥锁，保证同一时间只有一个 goroutine 访问。
• sync.RWMutex：读写锁，允许多个读并发，写独占。

👉 使用场景：读多写少时 RWMutex 效果好；写多时反而可能更慢。

(2) WaitGroup

• 用于等待一组 goroutine 结束。

var wg sync.WaitGroup
wg.Add(3)
go func(){ defer wg.Done(); work() }()
go func(){ defer wg.Done(); work() }()
go func(){ defer wg.Done(); work() }()
wg.Wait()

(3) Once

• 保证某个操作只执行一次（如单例初始化）。

var once sync.Once
once.Do(func(){ initConfig() })

(4) Cond

• 条件变量，用于复杂同步。

cond := sync.NewCond(&sync.Mutex{})
cond.L.Lock()
for !condition {
    cond.Wait() // 等待唤醒
}
cond.L.Unlock()
cond.Signal() // 唤醒一个
cond.Broadcast() // 唤醒全部

(5) Map

• 并发安全的 map（内部用分片+原子操作）。
• 适合读多写少场景。写多场景用自己加锁的 map 更好。

6. 原子操作

• 包：sync/atomic，底层用 CPU 原子指令（CAS）。
• 常用函数：
  • atomic.AddInt32(&x, 1)：原子加。
  • atomic.LoadInt32(&x)：原子读。
  • atomic.StoreInt32(&x, v)：原子写。
  • atomic.CompareAndSwapInt32(&x, old, new)：CAS 操作。

👉 面试常考点：用 atomic 实现自旋锁、计数器。

✅ 总结一张表：

1. GMP 调度模型

• G：goroutine（协程）。
• M：machine（内核线程，真正执行 G 的载体）。
• P：processor（逻辑调度器，保存就绪的 G 队列，决定哪个 G 给哪个 M 执行）。

关系：

• G 一定要绑定到 P，才能被 M 执行。
• P 的数量 = GOMAXPROCS（默认等于 CPU 核数）。
• M 数量不固定，可以比 CPU 多。

为什么高效？

• Go 自己管理 goroutine 调度，不依赖 OS 内核调度。
• goroutine 栈很小（2KB 起），能动态增长。
• 上下文切换在用户态完成，比线程切换轻量。

2. 垃圾回收 (GC)

Go 的 GC 是 并发标记清除，核心是 三色标记法 + 写屏障。

三色标记

• 白色：未标记对象，可能是垃圾。
• 灰色：已发现但子节点未扫描的对象。
• 黑色：已扫描完成，不会被回收。

流程：

1. GC 起始时，根对象（全局变量、栈）标记为灰色。
2. 遍历灰色对象，把它们引用的对象标记成灰色，然后自身变黑。
3. 最后白色对象就是垃圾，被回收。

写屏障

• 在 GC 过程中，程序还在运行（mutator）。
• 写屏障确保：只要一个对象能从黑色对象访问到，它就不会漏标。
• 这样 GC 和用户程序可以并发执行。

4. 内存对齐

• Go struct 的字段存放需要 按照类型对齐，保证 CPU 访问高效。
• 规则：
  • 每个字段的地址必须是该字段大小的整数倍。
  • 整个 struct 的大小必须是最大字段大小的整数倍。

例子：

type A struct {
    a int8   // 1B
    b int64  // 8B
    c int8   // 1B
}
fmt.Println(unsafe.Sizeof(A{})) // 输出 24

解释：

• a 占 1B，但要对齐到 8B → 前后填充 7B。
• b 占 8B → 正常放置。
• c 占 1B，但 struct 总大小必须是 8 的倍数 → 填充到 24B。

👉 优化办法：把大的字段放前面，小的放后面，减少填充。

Go 的 net/http 库底层是如何和网络沟通的。面试里这一块也常会考。简单讲，它其实是对 TCP 套接字 (socket) 的一层封装。

1. 启动 HTTP 服务的入口

最常见的启动方法是：

http.ListenAndServe(":8080", handler)

它背后做了几件事：

1. 创建监听器：调用 net.Listen("tcp", ":8080")，监听 TCP 端口。
2. 循环 accept：不断 Accept() 等待新的客户端连接。
3. 每个连接开一个 goroutine：并发处理请求。
4. 读写数据：在 goroutine 内，对 socket 做 Read/Write，并解析 HTTP 协议。

2. 底层网络调用流程

Go 的 net 包其实就是对 系统调用（syscall） 的封装：

• 服务端：
  • net.Listen("tcp", ":8080") → 调用内核的 socket()、bind()、listen()。
  • Accept() → 调用内核的 accept()，拿到客户端的 socket。
• 客户端：
  • net.Dial("tcp", "host:port") → 调用 socket()、connect()。
• 数据传输：
  • conn.Read(b) → 调用内核 read()，从 TCP 缓冲区读数据。
  • conn.Write(b) → 调用内核 write()，把数据写到 TCP 缓冲区，由内核协议栈发出去。

3. Go 的并发网络模型

• Go 的网络 I/O 并不是“一个连接一个线程”，而是基于 epoll/kqueue/IOCP 的多路复用。
• Runtime 里有 netpoller：
  • Linux → 用 epoll
  • macOS → 用 kqueue
  • Windows → 用 IOCP
• 每个连接被注册到内核的事件通知机制上，I/O 就绪后由 runtime 唤醒对应的 goroutine 处理。

👉 这就是为什么 Go 的 http server 可以轻松支撑成千上万并发连接 —— goroutine 是轻量的，I/O 调度靠事件驱动，而不是线程阻塞。

4. Handler 的调用链

当数据读到用户态，net/http 会：

1. 解析 HTTP 请求行、Header、Body → 生成 http.Request 对象。
2. 调用用户注册的 Handler.ServeHTTP(w, r)。
3. 用户写 w.Write() → 最终写回到 TCP 连接。

✅ 总结一句话： Go 的 net/http 底层是用 net 包的 TCP socket 实现的，连接管理靠 epoll/kqueue/IOCP，I/O 事件由 runtime 的 netpoller 分发给 goroutine，最终由用户定义的 Handler 来处理业务逻辑。

1. goroutine 泄漏场景与排查方法

• 泄漏场景：
  • 阻塞在 channel 读写上，没人来匹配。
  • 无限循环里没有退出条件。
  • HTTP 请求/数据库连接没关闭。
• 排查方法：
  • pprof 分析 goroutine 数量 (runtime.NumGoroutine()，或 go tool pprof)。
  • 用 golang.org/x/net/trace 或 log 打印栈追踪。

👉 面试答法：goroutine 不会被 GC 自动回收，必须保证退出机制，比如用 context 控制生命周期。

2. channel 死锁的几种情况

• 在无缓冲 channel 上，只有发送，没有接收。
• 只有接收，没有发送。
• 有缓冲 channel 满了还继续写，没人读。
• 空 channel 一直读，没人写。
• close 后继续写入 → panic（严格来说是 runtime error，也会被当成“死锁”场景）。

3. interface 底层实现机制

• 接口底层由两部分组成：
  • 非空接口：itab (type + method table) + data。
  • 空接口：type + data。
• 调用接口方法时，通过 itab 的方法表动态派发。

👉 常考陷阱：

• nil interface 和 interface holding nil 不一样：前者完全为 nil，后者 type 有值但 data 是 nil。

4. slice 扩容机制，append 触发条件

• 触发条件：len+1 > cap。
• 扩容策略：
  • 小于 1024 → 容量 *2。
  • ≥1024 → 容量 *1.25 左右。
• 新建底层数组，拷贝原数据。旧切片和新切片分离。

5. map 并发读写问题，如何解决

• Go 的普通 map 不是线程安全的。并发读写会报错：fatal error: concurrent map read and map write。
• 解决办法：
  • 加锁：sync.Mutex/sync.RWMutex。
  • 用并发安全的 sync.Map（适合读多写少）。

6. defer 的执行顺序，和 return 结合时的执行时机

• 顺序：先进后出（LIFO）。
• 执行时机：函数 return 时 → 先计算返回值 → 再执行 defer → 最后返回。

例子：

func f() (x int) {
    defer func() { x++ }()
    return 1
}
// 返回 2

7. 内存逃逸分析的例子

• 编译器会决定变量在栈/堆上的分配。
• 典型例子：

func f() *int {
    x := 10
    return &x // x 逃逸到堆
}
func g() int {
    x := 10
    return x // x 在栈上
}

👉 可以用 go build -gcflags=-m main.go 查看逃逸情况。

8. select 随机性以及默认分支

• 多个 case 就绪时：Go 会随机选择一个执行（防止饿死）。
• default 分支：如果所有 case 都阻塞，就执行 default，相当于非阻塞 select。

9. Go 的 GC 与 C++/Java 的区别

• C++：手动管理内存，或用智能指针。
• Java：GC 停顿明显，分代 GC（新生代、老年代）。
• Go：三色标记 + 写屏障，并发 GC，追求 低延迟（STW 时间小于 1ms）。

10. Go 的零值机制，为什么避免了“野指针”问题

• Go 中所有变量在声明时都会初始化为 零值：
  • int → 0
  • string → “”
  • bool → false
  • 指针、slice、map、chan、func、interface → nil
• 好处：不用担心未初始化的随机值，避免 C 语言常见的“野指针”。

常见性能优化手段

• 减少逃逸 逃逸分析：决定变量分配在栈还是堆。

  • 栈分配：快，随函数返回自动释放
  • 堆分配：需要 GC，代价大 优化：尽量避免返回局部变量的指针、接口存储值、闭包引用大对象。

• 减少 GC 压力

  • 复用对象（对象池、sync.Pool）
  • 避免短生命周期的大量小对象

• 使用 sync.Pool

  • 适合缓存临时对象，减少频繁分配/回收
  • 但 GC 会清空池，不能依赖它做长期缓存

  var pool = sync.Pool{New: func() interface{} { return new(bytes.Buffer) }}
  buf := pool.Get().(*bytes.Buffer)
  buf.Reset()
  pool.Put(buf)
  

• 合理使用 channel vs 锁

  • channel 适合：goroutine 间数据传递（CSP 模型）
  • 锁更快：在共享内存读写简单时，用 Mutex/RWMutex 更高效
  • 面试官常问：“能不能用 channel 替代锁？” → 可以，但性能未必更好

🌰 情况一：goroutine 相互等待资源（两个人互相等钥匙）

想象一下：

• 有两把钥匙：钥匙 A、钥匙 B。
• 小明拿到了钥匙 A，准备去开一扇需要 A+B 的门，他伸手去要钥匙 B。
• 小红拿到了钥匙 B，也要去开同一扇门，她伸手去要钥匙 A。

结果呢？ 👉 小明说：“你先给我钥匙 B，我再给你钥匙 A。” 👉 小红说：“你先给我钥匙 A，我再给你钥匙 B。”

谁也不松手，双方僵住了。门永远打不开。

这就是 两个 goroutine 拿锁顺序不一致 → 相互等待 → 死锁。

避免方法：规定规则，比如“大家必须先拿钥匙 A，再拿钥匙 B”。这样就不会互相僵持。

🌰 情况二：channel 双向阻塞（两个人互相等对方说话）

想象一下：

• 有两个人面对面聊天，规则是 必须先听到对方说话，自己才能说话。
• 小明想先说，但他得等小红说。
• 小红也想说，但她也得等小明先说。

于是两人都张着嘴巴，互相盯着，尴尬沉默，谁都不说话。

👉 这就是 无缓冲 channel 的读写双方都在等 → 死锁。

解决方法：

• 给 channel 放个“缓冲座位”，就像中间放个录音机，可以先把话录下来，再轮流听：

  ch := make(chan int, 1)
  ch <- 1  // 先写进去
  fmt.Println(<-ch) // 再读出来
  

• 或者加个超时： 就像“如果 3 秒没人说话，我就自己走人”。

下面把“Redis 集群一致性”拆成 4 个层面：写一致性、读一致性、持久化一致性、迁移/故障一致性，并给出可落地做法。

1) 写一致性（主从复制）

• Redis Cluster 的复制是异步的 ⇒ 天生是最终一致，主节点写成功并不保证副本立刻有。

• 可用两种手段把“最终一致”收紧到“准同步”：

  1. WAIT <numreplicas> <timeout>：写后阻塞到有 N 个副本确认接收（只是“收到”，不是落盘）。

     SET k v
     WAIT 1 50     # 等 1 个副本在 50ms 内确认
     

     适合关键写路径（但会增加写时延）。

  2. 写口子控制（老版本叫 min-slaves-to-write/min-slaves-max-lag）：

     • min-replicas-to-write 1
     • min-replicas-max-lag 2 含义：若可用副本数 < 1 或主从延迟 > 2s，则拒绝写入，防止孤岛写入造成更大不一致。

2) 读一致性（主/从读与读己之）

• 强烈建议：读走主（尤其是写后立刻读的请求），保证读己之（Read-Your-Writes）。
• 若必须读从（减压/就近）：
  • 接受可能的读陈旧；或在重要读前先 WAIT 收紧复制，再读从；
  • 使用客户端“读偏好”策略：更新后短时间强制读主、或附加版本/时间戳检查回退读主；
  • 可用 CLIENT CACHING / 失效推送（或应用本地 cache+订阅失效）做缓存一致性。

3) 持久化一致性（崩溃后是否一致）

• 打开 AOF，并权衡 appendfsync：
  • always：最安全、最慢；
  • everysec（常用）：最多丢 1s 日志；
  • no：性能最好、风险最大。
• 为降低 fork 开销与传播时延，可配 repl-diskless-sync yes（无盘复制快一些，但与一致性关系间接）。
• 如果你已经用 WAIT 保证 N 个副本都“接收”，仍不能 100% 防断电丢失，除非副本也落盘成功（Redis 没有多副本“落盘确认再返回”的强一致路径）。

4) 迁移/故障切换一致性

• 槽位迁移使用 MIGRATING/IMPORTING + ASK：迁移期间客户端收到 ASK 重定向，单 Key 操作仍原子，不会出现半迁移读写错位。
• 故障转移：Replica 选主需要集群多数投票；因为复制异步，主挂前最后一批写可能丢失（常见“少量回滚”）。
  • 缩小窗口：
    • 合理设置 cluster-node-timeout（更快探测=更快切主，但误判风险 ↑）；
    • 写前/后配合 WAIT；
    • min-replicas-* 防孤岛写；
    • 业务端对关键资源加 幂等键 / 版本号（CAS），允许重试+去重。
• 多键原子性限制：多键事务、Lua、pipeline 只在同槽才能保证原子与一致。用 hash tag（如 user:{42}:profile, user:{42}:orders）把相关键锁定到一个槽。

5) 应用侧“补齐一致性”的通用做法

• 幂等写：用业务唯一键（如订单号/请求 ID），重复请求不副作用。
• 版本化更新（CAS）：把版本号放在 value/哈希字段里，WATCH/Lua 检查版本一致再更新。
• 双写/旁路缓存：先写 DB 再删/设 Redis，或采用延迟双删（写后删缓存 + 延迟再删一次）减少脏读。
• 读己之保障：写成功后 N 秒内强制读主或携带写入版本做校验。
• 审计与修复：离线对账（Hive/ClickHouse）发现不一致→后台修复任务（你已有成熟经验，可以把 Redis Cluster 的对账也纳入）。

🔹 (1) 全量复制（初次同步 / 断线重连）

1. 从节点发送 PSYNC 或 SYNC 给主节点。
2. 主节点执行 bgsave 生成 RDB 快照，并把快照文件发送给从节点。
3. 在生成快照期间，主节点会把新的写操作写入 复制缓冲区 (replication backlog buffer)。
4. 从节点加载 RDB 文件，更新数据。
5. 从节点再接收缓冲区里的增量命令，保证数据和主节点一致。

🔹 (2) 增量复制（部分同步）

• 如果主从之间网络闪断，从节点重连时可以尝试部分同步：
  1. 主节点维护一个 复制偏移量 offset 和 replication backlog buffer（固定大小的环形缓冲区）。
  2. 从节点重连时带上自己上次的 offset。
  3. 如果这个 offset 仍在主节点的 backlog buffer 范围内，主节点就只发缺失的数据。
  4. 否则，执行全量同步。

3. 主从复制的实现细节

• 复制 ID
  • 每个主节点有一个 replication ID。
  • 主节点重启时会生成新的 ID，从节点可用这个 ID 判断是否能部分同步。
• 异步复制
  • 默认是异步，主节点不等待从节点确认就返回客户端。
  • 可以配置 WAIT 命令来要求同步到多少个从节点才返回。
• 读写分离
  • 主节点负责写，从节点可以读，提高吞吐量。
  • 缺点：可能读到旧数据（延迟复制）。

1. TCP 头部字段（最小 20 字节，常见如下）

2. UDP 头部字段（固定 8 字节）

1. Spring Boot 是怎么加载 Bean 的？

• 启动过程：Spring Boot 启动时，会加载 ApplicationContext → 通过类路径扫描和自动配置发现要托管的类。
• 加载机制：
  1. 扫描带有 @Component、@Service、@Repository、@Controller 等注解的类；
  2. 解析 @Configuration 中的 @Bean 方法；
  3. 根据 spring.factories / @EnableAutoConfiguration 加载自动配置类；
  4. 统一注册到 BeanDefinitionMap，通过 反射 或 CGLIB 动态代理创建对象并注入依赖。

2. 反射为啥会影响性能？

• 正常调用：方法调用是 JVM 已优化的直接调用（有内联、JIT 优化）。
• 反射调用：绕过编译期检查 → 运行时查找类信息、校验安全性、方法分派，需要频繁访问 Method/Field 元信息表。
• 影响：多了一层动态解析，CPU cache 友好性差，JIT 优化也受限 → 性能比直接调用低。

3. 线程安全的工作原理是啥？

• 定义：多线程访问同一对象/方法时，不会出现数据不一致、状态错乱。
• 实现方式：
  • 互斥同步：如 synchronized、ReentrantLock，通过锁保证同一时间只有一个线程访问。
  • 非阻塞同步：CAS（Compare-And-Swap）+ 原子类，保证更新操作的原子性。
  • 线程封闭：线程私有变量，避免共享。
  • 不可变对象：对象状态不可修改，天然安全。

4. 主内存和工作内存（JMM）

• 主内存：所有共享变量存放的地方，所有线程可见。
• 工作内存：每个线程的本地副本（类似 CPU 缓存），线程对变量操作时必须从主内存拷贝到工作内存，再回写。
• 关键点：线程不能直接操作主内存，只能通过工作内存；volatile / synchronized 保证内存可见性和有序性。

9. 网络编程里的 IO 模型

常见五种：

1. 阻塞 IO（BIO）：调用阻塞，直到数据就绪。
2. 非阻塞 IO：调用立即返回，需轮询。
3. IO 多路复用：select/poll/epoll，一个线程管理多个连接。
4. 信号驱动 IO：数据就绪时内核发信号通知应用。
5. 异步 IO（AIO）：应用提交请求后，内核完成后直接通知应用处理。

11. TCP 是怎么保证可靠传输的？

• 分片与序号：数据拆分为段，带序号，接收方按序重组。
• 确认应答（ACK）：接收方收到数据后发 ACK，丢失则重传。
• 超时重传：发送方超时未收到 ACK，自动重发。
• 流量控制：滑动窗口机制，防止发送方压垮接收方。
• 拥塞控制：慢启动、拥塞避免、快重传、快恢复，避免网络过载。
• 校验和：保证传输过程数据未被篡改。

流量控制 (Flow Control)

• 目标：防止发送方把数据发得太快，把接收方“撑爆”。
• 机制：由 接收方 通知发送方自己能接收多少数据。
• TCP实现：
  • 接收方在 TCP 头部的 Window Size 字段告诉对方自己的接收缓冲区大小。
  • 发送方根据这个窗口大小，控制发送速率。
  • 如果窗口为 0，表示暂时不能收，发送方会停发，等对方发 窗口更新 再继续。
• 类比：水桶装水，接收方是桶，桶快满了就喊“慢点”，否则会溢出。

拥塞控制 (Congestion Control)

• 目标：防止在网络中注入过多数据，把整个网络“挤爆”。
• 机制：由 发送方 自己感知网络状况来调节速率。
• TCP实现（四大算法）：
  • 慢启动 (Slow Start)：开始时窗口指数级增长。
  • 拥塞避免 (Congestion Avoidance)：接近阈值后线性增长。
  • 快重传 (Fast Retransmit)：收到 3 个重复 ACK 立即重传，不等超时。
  • 快恢复 (Fast Recovery)：拥塞发生后，减小窗口一半而不是清零。
• 类比：高速公路上的车流，发现堵车就得减速，避免进一步拥堵。

✅ 窗口是不是固定的？

不是固定的。

• 窗口大小 会随着网络和接收方的处理能力动态变化。
• 接收方在 TCP 报文头里的 Window Size 字段里告诉发送方自己当前还能接多少数据。
• 另外 TCP 发送方还会维护一个 拥塞窗口（cwnd），受网络状况控制。 最终生效的是：

发送窗口大小 = min(接收窗口, 拥塞窗口)

也就是说，既不能超过接收方的承受能力，也不能超过网络的拥堵程度。

✅ 窗口长度怎么算？

是的，你理解的没错，窗口长度 = 已发送未确认的数据 + 还能发送的数据。

1. synchronized 的特点

• 关键字层面：是 Java 内置关键字，JVM 层面支持，语法简单（方法或代码块加 synchronized）。
• 锁对象：锁定的是对象（实例对象锁或类对象锁）。
• 可重入：同一线程可以重复获取同一把锁，不会死锁。
• 自动释放：代码块/方法执行完自动释放锁，不需要手动操作。
• 性能：JDK1.6 之后经过偏向锁、轻量级锁、自旋锁优化，性能已经大幅提升。
• 限制：功能单一，无法中断等待的线程、无法设置超时、公平性不可控。

2. ReentrantLock 的特点

• 类层面：是 java.util.concurrent.locks 包下的一个实现类，显示地调用 lock() 和 unlock() 来加解锁。
• 可重入：同样支持可重入。
• 高级功能：
  • 可中断：支持 lockInterruptibly()，线程可被中断。
  • 超时获取：支持 tryLock(long timeout, TimeUnit unit)，超时放弃。
  • 公平锁/非公平锁：构造时可指定，保证先来先得。
  • 条件队列：配合 Condition，比 Object.wait/notify 更灵活。
• 需要手动释放锁：如果 unlock() 忘记调用，可能导致死锁。

3. 两者对比

1. 什么是 AQS？

• AQS (AbstractQueuedSynchronizer) 是 JDK 并发包中的一个抽象类。
• 核心思想：用一个 volatile 状态值 + FIFO 双向队列 来管理多线程的竞争和唤醒。
• 提供 独占模式（exclusive，如 ReentrantLock）和 共享模式（shared，如 Semaphore、CountDownLatch）两种资源获取方式。

2. AQS 的核心组成

1. state 变量
   • volatile int state;
   • 表示同步状态，比如锁是否被占用、剩余的许可数等。
   • 通过 CAS (compare-and-swap) 保证修改的原子性。
2. CLH 队列
   • AQS 使用 CLH（双向链表队列） 来保存等待线程。
   • 每个线程排队时会封装成一个 Node，放入队尾。
   • head 和 tail 指针维护队列。
3. Node 节点
   • 保存线程本身（Thread）、等待状态（waitStatus）、前驱/后继引用。
   • 状态标记有：SIGNAL（等待唤醒）、CANCELLED（取消等待）、CONDITION（在条件队列中）等。

3. 获取锁（acquire）的过程（独占模式为例）

1. 尝试获取资源
   • 调用 tryAcquire()（子类实现，如 ReentrantLock）。
   • 如果成功：直接返回。
   • 如果失败：进入等待队列。
2. 入队
   • 将当前线程封装为 Node，CAS 插入到队尾。
3. 自旋等待
   • 线程在队列中循环检查是否能获取到锁：
     • 如果前驱是 head 且资源可用，则 CAS 修改 state 成功并获取锁。
     • 否则阻塞（LockSupport.park()）。
4. 唤醒
   • 前驱节点释放锁时，会唤醒后继节点（LockSupport.unpark()），后继线程继续尝试获取锁。

4. 释放锁（release）的过程

1. 修改 state
   • 调用 tryRelease()（子类实现）。
   • 如果 state == 0（完全释放），说明锁已可用。
2. 唤醒后继节点
   • 唤醒队列中第一个有效的等待线程（head 的 next）。
   • 被唤醒的线程会重新尝试获取锁。

5. 共享模式（Semaphore、CountDownLatch）

• 共享模式下允许多个线程同时获取资源。
• tryAcquireShared() 返回值：
  • < 0：获取失败，入队等待。
  • = 0：获取成功，但没有剩余资源。
  • > 0：获取成功，还有剩余资源。
• 释放时调用 releaseShared()，会唤醒多个节点。

6. 核心思想总结

• state 表示资源状态（锁、信号量、计数器）。
• CAS 保证并发修改安全。
• CLH 队列保证公平排队。
• LockSupport.park/unpark 实现线程挂起和唤醒。

也就是说，AQS 就是一个 可扩展的框架：它自己不定义获取/释放的具体逻辑，而是交给子类（ReentrantLock、Semaphore 等）实现 tryAcquire/tryRelease，然后用 AQS 封装好的排队 + 阻塞 + 唤醒机制来管理并发。

双亲委派模型（Parent Delegation）

定义：类加载器在加载类时，先把请求交给父类加载器去尝试加载，只有父类加载器找不到时，才由当前加载器自己去加载。

主要目的：

1. 避免重复加载：父类加载器加载过的类，子类加载器就不会重复加载。
2. 保证核心类安全：比如 java.lang.Object 必须由最顶层的引导类加载器（Bootstrap ClassLoader）加载，防止被恶意替换。

典型流程（从下往上委派）：

• 自定义类加载器 → 应用类加载器（AppClassLoader） → 扩展类加载器（ExtClassLoader） → 启动类加载器（Bootstrap ClassLoader）。
• 加载一个类时，先问“爸爸”有没有加载过，如果有就直接用；如果没有，再自己加载。

慢 SQL 常见原因

1. 缺少合适索引：条件字段没有索引，导致全表扫描。
2. 索引未命中：例如 like '%abc'、函数操作 where date(create_time)=...，会导致索引失效。
3. 返回数据过多：一次查询几百万行，网络传输和应用层处理都慢。
4. join 设计不当：没有合理索引的多表 join。
5. 排序 / 分组开销大：order by、group by、distinct 没有索引辅助。
6. 统计类函数：count(*) 在大表上性能差（InnoDB 要全表扫描）。
7. 锁/阻塞：事务未提交，SQL 被锁住。

3. 优化思路

1. 加索引
   • 单列索引、联合索引（最左匹配原则）。
   • 覆盖索引（select id,name from user where id=...）。
2. 改写 SQL
   • 避免 select *，只取需要的列。
   • 避免 !=、<>、or 等导致索引失效。
   • 尽量把计算放在等号右边，例如 where create_time >= '2024-01-01'，而不是 date(create_time) = ...。
3. 分库分表 / 限流
   • 大表按时间、用户 ID 做分表。
   • 分页优化：limit 100000, 10 → 用子查询或 ID 范围。
4. 缓存
   • 读多写少的场景，用 Redis/Memcached 缓存热点数据。
5. 架构优化
   • 主从复制：读写分离。
   • 数据仓库：复杂统计查询放到 Hive/ClickHouse。

1. 联合索引的本质

• 联合索引：在多个列上建立的索引，比如 (a, b, c)。
• MySQL 底层存储是 B+Tree，所有索引字段会按照从左到右的顺序组合排序。

定义：MySQL 在使用联合索引时，会从 最左的列开始匹配，能连续利用多少列，就用多少列。

一旦中间断了，就无法继续利用后面的索引列。

因为 B+Tree 的有序性：

• 索引的排序顺序是 (a → b → c)，查询必须遵循这个顺序才能走到具体的节点。
• 如果跳过了 a，就无法确定 b 的范围。
• 这就是为什么 MySQL 要求 从最左边连续匹配。

1. redo log（重做日志，InnoDB 专有）
   • 物理日志，记录“数据页修改了什么”。
   • 作用：保证 崩溃恢复（crash-safe）。即使 MySQL 异常宕机，也能用 redo log 把已提交事务恢复出来。
2. binlog（归档日志，Server 层）
   • 逻辑日志，记录“执行了什么 SQL/行操作”。
   • 作用：保证 主从复制、数据恢复。
   • 是 MySQL Server 层统一的日志，所有引擎都能用。

两阶段提交（保证两种日志一致）

问题：如果先写 redo log 再写 binlog，中途宕机，可能 redo log 有事务，binlog 没有，主从不一致。 解决：两阶段提交（2PC），保证 redo log 和 binlog 的一致性。

流程：

1. 写入 redo log（prepare 阶段）
   • 把 redo log 写入磁盘，但标记为 “prepare”，表示事务还没提交。
2. 写入 binlog
   • 把 binlog 写入磁盘，刷盘成功。
3. 提交 redo log（commit 阶段）
   • 修改 redo log 标记为 “commit”。
   • 至此事务才算真正提交。

MySQL（InnoDB 引擎）主要通过 undo log + 两阶段提交 来实现原子性。

(1) Undo Log（回滚日志）

• 当事务执行 UPDATE/DELETE/INSERT 时，InnoDB 会生成一份 相反操作的日志。
  • UPDATE：记录旧值，便于回滚。
  • DELETE：记录被删除的数据，用来恢复。
  • INSERT：记录新插入的主键，回滚时删除。
• 如果事务执行失败或显式 ROLLBACK，就通过 undo log 把数据恢复到原始状态。

👉 这保证了事务失败时，可以回到“没执行之前”的样子。

(2) Redo Log + Binlog 的两阶段提交

• 为了保证事务成功时，数据不会丢，InnoDB 还配合 redo log 和 binlog。
• 两阶段提交流程：
  1. 写入 redo log（prepare）：标记事务即将提交。
  2. 写入 binlog：写入逻辑日志。
  3. 提交 redo log（commit）：事务正式提交。
• 如果中途崩溃，恢复时根据 redo log 和 binlog 的一致性判断事务是“完成”还是“回滚”。

👉 这保证了事务提交后，要么 redo/binlog 都有，要么都没有，不会出现“一半成功”。

redo log（重做日志，物理日志，InnoDB 专有） 记录“某个页上做了什么修改”，保证 崩溃恢复（crash-safe）。

undo log（回滚日志，逻辑日志，InnoDB 专有） 记录“相反操作”，用于事务回滚，保证 原子性。

binlog（归档日志，逻辑日志，Server 层） 记录“执行了什么 SQL/行操作”，用于 主从复制、数据恢复。

（1）事务执行过程

1. 写 undo log（记录老版本）
   • 更新前先写 undo log，以便失败时回滚。
2. 修改内存数据（Buffer Pool）
   • 把数据页加载到内存并修改，此时还没写入磁盘。
3. 写 redo log（prepare 阶段）
   • 把修改写入 redo log buffer，并刷盘（标记为 prepare）。
   • 保证即使宕机，也能用 redo log 重放修改。
4. 写 binlog
   • 把 SQL/行修改写入 binlog cache，提交时统一刷盘。
5. 提交 redo log（commit 阶段）
   • 修改 redo log 状态为 commit，事务正式提交。

Redis 本质上是一个 单线程事件驱动 的服务器，它的网络模型基于：

• I/O 多路复用（epoll/kqueue/select）
• 文件事件处理器（File Event Handler）
• 单线程 + 非阻塞 I/O

避免线程切换开销：单线程就没有锁竞争。

大部分操作在内存中完成：CPU 不是瓶颈，主要瓶颈在网络 I/O。

I/O 多路复用高效：epoll 能同时处理上万连接。

分布式系统里的 几个核心问题 和 常见解决方案详细讲一下：

1. 数据一致性问题

问题：多个副本同时更新，可能出现不一致（读到旧数据、丢更新）。

解决方案：

• 强一致性（CP）
  • 用 共识算法 保证：如 Paxos、Raft。
  • 一个写请求必须在大多数节点确认后才算成功（例如：Etcd、Zookeeper）。
• 最终一致性（AP）
  • 写请求先到主节点，异步复制到从节点。
  • 短时间内可能读到旧数据，但最终会收敛一致。
  • 典型应用：Redis 集群、消息队列、DynamoDB。
• 读写分离优化
  • 对一致性要求高的读 → 走主库。
  • 对实时性要求低的读 → 走从库。

👉 一句话：一致性依靠 共识协议 或 最终一致性模型来实现，取决于业务对一致性的要求。

2. 网络问题

问题：延迟、丢包、网络分区（部分节点之间无法通信）。

解决方案：

• 心跳检测 + 超时机制
  • 每个节点周期性发送心跳，超时没回应就判定异常（如 Raft 选举）。
• 重试 / 重传
  • 网络丢包时自动重试。
  • 幂等性设计很关键，避免重试导致重复操作。
• CAP 权衡
  • 出现网络分区时，系统必须在 一致性 C 和 可用性 A 之间做取舍。
  • 例如：Zookeeper 选择保证 C，某些 NoSQL 选择保证 A。

3. 节点故障

问题：节点可能宕机，服务不能用。

解决方案：

• 副本机制（Replication）
  • 每份数据至少存多个副本（主从复制）。
  • 一个节点挂了，数据不会丢失。
• 故障转移（Failover）
  • 检测到主节点挂了，自动把从节点提升为主节点。
  • 例如：Redis Sentinel、Kafka Controller。
• Leader 选举
  • 通过共识算法（如 Raft、ZAB）选举新的 Leader，维持集群一致性。

4. 数据分片与路由

问题：数据量太大，单机存不下。

解决方案：

• 哈希取模分片
  • hash(key) % N，简单直接，但扩容时迁移数据量大。
• 一致性哈希
  • 数据和节点都映射到哈希环，扩容/缩容时只迁移部分数据。
  • 常见于 缓存系统（Memcached、Redis 集群）。
• 分片键（Sharding Key）
  • 选择一个业务字段作为分片维度（如用户 ID、订单 ID）。
  • 请求时通过分片键路由到对应分片。

5. 分布式事务

问题：多个数据库 / 服务参与同一个事务时，难以保证 ACID。

解决方案：

• 2PC（两阶段提交）
  • 阶段一：协调者询问各节点能否提交。
  • 阶段二：若都同意则提交，否则回滚。
  • 缺点：阻塞、单点故障风险。
• 3PC（三阶段提交）
  • 在 2PC 基础上增加预提交和超时机制，减少阻塞风险，但实现复杂。
• TCC（Try-Confirm-Cancel）补偿事务
  • 每个操作拆成三个步骤：预留资源 → 确认 → 取消。
  • 常用于电商支付、库存场景。
• 本地消息表 / 可靠消息 + 最终一致性
  • 把事务状态写入消息表，由消息系统保证最终一致。
  • 典型应用：电商下单 + 扣库存。

消息队列（MQ）的 推/拉模式 是个经典话题。我们可以从概念、流程、优缺点、应用场景四个角度来看：

1. 概念

• 拉模式（Pull）：消费者主动向 MQ 请求消息，类似“我去拿”。
• 推模式（Push）：MQ 主动把消息推送给消费者，类似“送上门”。

很多 MQ（Kafka、RocketMQ、RabbitMQ）其实都 支持两种模式，或者底层是拉，但对外封装成推。

2. 流程

拉模式

1. 消费者周期性向 Broker 发起拉取请求。
2. Broker 返回一批消息，如果没有消息可能返回空。
3. 消费者自己决定什么时候再拉。

推模式

1. Broker 监听到有新消息。
2. 主动把消息推送到消费者（通常通过长连接）。
3. 消费者处理后返回确认（ACK）。

3. 优缺点

在 分布式系统 + 消息队列 中，“消息幂等”是面试必考点。因为 MQ 天然可能出现：

• 消息重复投递（Producer 重试 / Broker 重发 / Consumer 超时 ACK）。
• 消息重复消费（Consumer 崩溃重启 / ACK 丢失）。

(1) 唯一消息 ID + 去重表

• 做法：
  • Producer 给消息加全局唯一 ID（如订单号、UUID）。
  • Consumer 消费时，先查去重表（如 Redis/数据库）。
  • 处理过则丢弃，没处理过则执行并写入去重表。
• 优点：适合强一致性场景。
• 缺点：需要维护额外存储，性能压力大。

(2) 利用业务唯一键

• 做法：业务本身就有唯一约束，比如：
  • 支付场景：order_id 已唯一，不可能重复扣款。
  • 数据写库：用 INSERT ... ON DUPLICATE KEY UPDATE。
• 优点：不需要额外存储，利用业务天然幂等。
• 缺点：依赖业务特性，不通用。

(3) 记录消息处理状态

• 做法：维护 msg_id → status，状态可为：未处理 / 处理中 / 已处理。
• 步骤：
  1. 消费消息时先查状态。
  2. 如果已处理 → 跳过。
  3. 如果未处理 → 标记处理中 → 执行业务 → 标记已处理。
• 典型实现：用数据库表或 Redis。

(4) 幂等操作设计

• 做法：让操作本身支持幂等。
  • 设置用户余额时用 set balance=100 而不是 balance+=100。
  • 更新库存时用 库存 = max(0, 当前库存 - N)。
• 优点：操作本身无论执行多少次结果相同。
• 缺点：不是所有业务都能改造为幂等操作。

(5) 分布式锁

• 做法：消费消息前获取分布式锁（如 Redis 锁），保证同一消息只能一个消费者执行。
• 缺点：增加系统复杂度，吞吐量下降，不适合高并发场景。

常见 OOM 出现场景

不同内存区域都可能 OOM：

(1) Java Heap Space

• 原因：对象过多，堆空间不足。
• 场景：集合不断加元素、缓存不清理、加载过多大对象。
• 异常：java.lang.OutOfMemoryError: Java heap space

(2) GC Overhead Limit Exceeded

• 原因：JVM 花费过多时间在 GC，但回收内存效果很差。
• 场景：内存不足，大量对象存活，GC 一直在忙。
• 异常：java.lang.OutOfMemoryError: GC overhead limit exceeded

(3) Metaspace / PermGen（JDK8 前是 PermGen，JDK8+ 是 Metaspace）

• 原因：类太多，元数据区放不下。
• 场景：动态生成很多类（反射、CGLIB 动态代理）、频繁加载卸载类（Web 容器热部署）。
• 异常：java.lang.OutOfMemoryError: Metaspace

(4) Direct Buffer Memory

• 原因：使用 NIO 时分配了太多堆外内存，没释放。
• 场景：Netty、Kafka 使用 DirectByteBuffer，超出 -XX:MaxDirectMemorySize。
• 异常：java.lang.OutOfMemoryError: Direct buffer memory

(5) Unable to create new native thread

• 原因：系统线程数达到上限，无法再创建新线程。
• 场景：线程池参数设置不当，疯狂 new Thread。
• 异常：java.lang.OutOfMemoryError: unable to create new native thread

(6) Out of swap space

• 原因：物理内存 + 交换分区都耗尽。
• 场景：进程占用太多内存，系统 OOM。
• 异常：java.lang.OutOfMemoryError: Out of swap space

3. 为什么会出现 OOM？

• 代码问题：内存泄漏（对象没释放）、死循环创建对象。
• 配置不足：堆大小、元空间大小设置太小。
• 使用不当：线程池/缓存/DirectBuffer 配置错误。
• 高并发/大数据量：超出单机内存极限。

栈溢出后程序会怎样？

• 不会整个进程立刻终止。

• 表现为当前线程抛出 StackOverflowError：

  • 如果异常没有被捕获，线程会终止。
  • 如果是主线程栈溢出 → 主线程终止 → 整个程序退出（因为主线程挂了）。
  • 如果是子线程栈溢出 → 只有该子线程终止，进程继续运行，其他线程不受影响。

  StackOverflowError 可以捕获，捕获后程序有机会继续运行；

  但栈空间已经濒临极限，继续运行并不可靠；

  正确做法是 避免栈溢出，而不是“捕获它”。

现在主流的 HotSpot JVM（包括 OpenJDK）中：

• 每个 Java 线程对应一个操作系统原生线程（kernel thread）。
• 线程调度完全交给操作系统（Linux 用 pthread，Windows 用 Win32 thread）。

所以 Java 的 Thread 是 对操作系统线程的封装。

🔹 第一范式（1NF：原子性）

定义：字段必须是原子值，不可再分。

• 表中每一列都不能再拆分成更小的字段。
• 每一行、每一列的交叉点必须是单一值，而不是集合或重复组。

例子： ❌ 错误设计：

电话有两个值，不满足 1NF。

✅ 正确设计：

🔹 第二范式（2NF：消除部分依赖）

定义：在 1NF 基础上，表中的非主属性必须完全依赖于主键，不能只依赖主键的一部分。

• 针对复合主键（由多个字段组成主键）。
• 消除“部分依赖”。

例子： ❌ 错误设计： 主键 = (学号, 课程号)

问题：

• 姓名只依赖于学号，不依赖课程号。
• 出现冗余（一个学生选多门课，姓名会重复）。

✅ 正确设计： 拆成两张表：

• 学生表： (学号, 姓名)
• 选课表： (学号, 课程号, 成绩)

🔹 第三范式（3NF：消除传递依赖）

定义：在 2NF 基础上，非主属性之间不能存在传递依赖。

• 换句话说，非主键字段只能直接依赖于主键，不能依赖于其他非主键字段。

例子： ❌ 错误设计：

问题：

• 学号 → 系别 → 系主任
• 系主任对学号是“传递依赖”。

✅ 正确设计： 拆成两张表：

• 学生表：(学号, 姓名, 系别)
• 系别表：(系别, 系主任)

🔹 总结对照表

多个客户端的请求管理其实就是 并发请求的接收、分发和处理，同时要保证系统的 高效性、可靠性和可扩展性。我分几个层次来解释：

1. 请求接入层（入口管理）

• 连接管理 服务端会维护客户端与服务器之间的连接（例如 TCP 连接、HTTP 长连接、WebSocket）。
  • 常见做法：通过 连接池 或 线程池 来复用连接，避免每次请求都重新建立连接的开销。
• 负载均衡 在分布式部署中，请求通常会先经过 负载均衡器（如 Nginx、LVS、K8s Ingress），将流量分配到不同服务节点。

2. 请求调度层（并发控制）

• 线程池 / 协程池 服务器通常不会“一个请求 → 一个线程”直接处理（那样容易导致资源耗尽）。
  • Java 里用 线程池（ThreadPoolExecutor） 管理请求。
  • Go 使用 goroutine + channel 并发调度。
• 队列机制 请求进入时可能会先放入队列（如阻塞队列、消息队列），再由工作线程按序消费，防止系统过载。

3. 请求处理层（业务逻辑）

• 无状态处理 HTTP 请求常常是无状态的，服务器根据请求参数独立完成处理。状态信息（如用户会话）一般存储在 Session、Redis、JWT Token 等。
• 事务与锁 多个请求可能访问同一份资源（数据库记录、缓存 key）。服务端要用 锁、CAS、乐观锁、悲观锁 等方式保证一致性。
• 异步与并发优化 耗时操作（IO、数据库、远程调用）可通过 异步化、事件驱动、批量化 等方式优化。

4. 请求返回层（响应管理）

• 同步响应 请求处理完成后直接返回结果（常见于 REST API）。
• 异步响应 请求先返回“已接受”，真正结果通过 回调 / 消息通知 / WebSocket 再告知客户端。
• 限流与熔断 当请求量过大，服务端会进行 限流（如令牌桶算法）、熔断（避免级联失败），保证核心服务可用。

5. 日志与监控

• 每个请求都会被记录日志（请求时间、耗时、返回状态）。
• 服务端会用 监控系统（Prometheus, Grafana, ELK） 实时跟踪请求量、延迟、错误率等，辅助自动伸缩或故障排查。

✅ 总结一句话： 服务端管理多个客户端请求的核心就是：入口限流 → 并发调度 → 正确处理 → 高效返回 → 监控保障。

Nginx 的核心功能

1. Web 服务器

• 可以直接处理 静态资源（HTML、CSS、JS、图片、视频等），速度快、占用内存少。
• 常用场景：部署静态网站、作为应用的前端静态资源服务器。

2. 反向代理

• Nginx 不仅能作为正向代理（帮用户访问外网），更常见的是 反向代理：
  • 用户请求 → Nginx → 转发到后端服务器（如 Tomcat、Spring Boot、Flask 等）。
• 好处：隐藏后端服务，提升安全性和可扩展性。

3. 负载均衡

• 当有多台后端服务器时，Nginx 可以把请求分配给不同机器，常见策略有：
  • 轮询（Round Robin）
  • 最少连接数（Least Connections）
  • IP 哈希（保证同一客户端固定到同一台服务器）

4. 高并发能力

• Nginx 基于 事件驱动模型（epoll/kqueue），可以在少量进程下支撑成千上万的并发连接。
• 这点比传统的 Apache（一个连接一个线程/进程）更高效。

Nginx 一般部署在哪里？

Nginx 常见的部署位置有：

1. 前端服务器（入口层）
   • 部署在最靠近用户的一层（公网可访问的机器上）。
   • 功能：作为 网关、反向代理，统一接收客户端请求，再转发到后端。
   • 示例：电商网站首页静态资源由 Nginx 提供，API 请求再反向代理到 Java/Python 后端服务。
2. 应用前的负载均衡器
   • 部署在 多台应用服务器前，把流量均衡分配。
   • 功能：均衡请求，避免某一台机器过载。
   • 示例：Nginx → {Tomcat1, Tomcat2, Tomcat3}。
3. 微服务网关的一部分
   • 在微服务架构中，Nginx 常与 K8s Ingress、API Gateway 配合。
   • 功能：做 动静分离、限流、路由分发，保护后端微服务。

🔹 什么是正向代理 (Forward Proxy)？

• 代理对象：代理 客户端。
• 工作方式：客户端先把请求发给代理服务器 → 代理服务器再去访问目标服务器 → 把结果返回给客户端。
• 核心作用：隐藏客户端，目标服务器不知道真实的客户端是谁。
• 常见用途：
  • 科学上网 / 翻墙（代理帮你访问目标网站）。
  • 内网机器访问外网。
  • 缓存代理，加速常用网站访问。

例子： 你在中国访问 google.com，由于无法直连，你先访问正向代理（比如一个国外代理服务器），由它帮你访问 Google，再把结果转发回来。

🔹 什么是反向代理 (Reverse Proxy)？

• 代理对象：代理 服务器。
• 工作方式：客户端请求发给代理服务器（如 Nginx），代理服务器再决定把请求转发给哪一台后端服务器 → 返回结果。
• 核心作用：隐藏服务器，客户端不知道真实的后端服务器是谁。
• 常见用途：
  • 负载均衡（流量分发到不同后端）。
  • 动静分离（静态资源直接由代理返回，动态请求转发到后端）。
  • 安全防护（隐藏真实后端 IP，避免攻击）。

例子： 你访问 www.taobao.com，实际上请求先到阿里云的反向代理（比如 Nginx / SLB），再由它转发到真正的后端服务器集群。

索引建立的核心原则：

1️⃣ 索引适合建立在「高频查询」的列上

• WHERE 条件、JOIN 条件、ORDER BY/GROUP BY 中用到的列。

• 例如：

  SELECT * FROM user WHERE email = 'xxx@xxx.com';
  

  如果 email 经常被用作查询条件，就应该给它建索引。

2️⃣ 选择区分度高的列

• 区分度（基数）：指该列不同值的数量 / 总行数。
• 区分度高 → 查询过滤效果好，索引效率高。
• 举例：
  • 身份证号（几乎唯一） → 适合建索引。
  • 性别（只有“男/女”两种值） → 不适合单独建索引。

3️⃣ 组合索引 > 单列索引

• 如果查询条件经常涉及 多个字段，优先考虑建立 联合索引。
• 原则：最左前缀原则（索引从左到右生效）。
  • 索引 (a, b, c) 可以支持以下查询：
    • WHERE a = ?
    • WHERE a = ? AND b = ?
    • WHERE a = ? AND b = ? AND c = ?
  • 但不能单独高效支持 WHERE b = ?。

4️⃣ 避免在频繁更新的列上建索引

• 因为每次 INSERT/UPDATE/DELETE 都要维护索引，会增加写入成本。
• 例如：日志表里的 last_modified_time 经常更新，不适合单独建索引。

5️⃣ 控制索引数量

• 一张表的索引数不宜过多（通常建议 <5）。
• 太多索引会：
  • 占用磁盘空间。
  • 影响写入性能。
  • 查询优化器在选择索引时也会变慢。

6️⃣ 使用前缀索引（针对长字符串列）

• 对于 TEXT / VARCHAR 很长的字段，可以只索引前几个字符。

• 例如：

  CREATE INDEX idx_email ON user(email(10));
  

  节省空间，但要注意区分度是否足够。

7️⃣ 覆盖索引（索引即结果）

• 如果一个查询需要的字段都在索引里，可以避免回表，提高性能。

• 例如：

  SELECT id, email FROM user WHERE email = 'xxx';
  

  如果索引 (email, id) 已经存在，就能直接返回结果，无需再查主表。

8️⃣ 考虑排序和分组需求

• ORDER BY、GROUP BY 经常用到的列，也可以建立索引。

• 例如：

  SELECT * FROM orders ORDER BY create_time DESC LIMIT 10;
  

  给 create_time 建索引，可以避免排序开销。

9️⃣ 结合业务场景

• 唯一性约束 → 用唯一索引（如手机号、邮箱）。
• 范围查询（BETWEEN, >, <） → 适合建索引，但要注意范围查询会影响联合索引的利用。
• 全文搜索 → 考虑全文索引（MySQL InnoDB 的 FULLTEXT 或 ES）。

redis分布式锁

1️⃣ 最基础实现：SETNX

• SETNX (SET if Not Exists)：只有当 key 不存在时才写入成功。
• 典型写法：

SETNX lock_key unique_id  # 成功=拿到锁
EXPIRE lock_key 10        # 设置过期时间，防止死锁

问题：这两步不是原子操作，可能 SETNX 成功了还没来得及 EXPIRE 就挂了 → 死锁。

2️⃣ 改进版：原子 SET 带参数

Redis 2.6.12+ 提供：

SET lock_key unique_id NX PX 10000

• NX：仅当 key 不存在时设置
• PX 10000：设置过期时间（10 秒）
• 一步到位，原子操作，解决了死锁问题。

👉 注意：unique_id 是客户端生成的唯一值（如 UUID），用来标识“是谁加的锁”。

🎯 想象一个现实场景 —— 公共厕所的隔间

• 厕所隔间 = 共享资源（比如数据库记录、文件、库存）
• 门上的锁 = 分布式锁
• 人 = 分布式系统里的不同进程/服务

1️⃣ 加锁：先到先得

小明要上厕所，他先看门上有没有挂“有人”的牌子。

• 如果没有（SETNX 成功），他立刻挂上自己的名字牌（uuid），并且写上“使用时间 30 分钟后自动清空”（PX 30000）。
• 如果已经有人挂了牌子，小明只能等一会儿再试（重试 + 退避）。

👉 这就是 Redis 加锁：保证同一时间只有一个人（进程）能进。

2️⃣ 解锁：只能自己开

小明用完出来了，要把牌子摘掉。

• 但要注意：如果直接把牌子拿掉（DEL），可能误删别人的！
  • 比如小明挂的 30 分钟牌子过期了，他还没出来；小红后来进去了并挂上了自己的牌子。
  • 这时如果小明一出门就粗暴地把牌子扔了，就把小红的锁删掉了。

👉 所以必须先确认“牌子上还是我的名字”（校验 uuid），才能删。 这就是 Lua 脚本解锁。

3️⃣ 锁过期：占太久会被清理

假设小明忘记出来，超过 30 分钟了，厕所管理员会把“有人”牌子自动摘掉。

• 这时其他人（小红）可以进来了。
• 但是小明其实还在里面没出来，于是小明和小红同时使用厕所 —— 锁失效了！

👉 这就是 锁过期 + 进程卡顿 带来的并发进入问题。

4️⃣ 看门狗机制：自动续期

为了避免小明被赶出来，他带了一只“看门狗”，每隔 10 分钟就帮他去刷新牌子上的时间（PEXPIRE）。

• 如果小明还在里面，牌子时间就会延长。
• 如果小明已经出来了，狗发现牌子上不是小明的名字，就不会续期。

👉 这就是 锁自动续期（watchdog）。

5️⃣ 主从复制延迟：双重预订

厕所有两个管理员（Redis 主从）。

• 小明在主管理员那里挂上牌子，但牌子还没来得及同步到从管理员。
• 突然主管理员晕倒了，从管理员接手，却没看到牌子，于是允许小红也挂上牌子。
• 结果小明和小红都进去了！

👉 这就是 Redis 异步复制带来的双持有问题。

解决方法：

• 要么找更靠谱的管理员（ZooKeeper/etcd 这种 CP 系统），
• 要么给每个人发 入场号（fencing token），厕所只认最大的号。

在计算机中，幂等（Idempotency） 指的是： 一个操作，无论执行一次还是执行多次，产生的效果都是一样的，不会因为重复调用而产生副作用。

🔹 日常生活类比

• 电梯按钮：你按一次电梯「上」按钮，它亮了；你再按十次，电梯还是只亮一个灯，不会派十部电梯来。
• 开灯开关：第一次按下开关 → 灯亮了，再按下去不会让灯更亮，操作结果保持一致。

👉 这就是幂等：重复执行不影响最终结果。

想象你要和银行（网站）打电话（建立连接），电话线（网络）不安全，可能有人窃听。于是你们约定了一个安全流程：

1. 打招呼（Client Hello）： 你告诉银行：「我支持 AES、RSA、TLS1.3 等加密方式，还有一个随机数 random1。」
2. 回应（Server Hello）： 银行说：「我选用 AES256 这种加密方式，这是我的数字证书（证明我是合法银行），再给你一个随机数 random2。」
3. 验证证书： 你拿到银行的证书，去权威机构（CA 公钥）验证，确认证书有效且没被篡改，确保对方不是骗子。
4. 生成密钥（Key Exchange）：
   • 你和银行用 random1 + random2 + （可能再加 random3） 生成一个「会话密钥」。
   • 这个过程可能用 RSA 或者 Diffie-Hellman(ECDHE) 算法，保证别人即使偷听，也无法推算出密钥。
5. 握手确认（Finished）： 双方用刚才生成的会话密钥互相加密发一句：「OK，我准备好了」。 收到能解开，说明密钥一致，握手成功。
6. 安全通信开始： 后续所有数据（HTTP 请求、响应）都用会话密钥对称加密传输。

底层实现 & 迭代器有效性（为啥会“失效”）

不同容器的迭代器，本质上指向“元素位置”。位置可能是：

• 连续内存的地址 + 偏移（vector, string, deque 一部分）：扩容/搬迁时，旧地址全部失效。
• 节点指针（list, map, unordered_*）：每个元素单独的节点，插入/删除其它节点一般不影响现有迭代器；被删除的那个迭代器当然失效。

典型规则（C++）：

• vector
  • push_back 导致扩容或 insert/erase 发生移动：可能使全部或部分迭代器失效。
  • reserve() 可减少扩容次数，从而减少失效。
• deque
  • 分段连续，插入/删除首尾较安全；中间插入移动代价大且可能失效。
• list（双向链表）
  • 除了被删节点自身，其它迭代器稳定（stable）。
• map/set（红黑树，节点式）
  • 插入/删除只使受影响节点的迭代器失效；其它迭代器通常稳定。
• unordered_map/set（哈希）
  • rehash（扩容重排桶）会使所有迭代器失效；单次插删通常只影响该元素。

Java 的 fail-fast 原理（简化）：容器维护 modCount，每个迭代器保存创建时的 expectedModCount；遍历过程中发现不一致就抛错。它不修复，只是快速发现“你边遍历边改”的不安全行为。

1. A – 原子性 (Atomicity)

👉 事务中的操作要么全部成功，要么全部失败。

• 实现机制：Undo Log（回滚日志）
  • 在事务执行前，InnoDB 会把需要修改的数据的旧值写入 Undo Log。
  • 如果事务执行失败或被回滚，系统可以根据 Undo Log 把数据恢复到原来的状态。
  • 类似于“后悔药”。

2. C – 一致性 (Consistency)

👉 事务执行前后，数据库要从一个一致状态变为另一个一致状态（比如满足约束条件）。

• 实现机制：
  • 原子性、隔离性 和 持久性的综合作用。
  • 依赖 约束机制（外键、唯一约束、触发器）+ 日志恢复，确保数据不违反规则。
  • 举例：银行转账，A 扣 100，B 加 100；即使中途失败，也不会出现钱凭空消失或凭空产生的情况。

3. I – 隔离性 (Isolation)

👉 多个事务之间相互隔离，避免相互干扰。

• 实现机制：锁机制 + MVCC（多版本并发控制）
  • 锁：行锁、间隙锁、表锁，保证数据不会被并发事务破坏。
  • MVCC：通过保存数据的多个版本 + Undo Log + 隐藏列（事务 ID、回滚指针），让读操作不阻塞写，写也不阻塞读。
  • 不同的 隔离级别（READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ、SERIALIZABLE）就是在锁和 MVCC 策略上的不同选择。

4. D – 持久性 (Durability)

👉 事务一旦提交，就必须永久保存，不会因为宕机而丢失。

• 实现机制：Redo Log（重做日志） + WAL（Write-Ahead Logging）机制
  • InnoDB 先把数据变更记录写入 Redo Log（顺序写，效率高），再写入数据文件。
  • 即使宕机，重启时 MySQL 会通过 Redo Log 把数据恢复到最新提交的状态。
  • 结合 binlog（归档日志），还能做主从复制、数据恢复。

🌟 为什么需要 MVCC？

如果只有锁（读锁、写锁），会导致：

• 读和写互相阻塞 → 并发性能差。
• 读多写少的场景下，效率尤其低。

👉 MVCC 的目标：让读操作几乎不阻塞写，写操作也几乎不阻塞读。

⚙️ MVCC 的实现核心

在 InnoDB 中，MVCC 主要依赖以下机制：

1. 隐藏列
   • 每行数据除了用户定义的字段，还有两个隐含字段：
     • DB_TRX_ID：最近一次修改这行的事务 ID
     • DB_ROLL_PTR：回滚指针，指向 Undo Log（历史版本）
   • 有时还会有 DB_ROW_ID（唯一标识行）。
2. Undo Log（回滚日志）
   • 当事务修改一行数据时，会把旧值保存到 Undo Log。
   • 这样就能“回溯”到某个历史版本的数据。
3. ReadView（读视图）
   • 一个事务在 执行查询时 会生成一个“视图”，记录当前活跃事务 ID 的范围。
   • 之后的查询就根据这个视图来决定能看到哪个版本的数据。

📌 不同隔离级别下的 MVCC 表现

• READ COMMITTED（读已提交） 每次 SELECT 都生成新的 ReadView → 可能出现不可重复读。
• REPEATABLE READ（可重复读，InnoDB 默认） 第一次 SELECT 时生成 ReadView，整个事务中都复用它 → 避免不可重复读。
• SERIALIZABLE 不使用 MVCC，而是直接用锁来强制串行执行。

🔎 举个例子

假设表中有一条数据 balance=100，事务 ID = 10。

1. 事务 A（ID=20）开始查询 balance，此时生成 ReadView，只能看到 ID≤10 的数据。
2. 事务 B（ID=30）更新 balance=200，并提交 → 新版本写入数据行，旧版本保存到 Undo Log。
3. 事务 A 再次查询时，依旧用最初的 ReadView → 只能看到旧版本 balance=100，而不会受事务 B 的影响。
4. 新事务 C（ID=40）查询时 → 它的 ReadView 已包含 B 的更新，因此能读到 balance=200。

👉 这样就实现了 读写互不阻塞，读者能“看到属于自己时空的历史版本”。

MySQL 性能监控一般要从 数据库本身运行状态 + 业务访问情况 + 系统资源使用 三个维度来看。常见指标可以分几类：

1. 连接与线程相关

• Threads_connected：当前已建立的客户端连接数。
• Threads_running：正在执行 SQL 的线程数（高了说明并发压力大）。
• Max_used_connections：历史峰值连接数，用来判断 max_connections 配置是否合理。
• Aborted_connects：失败的连接次数，可能说明有应用异常或权限配置错误。

2. 查询与事务相关

• Queries / Questions：单位时间内的 SQL 执行次数。
• Com_select / Com_insert / Com_update / Com_delete：不同类型 SQL 的执行次数，可以分析读写比例。
• Transactions（事务提交/回滚次数）：Com_commit、Com_rollback。
• Slow_queries：慢查询数量，需要结合 slow_query_log 分析。

3. InnoDB 存储引擎指标

• Buffer Pool 命中率：
  • 指标：Innodb_buffer_pool_read_requests vs Innodb_buffer_pool_reads
  • 命中率低 → 说明内存不够，经常要去磁盘读。
• 行锁冲突情况：
  • Innodb_row_lock_waits（行锁等待次数）、Innodb_row_lock_time（总等待时间）。
• Redo/Undo 日志：
  • Innodb_log_waits：redo log 太小导致写入阻塞。
• 事务等待：是否有大量事务长时间未提交，导致锁竞争。

4. 延迟与执行情况

• 平均查询执行时间（QPS、TPS）：通过 performance_schema 或监控系统统计。
• 等待事件：哪些 SQL 在等 IO、等锁，可以用 performance_schema.events_waits_summary_global_by_event_name 分析。
• 慢查询日志：具体 SQL 语句、执行时间、扫描行数。

5. 复制与高可用（主从架构时）

• Seconds_Behind_Master：从库延迟。

• Relay_Log_Space：从库 relay log 大小，说明复制积压情况。

• Slave_IO_Running / Slave_SQL_Running：从库复制线程是否正常。

找到慢 SQL 后，用以下方法分析：

🔍 (1) EXPLAIN 执行计划

EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = 'paid';

重点关注字段：

• type：访问类型（ALL=全表扫描，ref=索引，const=常量最优）。
• key：实际用到的索引。
• rows：预估扫描行数。
• Extra：是否出现 Using filesort、Using temporary（说明性能差）。

🔍 (2) SHOW PROFILE

SET profiling = 1;
SELECT * FROM orders WHERE user_id=123;
SHOW PROFILES;
SHOW PROFILE FOR QUERY 1;

可以看到 SQL 执行的时间分布：解析、优化、锁等待、执行。

🔍 (3) Performance Schema

MySQL 5.6+ 内置，可以分析等待事件、I/O 热点。

SELECT * FROM performance_schema.events_statements_summary_by_digest
ORDER BY AVG_TIMER_WAIT DESC
LIMIT 5;

覆盖索引（Covering Index）是数据库（尤其是 MySQL InnoDB 引擎里）一个重要的优化手段。

定义

当一个索引包含了 查询中需要的所有列 时，这个索引就叫做覆盖索引。 换句话说，查询只需要通过索引就能拿到结果，不必回表（再去主键索引或数据页中取完整行）。

优点

• 避免回表 → 减少随机 I/O，提升查询性能。
• 减少锁开销 → 因为只访问索引页，不必访问数据页。
• 更快的响应 → 特别适合高并发读多写少的场景。

使用场景

• 频繁执行的查询，只涉及索引中字段的 SELECT。
• 需要快速分页、统计的查询。
• 数据分析类查询（比如 SELECT COUNT(*) FROM ... WHERE ...）。

Elasticsearch 是一个分布式搜索和分析引擎，核心价值：

• 存数据：能像数据库一样存 JSON 文档。
• 查数据：能用极快的速度搜索和过滤。
• 分析数据：能做聚合统计，支持实时数据分析。

📖 生活化类比

你可以把 ES 想象成一个“超级图书馆检索系统”：

• 数据库（比如 MySQL）更像是“存档室”：你要精确知道“书的编号”，它能快速取出来。
• Elasticsearch 更像“图书馆检索”：你只记得书名里有几个词，或者想找“所有讲机器学习的书”，它能在几百万本书里快速给你结果，还能告诉你“哪个最相关”。

🔎 ES 能做什么？

1. 全文搜索（Full-text Search）
   • 模糊匹配、分词、相关性排序。
   • 例如：电商搜索框里输入“红色运动鞋”，ES 能智能拆分关键词并排序。
2. 结构化检索（Filtering）
   • 精确过滤（比如：价格 < 200，品牌=NIKE）。
   • 和全文搜索结合，用来做复杂的搜索场景。
3. 实时分析（Aggregations）
   • 类似 SQL 里的 GROUP BY、COUNT、AVG。
   • 例如：统计“每个城市今天新增的订单数”。
4. 日志/监控/指标存储
   • 常见场景：ELK/EFK 日志系统（Elasticsearch + Logstash/Fluentd + Kibana）。
   • 把大量日志写入 ES，再通过 Kibana 可视化检索和分析。

异常（Exception） 大体分为三类：

1. 异常分类

1. Checked Exception（受检异常）
   • 编译时必须显式处理（try-catch 或 throws）。
   • 比如：IOException, SQLException, ClassNotFoundException。
   • 特点：通常是外部因素导致，程序本身无法完全避免。
2. Unchecked Exception（非受检异常 / Runtime Exception）
   • 不需要编译期强制捕获。
   • 比如：NullPointerException, ArrayIndexOutOfBoundsException。
   • 特点：大多是由代码逻辑错误引起。
3. Error
   • JVM 无法恢复的严重错误。
   • 比如：OutOfMemoryError, StackOverflowError。

RuntimeException 常见子类

RuntimeException 及其子类常见的有：

• 空指针相关
  • NullPointerException
• 数组/集合越界相关
  • ArrayIndexOutOfBoundsException
  • StringIndexOutOfBoundsException
  • IndexOutOfBoundsException
• 类型转换相关
  • ClassCastException
• 算术相关
  • ArithmeticException（如除零）
• 非法参数相关
  • IllegalArgumentException
  • NumberFormatException（字符串转数字失败）
• 状态相关
  • IllegalStateException
• 迭代器/集合操作
  • ConcurrentModificationException（迭代时修改集合）
  • UnsupportedOperationException（不支持的操作）
• 安全相关
  • SecurityException
• 反射相关
  • IllegalAccessException（注意：这个是 Checked 的，但 InaccessibleObjectException 是 Runtime 的）
• 其他常见的
  • NegativeArraySizeException（数组长度为负）
  • MissingResourceException
  • EnumConstantNotPresentException

自定义业务异常继承哪个类，要取决于你希望它在编译期还是运行期被强制处理：

1. 继承 Exception（Checked Exception，受检异常）

• 特点：调用方必须 try...catch 或 throws。
• 适用场景：
  • 业务逻辑上确实需要调用方显式处理。
  • 比如：订单不存在、库存不足、用户余额不足等。
• 优点：强制调用方注意并处理业务错误。
• 缺点：代码会被大量 try...catch 或 throws 污染。

public class BusinessException extends Exception {
    public BusinessException(String message) {
        super(message);
    }
}

2. 继承 RuntimeException（Unchecked Exception，运行时异常）

• 特点：调用方可以选择性处理，不强制。
• 适用场景：
  • 绝大多数 Web 项目、Spring 项目中的业务异常。
  • 一般通过全局异常处理器（@ControllerAdvice、@ExceptionHandler）来统一捕获并返回错误信息。
• 优点：
  • 代码简洁，不需要每次调用都写 throws。
  • 与 Spring 等框架的异常机制更契合。
• 缺点：
  • 如果开发者忘了处理，异常可能直接抛到最上层。

public class BusinessException extends RuntimeException {
    public BusinessException(String message) {
        super(message);
    }
}

3. 实际推荐做法

在实际业务开发（尤其是 Spring Boot 项目）中，几乎都选择继承 RuntimeException，然后通过全局异常处理来规范输出。

例如：

@ResponseStatus(HttpStatus.BAD_REQUEST)
public class BusinessException extends RuntimeException {
    private final int code;

    public BusinessException(int code, String message) {
        super(message);
        this.code = code;
    }

    public int getCode() {
        return code;
    }
}

常见分布式 ID 方案

1) 数据库自增 / 发号器

• 实现：单表 AUTO_INCREMENT；或建一张【号段表】批量发号（segment）。
• 优点：实现简单，具备递增特性；号段方案吞吐高、可容灾。
• 缺点：单点或中心化依赖；跨机房延迟；切库要小心。
• 适用：强有序、易运维的业务（订单号等）。
• 号段表示例：

CREATE TABLE id_segment (
  biz_key VARCHAR(64) PRIMARY KEY,
  max_id BIGINT NOT NULL,
  step INT NOT NULL,
  version INT NOT NULL
);
-- 应用一次拿 step 个号： (max_id - step + 1) ~ max_id，乐观锁 version 保证并发安全

2) Snowflake（雪花算法）

• 结构（经典 64 位）：[1位符号][41位时间戳][10位机器标识][12位序列]
  • 41 位毫秒时间戳 ≈ 69 年
  • 10 位机器（可分 datacenterId + workerId）
  • 12 位序列：同毫秒内最大 4096 个
• 优点：本地生成、低延迟、趋势有序（按时间）。
• 缺点：时钟回拨需处理；机器位分配、漂移恢复要设计。
• 适用：高并发、低延迟、去中心化场景。
• 关键点：时钟回拨（拒绝、等待、备用序列或切换机器位）、序列溢出阻塞、机器号分配（ZooKeeper/Etcd/配置中心）。

1. Twitter Snowflake（经典雪花算法）

背景：Twitter 最早提出的分布式 ID 算法，用 64 位 long 型 ID 来保证唯一性和趋势有序。

结构（64 位）：

1位符号位 | 41位时间戳 | 10位机器标识 | 12位序列号

• 41位时间戳：毫秒级，可用约 69 年
• 10位机器号：可支持 1024 台节点
• 12位序列号：同一毫秒最多生成 4096 个 ID

优点：

• 本地生成，无需远程依赖，延迟极低
• ID 趋势递增，适合数据库索引

缺点：

• 时钟回拨问题：若系统时间被调整，可能生成重复 ID
• 机器 ID 分配需可靠机制（配置、ZK、Etcd 等）

2. 百度 UidGenerator（雪花算法的改进版）

背景：百度在雪花算法基础上改进，推出了 UidGenerator，优化了位分配和时钟回拨问题。

主要改进点：

1. 位结构可配置化
   • Snowflake 是固定的 41-10-12 分配。
   • 百度改成 可配置的时间位 + 工作节点位 + 序列位，适应不同业务。
   • 例如电商高并发可增大序列位，低并发长周期业务可增大时间位。
2. 时钟回拨处理
   • Snowflake 一旦发生时间回拨，常见做法是阻塞或报错。
   • UidGenerator 支持 环形队列缓存 ID，即便出现时间小范围回拨，也能继续发号。
3. 工程化支持
   • 提供 Spring Boot Starter，易接入
   • 机器号可通过数据库或 ZK 自动分配

优点：灵活、容错能力强、工程化好。 缺点：需要引入额外的缓存/队列，稍复杂。

3. 美团 Leaf

背景：美团点评内部开源的分布式 ID 生成服务，解决大规模分布式系统中的 ID 需求。

两种模式：

1. Leaf-segment（号段模式）
   • 利用数据库中的号段表，每次批量取一段 ID（如 1000 个），缓存在本地发号。
   • 优点：性能高（QPS 可到数十万），DB 压力小（批量更新）。
   • 缺点：依赖 DB，高可用需主从架构；ID 不严格单调（跨服务时可能有跳号）。
2. Leaf-snowflake（雪花模式）
   • 改造版 Snowflake，利用 Zookeeper 分配 workerId，避免冲突。
   • 优点：本地生成，低延迟，无需频繁访问 DB。
   • 缺点：依赖 ZK 的可用性；时钟回拨仍需处理。

工程化特性：

• 提供 HTTP 接口，可作为独立服务
• 高可用：DB 主从、ZK 集群
• 监控告警支持

Snowflake 遇到时钟回拨时，为什么常见的做法是阻塞或直接报错？

这里的根源在于 Snowflake 的 ID 设计强依赖本地系统时间👇

1. Snowflake ID 的组成回顾

[1位符号][41位时间戳][10位机器号][12位序列号]

• 时间戳部分是核心，它保证 不同毫秒生成的 ID 大体有序。
• 如果时间正常递增，ID 也随时间单调上升。

2. 时钟回拨为什么危险

如果系统时钟因为 NTP 校准、人工改动、硬件问题等被拨回：

• 当前时间戳比上一次生成 ID 的时间戳 还要小。
• 那么新的 ID 里 时间部分变小，可能与之前生成的 ID 重复，破坏全局唯一性和趋势递增性。

例如：

• 在 2025-09-06 10:00:00 生成了 ID → 时间戳 = T
• 时钟被回拨到 2025-09-05 23:59:59 → 时间戳 < T
• 此时生成的 ID 可能和之前的毫秒段 重叠，导致冲突。

3. 为什么选择“阻塞或报错”

• 阻塞：等到系统时钟追赶回之前的最大时间戳后再继续发号 → 确保新 ID 时间戳不会小于历史值。
• 报错：直接抛异常让调用方注意到系统时间异常 → 避免产生错误 ID。

这两种做法虽然会影响可用性，但它们保证了 ID 的正确性（唯一性 + 趋势有序性）。

你问的就是「环形队列缓存 ID」到底怎么做。给你一份工程化落地方案（接近百度 UidGenerator 的思路），含原理 + 关键数据结构 + 生成/续桶流程 + 代码骨架。

核心思路（一句话）

不是临时现算一个 ID 再返回，而是按时间片（毫秒/秒）预先批量生成一大把未来可用的 ID，放进一个环形队列（ring buffer）*里；业务线程只需从队列里 take()。当时间*小幅回拨时，队列里还有“未来时间片”生成的 ID 可用，从而不中断发号。

🍱 号段模式（Leaf-segment）

想象一下食堂打饭：

• 食堂阿姨每次从仓库里 搬一大筐鸡腿（比如 1000 个），放到窗口。
• 学生来打饭时，阿姨就从筐里一个一个发。
• 鸡腿快要发完时，阿姨就提前去仓库再搬一筐备用，这样窗口不会断货。

👉 在这里：

• 仓库 = 数据库（存着全局最大的号段值）
• 阿姨手里的筐 = 应用本地缓存的号段
• 学生拿到的鸡腿 = 分配出去的 ID

好处：发号非常快（内存操作），坏处：每次搬一筐会“跳号”，比如 A 窗口发到 1000，B 窗口发的是 2001，中间的 1001~2000 就没用了。

🕰️ 雪花模式（Leaf-snowflake）

再想象一个工厂生产流水号的机器：

• 每个工厂（机房）有很多条流水线（机器）。
• 每个工厂和流水线都有编号（datacenterId + workerId）。
• 每条流水线在同一毫秒里可以打出 0~4095 个序列号。
• 最终的编号就是：时间戳 + 工厂号 + 流水线号 + 序列号。

👉 在这里：

• 时间戳 = 当前时钟
• 工厂号/流水线号 = Zookeeper 分配的 workerId
• 序列号 = 当前毫秒内的计数器

好处：本地自己就能造号，速度极快，不用找“仓库”；坏处：如果时钟倒退（比如手表拨慢了），可能会打出重复的号。

🌟 总结对比

• 号段模式：像“提前批量领货”，靠数据库仓库统一管控；优点是容易管，缺点是有时候会浪费、跳号。
• 雪花模式：像“流水线即时生产”，每台机器自己拼装号码；优点是快，缺点是要小心时钟问题。

1. 号段的本质

• 每个应用实例（比如窗口 A、窗口 B）从数据库里一次性申请一段号：
  • 窗口 A 拿到号段 (1 ~ 1000)
  • 窗口 B 拿到号段 (1001 ~ 2000)
• 这两个号段在数据库里已经被锁定下来，不会再分给别人。

2. 跳号是怎么发生的

• 如果 窗口 A 提前下班/宕机，手里还有 300 个号没发完，那么 (701 ~ 1000) 这段就“浪费”了。
• 下一个用户只能去窗口 B 拿号，从 2001 开始。
• 结果就是：中间的号 没人用了，看起来像“跳过去”了一截。

👉 这就是“跳号”的根源：号段是一次性预分配的，没用完也不能退回去。

1. LIMIT

• 作用：限制返回的行数。
• 场景：只想要前几条结果，比如“最新的 10 条新闻”。

-- 取出前 10 行
SELECT * FROM news ORDER BY created_at DESC LIMIT 10;

👉 这里即使表里有 100 万条新闻，结果只会返回 10 条。

2. OFFSET

• 作用：跳过前面若干行，从指定位置开始返回。
• 常和 LIMIT 搭配：用来做分页。

-- 跳过前 20 行，取接下来的 10 行
SELECT * FROM news ORDER BY created_at DESC LIMIT 10 OFFSET 20;

👉 这表示“第 3 页的数据”（假设每页 10 条）：

• 第 1 页：LIMIT 10 OFFSET 0
• 第 2 页：LIMIT 10 OFFSET 10
• 第 3 页：LIMIT 10 OFFSET 20

3. 两者关系

• LIMIT n：取 n 行。
• LIMIT n OFFSET m：跳过 m 行，再取 n 行。
• 简写：LIMIT m, n 和 LIMIT n OFFSET m 等价。

例如：

SELECT * FROM users LIMIT 5, 10;

等价于：

SELECT * FROM users LIMIT 10 OFFSET 5;

意思是：跳过前 5 行，返回接下来的 10 行。

一、立刻见效的改写

1) 用“键集分页（seek/cursor）”替代大 OFFSET

• 适合时间线/翻下一页等场景；避免跳过成千上万行的扫描。

-- 原：第10001页
SELECT * FROM post ORDER BY id ASC LIMIT 100000, 20;

-- 优：基于上页最后一条记录继续翻
SELECT * FROM post
WHERE id > :last_id
ORDER BY id ASC
LIMIT 20;

多列排序用“组合游标”：

-- (created_at DESC, id DESC)
WHERE (created_at < :last_created_at)
   OR (created_at = :last_created_at AND id < :last_id)
ORDER BY created_at DESC, id DESC
LIMIT 20;

2) 让 ORDER BY 走索引（覆盖最好）

• 给排序键建立（联合）索引，并把唯一键放在最后保证确定性。

CREATE INDEX idx_feed ON post (created_at DESC, id DESC);
SELECT id, title, created_at
FROM post
FORCE INDEX (idx_feed)
ORDER BY created_at DESC, id DESC
LIMIT 20;     -- 尽量只取需要列，减少回表

3) 先取主键再回表（Deferred Join）

• 大宽表分页时显著减 I/O。

-- 子查询只用覆盖索引拿本页主键
WITH ids AS (
  SELECT id
  FROM post FORCE INDEX (idx_feed)
  ORDER BY created_at DESC, id DESC
  LIMIT 20
)
SELECT p.*
FROM post p JOIN ids USING(id)
ORDER BY p.created_at DESC, p.id DESC;

二、深分页与特殊需求

4) 必须“跳页”时

• 用页锚 + seek：预存每 N 页的锚点 id，跳到最近锚点后再 seek 前进几页。
• 或返回 cursor（next_cursor=created_at|id），前端用 cursor 翻页，不再用 offset。

5) 随机取样/推荐，避免 ORDER BY RAND() LIMIT n

-- 简化随机：先随机起点，再顺序取
SELECT * FROM post
WHERE id >= FLOOR(RAND() * (SELECT MAX(id) FROM post))
ORDER BY id
LIMIT 20;

更优：维护一个“抽样池”（Redis/轻量表），先抽 key 再回表。

6) DISTINCT/GROUP BY + 分页

• 先聚合出主键，再回表分页：

WITH g AS (
  SELECT MIN(id) AS id
  FROM events
  WHERE user_id = ?
  GROUP BY session_id
  ORDER BY MIN(created_at) DESC
  LIMIT 20
)
SELECT e.* FROM events e JOIN g USING(id);

三、索引与查询设计原则

• 复合索引顺序：等值列在前，范围/排序列在后，最后加唯一键保证稳定排序。 例：(user_id, status, created_at DESC, id DESC)
• 避免在排序列上使用函数/表达式（导致索引失效），避免数据类型隐式转换。
• 不要 SELECT *，按需列出字段。
• 计总条数不要 SQL_CALC_FOUND_ROWS，单独 COUNT(*)（可异步/缓存）。

1. OFFSET 的原理

原本的分页方式是：

SELECT * FROM post ORDER BY id ASC LIMIT 20 OFFSET 100000;

数据库内部会先扫描 100000 行、丢掉，再取 20 行。 所以页数越深，扫描越多，性能越来越差。

2. 替换为 “游标分页（键集分页）”

我们观察分页本质：

• 第 1 页取 id 最小的 20 条。
• 第 2 页其实就是：取 “大于第 1 页最后一个 id” 的 20 条。

于是写成：

-- last_id = 上一页最后一条记录的 id
SELECT * 
FROM post 
WHERE id > :last_id
ORDER BY id ASC
LIMIT 20;

这样数据库只需要从上次的位置往后扫 20 条，不用丢掉前面的大量记录。

3. 举个例子

假设表里 id 是顺序的：

• 第一页：

SELECT * FROM post ORDER BY id ASC LIMIT 3;

👉 得到 (1,2,3)，last_id = 3

• 第二页：

SELECT * FROM post WHERE id > 3 ORDER BY id ASC LIMIT 3;

👉 得到 (4,5,6)

4. 为什么高效？

因为数据库可以直接用 WHERE id > 3 来“定位”，再顺序取 3 行，避免了 OFFSET 3 这种“前 3 行读了又丢掉”的浪费。

✅ 所以：用 WHERE id > 上一页最后一个 id 替代 OFFSET，就是从“上一页最后一条记录”的位置继续往后读，这就叫 键集分页 / 游标分页。

1. 什么是“排序的确定性”

• SQL 查询里常用 ORDER BY created_at DESC LIMIT 20。
• 如果某一列（比如 created_at）的值有重复，数据库可能返回 任意一条相同值的记录，结果顺序不稳定。
• 当你做分页时就危险了：第 1 页和第 2 页可能出现重复或者漏掉。

2. 为什么要加唯一键

如果我们写成：

ORDER BY created_at DESC, id DESC

• created_at 决定大方向的顺序。
• 当两条记录 created_at 相同时，就用 id（唯一）来打破平局。
• 这样整个结果集的排序就是全局唯一确定的。

👉 这就避免了分页时“相同时间戳的数据前后飘”的问题。

3. 为什么“唯一键放在最后”

在联合索引里，MySQL 按最左前缀原则排序：

• 如果索引是 (created_at, id)，那么查询

  ORDER BY created_at DESC, id DESC
  

  可以完全走索引，结果自然有序，无需 filesort。

• 把唯一键（id）放在最后，保证了：

  1. 前面按主要排序列（created_at）聚集；
  2. 如果前面的值相同，就由唯一键来保证稳定性；
  3. 联合索引同时还能覆盖 created_at 和 id，提高效率。

4. 举个例子

假设表里数据是：

• 仅用 ORDER BY created_at DESC：数据库在 id=1 和 id=2 的顺序上可能前后不一致。
• 用 ORDER BY created_at DESC, id DESC：顺序必然是 (3,2,1)。

这样分页时不会丢记录或重复。

1. 什么叫“回表”

在 MySQL InnoDB 里：

• 聚簇索引（clustered index）：主键索引的叶子节点存放整行数据。
• 二级索引（secondary index）：叶子节点只存放【索引列 + 主键值】，不存放整行。

当你用二级索引做查询时：

1. MySQL 先在 二级索引里找到满足条件的主键 id；
2. 再根据这个主键去 聚簇索引（主键索引） 里取整行。 👉 这个过程就叫 回表（back to table lookup）。

2. 为什么“回表”会慢

• 每次二级索引命中一行，都要再去主键索引里查一次。
• 如果返回行数多，会触发大量随机 I/O。
• 在分页场景里，LIMIT 100000, 20 这种深分页，可能要扫描几十万行做回表，非常耗时。

下面给出一套可落地的“海量数据分布式排序 + 防倾斜”方案（框架无关，MapReduce/Spark/自研 gRPC 都通用）。

一、怎么在分布式里排好序（单机放不下）

总流程（Sample → RangePartition → Shuffle → Local Merge → Concatenate）：

1. 本地外排序（External Sort）
   • 每个节点把数据分块读入内存（≤ 可用内存），块内排序后落盘成有序 run；
   • 用k 路归并把多个 run 合并成更大的有序段（仍可落盘）。
2. 抽样选分界（Splitters）
   • 每个节点随机/均匀抽样 s 个 key（可从已排序 run 里等距抽样更准），汇总到协调者排序；
   • 选出 p-1 个近似分位数作为分界（i/p 分位），广播给所有节点。
3. 按范围分区（Range Partition）+ Shuffle
   • 依据分界把本机有序段切成 p 个子段（区间不重叠），发给对应“归并节点”。
4. 节点侧最终归并（Final Merge）
   • 每个归并节点把收到的多路已排序子段做堆归并，写出一个全局有序分片。
5. 拼接即全局有序
   • 分片 #0, #1, … 顺序拼接（或作为分区化的有序输出）。

关键点：局部 run 有序 + 全局按范围路由，最终每个分片内有序、分片之间按范围递增 ⇒ 全局有序。

读阶段：乐观锁通常不加锁（普通 SELECT，依赖 MVCC/快照读）。

写阶段：不提前占锁；在提交那一刻用“条件更新/版本校验”原子地写入。数据库为保证原子性会短暂拿行锁/闩锁，但这不是你在业务层显式加的“先锁再干活”的悲观锁。

ToC（面向消费者、上亿级并发）做分布式锁，和 ToB（内部系统、相对可控流量）相比，需要额外关注一堆“在大流量+强对抗+多地域”场景才会暴露的问题。下面给你一份工程化清单（带做法与参数建议），直接当评审/上线前的 checklist 用。

0. ToC vs ToB 的根本差异

• 流量模型：ToC 有洪峰/抖动/秒杀、长尾延迟，ToB 更稳定可控。
• 键分布：ToC 极易出现热点 Key（同一库存、同一活动、同一用户），ToB 多为分散操作。
• 对抗性：ToC 有恶意重放/刷子/爬虫/DDoS，ToB 客户端可信。
• 地域：ToC 常多机房/多地域，跨区 RTT 大，时钟偏差与网络分区更常见。 => 这直接影响锁的算法选择、超时策略、容灾、限流和观测。

2) 热点 Key & 惊群（thundering herd）

ToC 秒杀类请求会把同一个 lock:sku123 打爆，导致锁服务先被打死。

缓解手段

• 排队替代忙等：加锁失败不要自旋；有界排队（本地/网关）+ maxWaitMillis 超时直接失败。
• 指数退避 + 抖动：初始 20–50ms，指数增长，添加 20–30% 随机抖动，避免齐步重试。
• 请求合并（coalescing）：同 key 在网关处合并为单个后端尝试，其它等待结果（失败/成功广播）。
• 预分流：在入口层先做业务幂等/资格过滤/配额，减少真正触发锁的请求量。
• 限速 & 配额：按用户/IP/设备/地理维度配额，保护锁后端。

注意：给热点 key 加“盐”分片并不能保持互斥（会破坏语义）。盐值只用于吞吐型操作，互斥必须单 key，因此前置分流与排队更关键。

关键差异 & 额外要点（ToC 必做）

1. 热点键与倾斜

• 问题：同一资源键极热（如同一商品/活动），单分片被打爆。
• 做法：
  • 分片锁（Striped Lock）：lock:sku:123#{hash(reqId)%N} 把一个逻辑锁拆成 N 把；进入临界区前先“当选”一把（如用 ZSET 选最小哈希）。
  • 过度分区：多个物理分片承接同一热点，服务侧做二次仲裁。
  • 把锁转成队列：对热点资源排队（ZSET/Stream），一次只放少量请求过闸。

1. 惊群效应（锁释放瞬间风暴）

• 问题：成千上万请求同时重试，打爆 Redis/下游。
• 做法：指数退避 + 抖动（jitter）、发布订阅通知（锁释放推送），或使用等待队列（先入先出，避免全体轮询）。

1. 租约续期与进程暂停

• 问题：GC/容器 freeze 导致看门狗续期失败，锁过期被他人拿走；旧持有者继续执行→并发写。
• 做法：
  • 所有临界写操作强制携带 Fencing Token（单调递增票据）；下游只接受票据最大的写。
  • 续期失败立刻中止临界区；在每个关键步骤验证仍持有锁 & token 未过期。

1. 一致性模型选择

• ToC 常取 可用性优先：允许失败重试/幂等，而不是追求“强互斥到毫秒级”。
• 做法：幂等化（业务幂等键、去重表/布隆）、补偿/重放、超时回滚；锁只是“减并发”，最终以校验+幂等兜底。

1. TTL 与任务时长不确定

• 问题：请求时长长尾，固定 TTL 不是过短（误释放）就是过长（占用资源）。
• 做法：短 TTL + 心跳续期，续期周期 < TTL/3；自适应 TTL（按历史P95时长给 TTL 基线）。

1. 多机房/跨区域

• 问题：跨区网络分区与时钟漂移放大锁风险；RedLock 跨实例仲裁在强一致诉求下仍存争议。
• 做法：就近加锁（每区独立锁集群 + 资源分区归属），跨区通过消息总线同步结果；确需强一致用 etcd/ZooKeeper 或数据库单点仲裁。

1. 公平性与饿死

• 问题：高并发下“永远抢不过别人”。
• 做法：为热点资源实现FIFO 等待队列（ZSET/Stream + Lua 取号发号），或给不同请求分配权重/优先级。