八股总结 on GoClub

每日一问

Mon, 01 Jan 0001 00:00:00 +0000

每日一问

记录微信交流群中每天的提问。

2026.08.25#

raft中多数派为什么是n / 2 + 1#

为了保证系统的强一致性，必须确保读操作能读到最新的写操作，这就要求读集合（R）和写集合（W）必须有交集，即满足 |W| + |R| > N（N 为总节点数）。在满足该公式的前提下，系统的设计需要在可用性和可靠性之间做权衡：如果要求全部节点写入成功（W=N, R=1），读取极快，但任何一个节点宕机都会导致系统不可写，可用性极差。

如果只需一个节点写入（W=1, R=N），写入极快，但每次读取必须全量查询所有节点，容错性同样极差。

为了在这两者之间取一个最佳的“中间值”，Raft 和 Paxos 等算法通常将 N 设为奇数，并要求写入和读取都达到多数派（W = R = N/2 + 1）。这样不仅完美满足了 |W| + |R| > N，保证了读写集合的交集，同时也能容忍少数派（(N-1)/2 个）节点的宕机，实现了可用性和可靠性的最优解。

额外练习：以下代码有死锁的风险吗

package main

import (
 "sync"
 "time"
)

// Service 抽象的服务，管理共享数据和事件分发
type Service struct {
 mu sync.Mutex
 data int
 eventCh chan int //带缓冲的channel
}

// PublishEvent 模拟服务端内部逻辑：更新数据并广播事件
func (s *Service) PublishEvent() {
 s.mu.Lock()
 defer s.mu.Unlock()

 s.data++

 s.eventCh <- s.data
}

// RPC_UpdateData 模拟暴露给客户端的同步调用接口
func (s *Service) RPC_UpdateData(val int) {
 s.mu.Lock()
 defer s.mu.Unlock()

 s.data = val
}

/*
// 客户端按照以下方式使用Service
for {
 select {
 case val, ok := <-cmdCh:
 if !ok {
 return
 }
 svc.RPC_UpdateData(val)
 case _, ok := <-svc.eventCh:
 if !ok {
 return
 }
 // 处理服务端推送的事件
 }
 }
*/
}

答案：有，PublishEvent在向channel发送数据时加锁可能会导致死锁

Go

Mon, 01 Jan 0001 00:00:00 +0000

Go

这里整理 Go 面试中高频出现的语言、并发、运行时和工程相关问题，适合作为专题复习提纲。

1. 为什么选 Go 语言#

查看答案

可直接说： 我选择 Go，主要看重它在后端服务里的工程效率、并发能力和部署体验。Go 语法简洁、编译快、标准工具链完善，团队协作时容易形成统一代码风格；goroutine 和 channel 让并发代码更轻量，适合 I/O 密集、高并发服务；编译后的单二进制方便容器化和发布，配合云原生生态做微服务、网关、基础设施工具很顺手。

要答的点：

工程效率：语法小、编译快、gofmt、go test、go mod 等工具链统一。
并发能力：goroutine 初始栈小，由运行时调度，channel 提供类型安全通信。
服务端适配：标准库覆盖 HTTP、JSON、SQL、加密等常用能力，适合网络服务。
部署体验：单二进制交付，容器化和跨平台构建成本低。
取舍意识：Go 适合业务服务、云原生基础设施、CLI 工具和中间件开发。

重点讲解摘录：

Go 官方文档说 Go 是 “expressive, concise, clean, and efficient”，面试时可以把它落到工程效率上：代码风格统一、样板代码少、构建反馈快。
Go 云服务专题提到 Go 的 “built-in support for concurrency”，对应后端场景里的高并发连接、异步任务、RPC 服务和网关转发。
Go FAQ 说 Go 试图 “combine the ease of programming” 与静态编译语言的效率和安全性，这正是 Go 在业务服务里的核心价值。
Effective Go 说明 goroutine “costing little more than the allocation of stack space”，可以用来解释 goroutine 比直接管理线程更轻量。

原文链接：

MySQL

Mon, 01 Jan 0001 00:00:00 +0000

MySQL

这里按基础、索引、事务、锁和日志几个方向整理 MySQL 常见面试题，适合系统梳理数据库知识。

基础#

增删改查的语法#

查看答案

