15K的Go开发岗,坐标北京

好久没有分享最新的面经了,今天分享一下北京某公司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。

调度流程细节:

  1. 初始化:程序启动时创建初始线程 M0 和初始协程 G0(每个 M 绑定一个 G0,负责调度其他 G)。
  2. 协程入队:新建的 G 优先放入当前 P 的本地队列(容量默认 256),本地队列满后放入全局队列。
  3. 调度策略:
    • 本地队列调度: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.Dialos.Read等 IO 操作);
  • 同步操作(如time.Sleepmutex.Lock未获取锁时)。
具体流程
  1. G 阻塞时:执行 G 的 M 会检测到 G 进入阻塞状态,此时 M 会调用park函数将 G 的状态标记为 “阻塞”,并将绑定的 P 从自身解绑,放入全局 “空闲 P 列表”。

  2. 释放 P 后:M 进入休眠状态(或处理其他任务),而空闲 P 列表中的 P 可被其他空闲的 M 绑定,继续执行 P 本地队列中的 G(避免 P 因 M 阻塞而闲置)。

  3. 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)。

核心流程
  1. 初始标记(STW):短暂暂停所有协程(几微秒到毫秒级),标记 “根对象”(全局变量、栈上变量直接引用的对象)为灰色,开启写屏障(防止标记期间对象引用关系被修改导致漏标)。

  2. 并发标记:恢复协程执行,GC 后台线程从灰色对象出发,遍历其引用的对象:

    • 若引用的对象是白色,标记为灰色;
    • 遍历完的灰色对象标记为黑色(表示 “已处理”)。
      此阶段与业务代码并发执行,写屏障会实时跟踪对象引用变化(如黑色对象引用白色对象时,通过写屏障修正标记)。
  3. 最终标记(STW):再次短暂暂停协程,处理并发标记期间遗漏的对象(如根对象的新增引用),关闭写屏障。

  4. 并行清扫:恢复协程执行,多个 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 astring s),按声明顺序从 BP 向下分配。
  • 函数参数:调用方传递的参数,从 BP 向上(高地址)读取(如func(a, b int)中,a在 BP+8,b在 BP+12,取决于 CPU 位数)。
逃逸分析与堆分配

Go 编译器会通过 “逃逸分析” 判断变量是否需要 “逃逸” 到堆上:

  • 若变量仅在函数内使用(无外部引用),则分配在栈帧上(函数返回后自动释放,无需 GC);
  • 若变量被外部引用(如返回局部变量的指针、被闭包引用),则会 “逃逸” 到堆上(由 GC 管理生命周期)。

逃逸分析的目的是减少堆分配(堆分配需 GC,栈分配更高效),提升程序性能。

欢迎关注 ❤

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

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

感兴趣的朋友们可以私信我,备注:面试群。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值