今天还是分享一下组织内部成员最近的面经，是来自迅雷的 go 后端开发面经，

内容涵盖**Redis、分布式锁（SETNX/RedLock/可重入锁）、高可用（故障转移、脑裂防护）、数据一致性方案（事务消息、延迟双删、幂等设计）、消息队列可靠性（持久化、副本机制）**等等

面经详解

1. 逃逸分析

定义与作用

逃逸分析是 Go 编译器在编译阶段自动判断变量应分配到栈（函数结束时自动回收）还是堆（需 GC 回收）的优化技术。其核心目标是减少堆内存分配次数，降低 GC 压力，提升程序性能。

判定规则

编译器通过以下条件判断变量是否逃逸：

• 指针逃逸：函数返回局部变量的指针（如 return &x）

• 动态作用域：变量被闭包或外部函数引用

• 动态大小：变量容量在编译时无法确定（如 make([]int, n)中的 n 是变量）

• 接口类型转换：变量被赋值给 interface{}类型（如 fmt.Println(x)中的参数）

2. Channel 的底层原理

核心结构：

• hchan：包含缓冲区（环形队列）、发送/接收队列（sudog 链表）、互斥锁等

• 缓冲区：有缓冲 Channel 存储数据，无缓冲 Channel 直接阻塞等待配对操作

发送流程：

1. 加锁，若缓冲区未满则写入；否则加入发送队列并挂起当前 Goroutine

2. 接收端唤醒时，从缓冲区或发送队列取出数据

接收流程：

1. 优先从缓冲区读取；若为空，加入接收队列并挂起

2. 发送端唤醒时，直接传递数据或写入缓冲区

3. 分布式锁与红锁（RedLock）

SetNX 不可重入的原因：

• 基于 Redis 的单命令操作，未记录锁持有者信息，无法识别同一线程多次获取锁

可重入锁实现：

• 在 Redis Hash 中存储锁标识（如线程 ID）和重入次数，每次获取时递增计数器

红锁（RedLock）：

• 原理：向 N 个独立 Redis 节点申请锁，半数以上成功则视为获取锁

• 优势：避免单点故障，提升可用性

• 问题：时钟同步、网络分区可能导致锁失效，需权衡一致性与性能

4. 高可用的理解

核心指标：

• 可用性公式：可用性 = MTBF / (MTBF + MTTR)（MTBF 为平均无故障时间，MTTR 为平均修复时间）

• 实现手段：

• 冗余：主从复制、多副本部署（如 Redis Cluster）

• 故障转移：哨兵机制（Sentinel）、自动切换主节点

• 负载均衡：通过代理层（如 HAProxy）分散请求

5. Redis 集群部署模式

1. 主从复制：一主多从，主节点写，从节点读（数据异步复制）

2. 哨兵模式：Sentinel 监控主节点，自动故障转移（解决高可用问题）

3. Cluster 模式：数据分片（16384 哈希槽），多主多从，支持水平扩展

6. 哈希槽缩容

步骤：

1. 迁移目标节点的槽位到其他节点（使用CLUSTER SETSLOT命令）

2. 数据迁移：逐槽迁移键值，确保迁移过程中服务可用

3. 更新集群元数据，移除节点

4. 注意点：

5. 迁移期间避免写入热点，需平衡槽分布

6. 缩容后需检查数据倾斜，必要时调整分片策略

7. 事务隔离级别与 ReadView

隔离级别：

• RC（读已提交）：事务内每次查询生成新 ReadView，能看到其他事务已提交的修改

• RR（可重复读）：事务内首次查询生成 ReadView，后续复用，保证多次读取一致性

• ReadView 差异：

• RC：通过活跃事务 ID 列表判断数据可见性，每次查询重新生成

• RR：使用事务开始时生成的 ReadView，避免不可重复读

8. Buffer Pool

作用：MySQL 的内存缓存池，管理数据页的读写，减少磁盘 IO

核心结构：

• Free List：空闲页链表，用于分配新页

• LRU List：按最近最少使用算法管理热数据页

• Flush List：记录脏页，等待刷盘

9. Redo Log 与 Binlog

关系：

• Redo Log：物理日志，记录数据页修改（崩溃恢复）

• Binlog：逻辑日志，记录 SQL 操作（主从复制、数据归档）

• 提交时机：

• Redo Log：事务提交时刷盘（innodb_flush_log_at_trx_commit=1）

• Binlog：事务提交后刷盘（sync_binlog=1）

10. Kafka 消息顺序性

保证手段：

• 分区内顺序：单分区内消息按写入顺序存储，单消费者线程处理

• 生产者配置：max.in.flight.requests.per.connection=1 禁止消息重试乱序

• ISR 机制：

• In-Sync Replicas：与 Leader 保持同步的副本集合，用于 ACK 确认（acks=all）

• Leader 选举：仅从 ISR 中选择新 Leader，避免数据丢失

• 其他消息队列：

• RabbitMQ：基于队列的严格顺序，但吞吐量较低

• RocketMQ：支持顺序消息，通过 MessageGroup 锁定队列

11. HTTPS 原理

流程：

1. TCP 握手：建立连接（三次握手）

2. TLS 握手：

3. 客户端发送支持的加密套件和随机数

4. 服务端返回证书、公钥和随机数

5. 客户端验证证书，生成预主密钥并用公钥加密传输

6. 双方基于随机数和预主密钥生成会话密钥

7. 加密通信：使用对称加密（如 AES）传输数据

12. Etcd

定义：分布式键值存储系统，基于 Raft 协议保证一致性，用于服务发现、配置管理

核心功能：

• Watch 机制：监听键变化，实现实时配置更新

• Lease 机制：租约自动过期，用于分布式锁和节点健康检测

• 应用场景：Kubernetes 元数据存储、微服务注册中心

13. 分布式数据库

常见方案：

• 分库分表：按业务拆分（如用户库、订单库）

• NewSQL：TiDB（兼容 MySQL 协议）、CockroachDB（兼容 PostgreSQL）

• 云原生：AWS Aurora（计算存储分离）、Google Spanner（全球强一致性）

• 优化要点：

• 数据分片：避免热点，合理选择分片键（如哈希或范围）

• 多副本同步：使用 Raft/Paxos 协议保证一致性

欢迎关注 ❤

我们搞了一个免费的面试真题共享群，互通有无，一起刷题进步。

没准能让你能刷到自己意向公司的最新面试题呢。

感兴趣的朋友们可以加我微信：wangzhongyang1993，备注：infoq 面试群。