可直接说： 核心是 SELECT/INSERT/UPDATE/DELETE 四类语句，面试更看你是否会结合条件、排序、分页和事务使用。查询用 SELECT ... FROM ... WHERE ... GROUP BY ... HAVING ... ORDER BY ... LIMIT；插入用 INSERT INTO ... VALUES ... 或 INSERT ... SELECT；更新用 UPDATE ... SET ... WHERE ...；删除用 DELETE FROM ... WHERE ...。修改类语句上线前要确认条件、影响行数和事务边界。

要答的点：

SELECT：查询数据，常配合过滤、分组、排序、分页。
INSERT：插入单行、多行，或从查询结果写入。
UPDATE：按条件定位行，再用 SET 修改列。
DELETE：按条件删除行，核心是控制影响范围。
事务：多个修改语句用事务包起来，失败时回滚。
安全：线上修改先 SELECT 验证条件，再执行修改。

重点讲解摘录：

MySQL 官方把 SELECT、INSERT、UPDATE、DELETE 放在 DML 章节。
SELECT 语法覆盖投影、表引用、条件、分组、过滤、排序和分页。
UPDATE 和 DELETE 都强依赖 WHERE 控制影响行范围。
COMMIT 让事务修改永久生效，ROLLBACK 取消当前事务修改。

原文链接：

RabbitMQ

Mon, 01 Jan 0001 00:00:00 +0000

RabbitMQ

这里主要整理消息队列相关的高频面试题，包括 RabbitMQ、自身机制以及和 Kafka、RocketMQ 的对比。

1. RabbitMQ、Kafka、RocketMQ 对比#

查看答案

可直接说： RabbitMQ、Kafka、RocketMQ 都能做异步解耦、削峰填谷和事件传递，侧重点不同。RabbitMQ 基于 AMQP，Exchange 路由模型成熟，Direct、Topic、Fanout 等交换机适合复杂业务路由和任务队列；Kafka 是分布式事件流平台，分区、顺序追加写和消费位点让它适合日志、埋点、实时计算和数据管道；RocketMQ 面向业务消息能力更完整，顺序消息、事务消息、延时消息和消息轨迹适合订单、支付、交易链路。

消息队列	核心优势	适合场景
RabbitMQ	AMQP 成熟，Exchange 路由灵活，确认、死信、延迟等业务能力常用	业务系统解耦、任务队列、后台异步、复杂路由、失败重试
Kafka	分区并行、顺序追加、高吞吐、位点管理清晰、生态偏流式处理	日志采集、埋点上报、实时计算、数据湖同步、事件流平台
RocketMQ	事务消息、顺序消息、延时消息、消息轨迹等业务特性集中	电商订单、金融支付、交易链路、分布式事务最终一致性

要答的点：

RabbitMQ：强调路由灵活、可靠投递和传统业务消息。
Kafka：强调高吞吐、可回放、分区并行和事件流生态。
RocketMQ：强调业务消息特性，尤其事务、顺序、延迟。
顺序性：RabbitMQ 队列内顺序；Kafka 分区内顺序；RocketMQ 可按 MessageQueue 保序。
可靠性：都需要生产确认、持久化/副本、消费确认或位点提交。
选型：复杂路由选 RabbitMQ，大规模日志流选 Kafka，交易消息链路选 RocketMQ。

重点讲解摘录：

RabbitMQ 文档把 Exchange 描述为接收生产者消息并路由到队列的组件。
Kafka 官方把 Kafka 定位为 “distributed event streaming platform”。
Kafka 文档说明 Topic 可分为 partitions，并支持消费者通过 offset 控制消费位置。
RocketMQ 文档把事务消息、顺序消息、延迟消息列为常见消息类型能力。
面试对比要落到业务场景，避免只背吞吐量和名词。

原文链接：

Redis

Mon, 01 Jan 0001 00:00:00 +0000

Redis

这里主要覆盖 Redis 的数据结构、持久化、高可用、热点问题和面试中的常见追问。

基础#

Redis 和 MySQL 区别，为什么 Redis 更快#

查看答案

可直接说： Redis 是内存数据结构存储，常用于缓存、计数、排行榜、会话、消息流等实时场景；MySQL 是关系型数据库，侧重事务、持久化、一致性、复杂查询和关联分析。Redis 快主要来自数据主要在内存中、命令执行路径短、内置结构高效、单线程事件循环减少锁竞争和线程切换。MySQL 也有 Buffer Pool，但还要维护 SQL 优化、事务隔离、锁、redo/binlog、刷盘和崩溃恢复。

