感受一下『迅雷』的口试强度

本日还是分享一下组织内部成员近来的面经，是来自迅雷的go后端开辟面经，
内容涵盖**Redis、分布式锁（SETNX/RedLock/可重入锁）、高可用（故障转移、脑裂防护）、数据同等性方案（事务消息、耽误双删、幂等筹划）、消息队列可靠性（持久化、副本机制）**等等

---

面经详解

1. 逃逸分析

定义与作用
逃逸分析是Go编译器在编译阶段自动判断变量应分配到栈（函数结束时自动接纳）还是堆（需GC接纳）的优化技能。其核心目的是减少堆内存分配次数，降低GC压力，提升步伐性能。
判断规则
编译器通过以下条件判断变量是否逃逸：

• 指针逃逸：函数返回局部变量的指针（如return &x）
  
• 动态作用域：变量被闭包或外部函数引用
  
• 动态大小：变量容量在编译时无法确定（如make([]int, n)中的n是变量）
  
• 接口类型转换：变量被赋值给interface{}类型（如fmt.Println(x)中的参数）
  

---

2. Channel的底层原理

核心布局：

• hchan：包罗缓冲区（环形队列）、发送/接收队列（sudog链表）、互斥锁等
  
• 缓冲区：有缓冲Channel存储数据，无缓冲Channel直接阻塞等候配对操纵
  

发送流程：

• 加锁，若缓冲区未满则写入；否则参加发送队列并挂起当前Goroutine
  
• 接收端唤醒时，从缓冲区或发送队列取出数据
  

接收流程：

• 优先从缓冲区读取；若为空，参加接收队列并挂起
  
• 发送端唤醒时，直接传递数据或写入缓冲区
  

---

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

SetNX不可重入的缘故原由：

• 基于Redis的单下令操纵，未记录锁持有者信息，无法辨认同一线程多次获取锁
  

可重入锁实现：

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

红锁（RedLock）：

• 原理：向N个独立Redis节点申请锁，半数以上成功则视为获取锁
  
• 上风：避免单点故障，提升可用性
  
• 题目：时钟同步、网络分区大概导致锁失效，需权衡同等性与性能
  

---

4. 高可用的明白

核心指标：

• 可用性公式：可用性 = MTBF / (MTBF + MTTR)（MTBF为平均无故障时间，MTTR为平均修复时间）
  实现手段：
  
• 冗余：主从复制、多副本摆设（如Redis Cluster）
  
• 故障转移：哨兵机制（Sentinel）、自动切换主节点
  
• 负载均衡：通过代理层（如HAProxy）分散请求
  

---

5. Redis集群摆设模式

• 主从复制：一主多从，主节点写，从节点读（数据异步复制）
  
• 哨兵模式：Sentinel监控主节点，自动故障转移（解决高可用题目）
  
• Cluster模式：数据分片（16384哈希槽），多主多从，支持程度扩展
  

---

6. 哈希槽缩容

步骤：

• 迁徙目的节点的槽位到其他节点（使用CLUSTER SETSLOT下令）
  
• 数据迁徙：逐槽迁徙键值，确保迁徙过程中服务可用
  
• 更新集群元数据，移除节点
  注意点：
  
  
  
  • 迁徙期间避免写入热点，需平衡槽分布
    
  • 缩容后需查抄数据倾斜，必要时调整分片策略
    
  
  

---

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原理

流程：

• TCP握手：创建连接（三次握手）
  
• TLS握手：
  
  
  
  • 客户端发送支持的加密套件和随机数
    
  • 服务端返回证书、公钥和随机数
    
  • 客户端验证证书，生成预主密钥并用公钥加密传输
    
  • 双方基于随机数和预主密钥生成会话密钥
    
  
  
• 加密通信：使用对称加密（如AES）传输数据
  

---

12. Etcd

定义：分布式键值存储系统，基于Raft协议保证同等性，用于服务发现、设置管理
核心功能：

• Watch机制：监听键变化，实实际时设置更新
  
• Lease机制：租约自动过期，用于分布式锁和节点健康检测
  应用场景：Kubernetes元数据存储、微服务注册中心
  

---

13. 分布式数据库

常见方案：

• 分库分表：按业务拆分（如用户库、订单库）
  
• NewSQL：TiDB（兼容MySQL协议）、CockroachDB（兼容PostgreSQL）
  
• 云原生：AWS Aurora（盘算存储分离）、Google Spanner（环球强同等性）
  优化要点：
  
• 数据分片：避免热点，合理选择分片键（如哈希或范围）
  
• 多副本同步：使用Raft/Paxos协议保证同等性
  

---

接待关注 ❤

我们搞了一个免费的口试真题共享群，互通有无，一起刷题进步。
没准能让你能刷到自己意向公司的最新口试题呢。
感兴趣的朋侪们可以私信我，备注：口试群。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。