好久没有分享最新的面经了,今天分享一下北京某公司Go开发岗的面经,薪资是15K左右,看看难度如何:
为什么要用分布式事务
分布式事务的核心作用是解决跨服务、跨数据源操作的数据一致性问题。在单体应用中,数据库本地事务(如 MySQL 的 InnoDB 事务)可通过 ACID 特性保证单库内操作的一致性,但在分布式系统中,业务操作往往需要跨多个服务(如用户服务、订单服务、支付服务)或多个数据库,此时本地事务无法覆盖所有操作,可能出现 “部分成功、部分失败” 的情况。
什么是事务
事务是一组操作的集合,需满足 “要么全部成功,要么全部失败” 的原子性要求,分为数据库事务和分布式事务两类:
1. 数据库事务
指单库内的事务(如 MySQL、PostgreSQL),核心是满足ACID 特性:
- 原子性(Atomicity):事务中的所有操作要么全执行,要么全不执行(如转账时 “扣 A 的钱” 和 “加 B 的钱” 必须同时成功或同时失败)。
- 一致性(Consistency):事务执行前后,数据从一个合法状态切换到另一个合法状态(如转账前后 A 和 B 的总金额不变)。
- 隔离性(Isolation):多个事务并发执行时,彼此的操作互不干扰(避免脏读、不可重复读、幻读)。
- 持久性(Durability):事务提交后,数据修改会永久保存(即使数据库崩溃,重启后数据仍有效)。
以 MySQL InnoDB 引擎为例,其事务实现细节包括:
- 隔离级别:支持读未提交(Read Uncommitted)、读已提交(Read Committed)、可重复读(Repeatable Read,默认)、串行化(Serializable)。
- 快照读与当前读:
- 快照读(如
select * from t where id=1
):通过 MVCC(多版本并发控制)和 Read View 实现。每行数据包含隐藏列(DB_TRX_ID
:最后修改事务 ID;DB_ROLL_PTR
:回滚指针,指向历史版本),Read View(由 “低水位”“高水位”“活跃事务 ID 列表” 组成)决定可见的版本(读提交时每次查询生成新 Read View,可重复读时首次查询生成 Read View)。 - 当前读(如
update/delete/select ... for update
):会加锁(行锁、表锁),并读取最新数据。
- 快照读(如
- 锁机制:更新操作时会加 “意向锁”(IX/IS),用于快速判断表中是否有行锁(避免逐行检查锁,提高效率);行锁(如 Record Lock)用于锁定单行数据,防止并发修改冲突。
2. 分布式事务
指跨多个服务或多个数据库的事务,核心是保证跨节点操作的最终一致性(无法像本地事务一样严格保证 ACID,而是通过补偿机制实现 “最终一致”)。
常见实现方式包括 TCC(Try-Confirm-Cancel)、SAGA(正向 + 反向补偿)、本地消息表、DTM 框架等。以 DTM 为例,其核心组件包括:
- 事务管理器(TM):负责全局事务的创建、提交、回滚,协调各子事务的执行顺序,解决事务乱序、幂等性(重复提交)、空补偿(未执行 Try 却执行 Cancel)等问题(通过 “子事务屏障表” 记录全局事务 ID、分支事务 ID 及状态实现)。
- 资源管理器(RM):管理各服务的本地资源(如数据库连接),负责执行子事务的 Try/Confirm/Cancel 操作,并向 TM 汇报执行结果。
分布式事务 CAP 特性
CAP 是分布式系统的三大核心特性,由 Eric Brewer 提出,三者不可同时满足:
- 一致性(Consistency):分布式系统中,所有节点在同一时间看到的数据是一致的(如集群中所有节点的用户余额必须相同)。
- 可用性(Availability):分布式系统中,任何节点故障时,剩余节点仍能正常响应请求(如支付系统不能因某台服务器宕机而无法下单)。
- 分区容错性(Partition Tolerance):当网络分区(部分节点与其他节点断开通信)发生时,系统仍能继续运行(分布式系统必须满足此特性,因为网络故障不可避免)。
在分布式事务中,由于必须满足分区容错性(P),因此需在一致性(C)和可用性(A)之间权衡:
- CP 倾向:优先保证一致性,牺牲部分可用性(如 ZooKeeper 集群,leader 宕机后会暂停服务直到新 leader 选举完成,期间不可用但数据一致)。
- AP 倾向:优先保证可用性,接受短暂的不一致(如多数业务的支付系统,允许 “用户余额扣减后,订单状态延迟更新”,但最终会通过补偿机制一致)。
实际业务中,分布式事务通常追求最终一致性(属于 AP 倾向),即允许中间过程数据不一致,但通过补偿操作(如 TCC 的 Cancel、SAGA 的反向流程),最终所有节点数据会达成一致。
协程了解吗
协程(Goroutine,Go 语言中的实现)是轻量级的 “用户态线程”,相比操作系统线程(OS Thread),其优势在于:
- 资源占用极低:初始栈大小仅 2KB(可动态扩容至 GB 级),而线程初始栈通常为 2MB,因此单台机器可创建数十万甚至数百万协程。
- 调度效率高:由 Go runtime 而非操作系统调度,减少用户态与内核态的切换开销。
Go 语言通过GMP 调度模型实现协程的高效调度,核心组件包括:
- G(Goroutine):协程本身,包含栈、程序计数器、状态(如运行中、就绪、阻塞)等信息。
- M(Machine):操作系统线程,负责执行 G(真正的 “执行载体”)。
- P(Processor):处理器,是 G 和 M 的 “桥梁”,包含本地协程队列(Local Queue)、全局队列指针、调度器状态等,用于管理可执行的 G。
调度流程细节:
- 初始化:程序启动时创建初始线程 M0 和初始协程 G0(每个 M 绑定一个 G0,负责调度其他 G)。
- 协程入队:新建的 G 优先放入当前 P 的本地队列(容量默认 256),本地队列满后放入全局队列。
- 调度策略:
- 本地队列调度:M 优先从绑定的 P 的本地队列获取 G 执行。
- 全局队列调度:本地队列为空时,M 会从全局队列批量获取 G(一次取
min(全局队列长度/num(P) + 1, 64)
个)。 - 偷取机制(Work Stealing):若本地队列和全局队列都为空,M 会随机选择其他 P 的本地队列,偷取一半的 G 执行(避免线程空闲,提高资源利用率)。
- Hand off 机制:当 G 因系统调用(如 IO、sleep)阻塞时,M 会主动释放绑定的 P(将 P 放入空闲 P 列表),让其他空闲的 M 绑定该 P 并执行其本地队列的 G;当阻塞的 G 唤醒后,M 会尝试从空闲 P 列表获取 P,若获取成功则继续执行 G,否则将 G 放入全局队列等待调度。
介绍一下 hand off 机制
Hand off 机制是 Go 调度器中用于处理 “协程阻塞” 的协作式调度策略,核心目的是避免处理器(P)闲置,提高系统资源利用率。
触发场景
当协程(G)因以下操作阻塞时,会触发 hand off:
- 系统调用(如
net.Dial
、os.Read
等 IO 操作); - 同步操作(如
time.Sleep
、mutex.Lock
未获取锁时)。
具体流程
-
G 阻塞时:执行 G 的 M 会检测到 G 进入阻塞状态,此时 M 会调用
park
函数将 G 的状态标记为 “阻塞”,并将绑定的 P 从自身解绑,放入全局 “空闲 P 列表”。 -
释放 P 后:M 进入休眠状态(或处理其他任务),而空闲 P 列表中的 P 可被其他空闲的 M 绑定,继续执行 P 本地队列中的 G(避免 P 因 M 阻塞而闲置)。
-
G 唤醒时:阻塞的 G 被唤醒(如 IO 操作完成、锁获取成功),此时 M 会调用
unpark
函数,尝试从空闲 P 列表中获取一个 P:
- 若获取成功,M 绑定该 P,继续执行唤醒的 G;
- 若未获取成功,将 G 放入全局队列,M 进入休眠,等待后续被调度。
与抢占式调度的区别
Hand off 是 “协作式调度”(G 主动让出 P),而 Go 1.14 后引入的 “抢占式调度” 是通过信号中断长时间运行的 G(如循环无阻塞的 G),强制其让出 P,避免单个 G 独占 P 导致其他 G 饿死。两者结合,保证了 Go 协程调度的高效性。
gc 了解吗
Go 的垃圾回收(GC)是自动管理堆内存的机制,核心目标是 “在保证程序正确的前提下,尽可能减少对业务代码的干扰(低延迟)”。其核心实现是三色标记法 + 混合写屏障,特点是 “并发标记、并行清扫”(大部分阶段与业务代码并发执行,仅短暂 STW)。
核心流程
-
初始标记(STW):短暂暂停所有协程(几微秒到毫秒级),标记 “根对象”(全局变量、栈上变量直接引用的对象)为灰色,开启写屏障(防止标记期间对象引用关系被修改导致漏标)。
-
并发标记:恢复协程执行,GC 后台线程从灰色对象出发,遍历其引用的对象:
- 若引用的对象是白色,标记为灰色;
- 遍历完的灰色对象标记为黑色(表示 “已处理”)。
此阶段与业务代码并发执行,写屏障会实时跟踪对象引用变化(如黑色对象引用白色对象时,通过写屏障修正标记)。
-
最终标记(STW):再次短暂暂停协程,处理并发标记期间遗漏的对象(如根对象的新增引用),关闭写屏障。
-
并行清扫:恢复协程执行,多个 GC 线程并行清扫所有白色对象(不可达对象),释放其占用的堆内存。
关键技术:混合写屏障
写屏障的作用是在并发标记阶段,保证对象引用关系变化时,GC 能正确跟踪可达性,避免 “黑色对象引用白色对象” 导致的漏标(漏标会导致白色对象被误判为垃圾回收)。
混合写屏障结合了 “插入写屏障” 和 “删除写屏障” 的优势,规则如下:
- 当创建新对象时,直接标记为黑色(避免新对象被误回收);
- 当修改对象引用(如a.b = c)时:
- 若旧引用
a.b
指向的对象是黑色,将其重新标记为灰色(确保其引用的对象被遍历); - 新引用
c
指向的对象若为白色,标记为黑色(避免被误回收)。
- 若旧引用
性能优化
Go GC 通过不断迭代优化延迟(如 1.5 引入并发标记、1.8 优化 STW 时间、1.19 引入分代回收),目前在多数场景下 STW 时间可控制在 100 微秒以内,对业务影响极小。
函数的栈帧了解吗
函数栈帧是函数调用时在栈上分配的内存区域,用于存储函数的参数、局部变量、返回地址、栈基指针等信息,其生命周期与函数调用一致(函数返回时栈帧被释放)。
栈帧结构(以 x86 架构为例)
从高地址到低地址依次为:
- 返回地址:函数执行完毕后,CPU 需跳转回的调用处地址(如
call func
指令会将下一条指令地址压栈)。 - 栈基指针(BP):指向当前栈帧的底部,用于定位栈帧内的参数和局部变量(函数执行时,BP 的值由上一个栈帧的 SP 决定)。
- 局部变量:函数内定义的变量(如
int a
、string s
),按声明顺序从 BP 向下分配。 - 函数参数:调用方传递的参数,从 BP 向上(高地址)读取(如
func(a, b int)
中,a
在 BP+8,b
在 BP+12,取决于 CPU 位数)。
逃逸分析与堆分配
Go 编译器会通过 “逃逸分析” 判断变量是否需要 “逃逸” 到堆上:
- 若变量仅在函数内使用(无外部引用),则分配在栈帧上(函数返回后自动释放,无需 GC);
- 若变量被外部引用(如返回局部变量的指针、被闭包引用),则会 “逃逸” 到堆上(由 GC 管理生命周期)。
逃逸分析的目的是减少堆分配(堆分配需 GC,栈分配更高效),提升程序性能。
欢迎关注 ❤
我们搞了一个免费的面试真题共享群,互通有无,一起刷题进步。
没准能让你能刷到自己意向公司的最新面试题呢。
感兴趣的朋友们可以私信我,备注:面试群。