要答的点：

定位：Redis 偏缓存和实时数据结构，MySQL 偏关系建模和事务主库。
存储：Redis 主要内存访问，MySQL 通过 Buffer Pool、索引页和磁盘页访问。
性能：Redis 命令短路径、事件循环、数据结构针对场景优化。
MySQL 优势：事务、复杂 SQL、可靠持久化、约束和恢复能力。
选型：热点数据和短期状态用 Redis，核心事实数据用 MySQL。

重点讲解摘录：

Redis 官方把 Redis 定义为 “in-memory data structure store”。
Redis 官方介绍提到亚毫秒级响应和数据结构能力。
Redis latency 文档说明正常简单命令执行时间很短。
MySQL InnoDB Buffer Pool 缓存表和索引数据，提高读性能。
MySQL ACID 文档说明 InnoDB 为可靠业务数据提供事务能力。

原文链接：

Redis 的应用场景#

查看答案

可直接说： Redis 适合访问频率高、实时性强、生命周期相对短、结构清晰的数据。常见场景包括缓存、会话存储、计数器、限流、分布式锁、排行榜、热点统计、延迟任务、Pub/Sub 通知、Stream 消息流和地理位置查询。面试里要强调 Redis 通常作为 MySQL 等主存储的加速层和实时状态层，核心业务事实数据仍要落到可靠持久存储。

常用工具

Mon, 01 Jan 0001 00:00:00 +0000

常用工具

Git#

Git 的工作区、暂存区和本地仓库分别是什么#

查看答案

可直接说： 工作区是你正在编辑的项目文件；暂存区是下一次提交的候选快照；本地仓库是 .git 目录里保存提交历史、分支、标签和对象数据库的地方。典型流程是修改工作区文件，用 git add 把变更放入暂存区，再用 git commit 把暂存区快照写成本地仓库里的一个提交。

要答的点：

工作区：真实文件目录，承载当前编辑内容。
暂存区：index，保存下一次 commit 的内容。
本地仓库：.git 目录，保存对象、引用和历史。
git status：查看工作区和暂存区状态。
git add：把工作区变更加入暂存区。
git commit：把暂存区快照写入本地仓库。

重点讲解摘录：

Pro Git 把 Git 项目分为 working tree、staging area 和 Git directory。
Git 官方文档把 index 描述为暂存下一次提交内容的区域。
git status 会同时显示 staged 和 unstaged changes。
提交对象记录快照、作者、提交者、父提交和提交信息。

原文链接：

`git pull` 和 `git fetch` 的区别#

查看答案

可直接说： git fetch 只从远程拉取最新对象和远程跟踪分支，不改当前工作分支；git pull 等于先 fetch，再把远程分支整合到当前分支，默认通常执行 merge，也可以配置或使用参数执行 rebase。日常协作里想先看远程变化就用 fetch，确定要整合再 merge 或 rebase。

操作系统

Mon, 01 Jan 0001 00:00:00 +0000

操作系统

这里用于整理操作系统面试中的高频基础问题，重点围绕内存、进程线程、调度与文件系统等主题。

内存#

虚拟内存是什么？为什么要有？#

查看答案

可直接说： 虚拟内存是操作系统给每个进程提供的独立逻辑地址空间，进程访问的是虚拟地址，CPU 和操作系统通过页表把它映射到物理内存或磁盘中的后备存储。它的价值是进程隔离、按需加载、简化内存管理、支持更大的地址空间。即使物理内存有限，系统也可以把暂时不用的页面换出，把正在使用的页面换入。

要答的点：

抽象：每个进程看到连续、独立的虚拟地址空间。
映射：虚拟地址通过页表映射到物理页框。
隔离：进程之间默认不能直接访问对方地址空间。
按需调页：访问到尚未装入内存的页时触发缺页处理。
内存利用：降低连续物理内存需求，提升多进程并发运行能力。
成本：页表、TLB miss、缺页换入和换出都会带来额外开销。

重点讲解摘录：

OSTEP 把虚拟化内存描述为每个进程拥有自己的私有地址空间。
Linux 内核文档说明虚拟内存系统管理虚拟地址到物理内存的映射。
Intel 手册把分页描述为线性地址到物理地址的转换机制。
xv6 book 把页表作为地址转换和进程隔离的核心结构。
面试回答要同时讲收益和代价，体现工程取舍。

原文链接：

内存分页的好处和问题#

查看答案

可直接说： 分页把虚拟地址空间和物理内存都切成固定大小的页，虚拟页通过页表映射到物理页框。好处是管理简单、减少外部碎片、支持非连续物理内存分配、支持按需加载和换页；问题是会产生页表内存开销、地址转换开销、TLB miss、内部碎片和缺页 I/O 成本。面试里要把“固定大小带来简单”和“页表/缺页带来成本”一起讲。

要答的点：

固定粒度：常见页大小是 4KB，也支持大页。
减少外部碎片：物理页框固定大小，分配更容易。
支持虚拟内存：虚拟页可以映射到任意物理页框。
支持换页：冷页可以换出到磁盘，热页按需换入。
页表成本：页表本身占内存，多级页表用于降低稀疏地址空间成本。
性能成本：TLB miss 和缺页会显著拉高访问延迟。

重点讲解摘录：

OSTEP 分页章节强调固定大小页让空间管理更灵活。
Linux 内核文档把页表描述为虚拟内存管理的核心数据结构。
Intel 手册说明 TLB 用来缓存线性地址到物理地址转换结果。
缺页会让 CPU 进入内核，由内核完成页面分配、换入或异常处理。
内部碎片来自最后一页未完全使用的空间。

原文链接：

计算机网络

Mon, 01 Jan 0001 00:00:00 +0000

计算机网络

这里整理计算机网络面试里的常见问题，覆盖 DNS、TCP、HTTP、HTTPS 和排障思路等主题。

基础#

输入一个 URL 会发生什么？#

查看答案

可直接说： 浏览器输入 URL 后，先解析 URL 并确定协议、域名、端口和路径；然后通过缓存和 DNS 系统把域名解析成 IP；再建立传输连接，HTTP/1.1 和 HTTP/2 常走 TCP，HTTPS 还要完成 TLS 握手，HTTP/3 走 QUIC；连接建立后浏览器发送 HTTP 请求，服务端返回响应；浏览器解析 HTML，下载 CSS、JS、图片等资源，构建 DOM/CSSOM，完成布局、绘制和合成。连接后续可能复用，也可能按协议和服务端策略关闭。

要答的点：

URL 解析：确定 scheme、host、port、path、query。
DNS：先查浏览器/系统/本地 DNS 缓存，再走递归解析和权威解析。
建连：TCP 三次握手；HTTPS 增加 TLS 握手；HTTP/3 基于 QUIC。
请求响应：发送 HTTP 请求，服务端处理后返回状态码、响应头和响应体。
渲染：解析 HTML/CSS/JS，构建 DOM、CSSOM、渲染树，布局、绘制、合成。
连接管理：Keep-Alive、多路复用、缓存、重定向、Cookie 等都会影响真实链路。

重点讲解摘录：

MDN 的 Web 工作原理文章把过程拆成 DNS 找到服务器地址、浏览器向服务器发送请求、服务器返回页面副本。
MDN 浏览器渲染文档提到，浏览器得到资源后会解析 HTML、CSS、JavaScript，再进行布局和绘制。
RFC 9293 把 TCP 建连称为 “three-way handshake”，这是 HTTP over TCP 的基础。
RFC 8446 说明 TLS 的目标是为通信应用提供安全通道，HTTPS 的安全性来自这一层。
RFC 9114 说明 HTTP/3 使用 QUIC 传输，适合回答 HTTP/3 和前两代的建连差异。

原文链接：

八股总结 on GoClub

每日一问

2026.08.25#

raft中多数派为什么是n / 2 + 1#

Go

1. 为什么选 Go 语言#

MySQL

基础#

增删改查的语法#

RabbitMQ

1. RabbitMQ、Kafka、RocketMQ 对比#

Redis

基础#

Redis 和 MySQL 区别，为什么 Redis 更快#

Redis 的应用场景#

常用工具

Git#

Git 的工作区、暂存区和本地仓库分别是什么#

git pull 和 git fetch 的区别#

操作系统

内存#

虚拟内存是什么？为什么要有？#

内存分页的好处和问题#

计算机网络

基础#

输入一个 URL 会发生什么？#

`git pull` 和 `git fetch` 的区别#