面经 on GzzhM

[深信服] 面经每日一看

Thu, 30 Jul 2026 00:00:00 +0000

本篇面经来自 : https://www.nowcoder.com/feed/main/detail/e28ee3b477754207a97a79516d7e7101?sourceSSR=search

牛客上面最新的 golang 社招没有了，不确定是不是没有岗位面试还是工作了之后大家都不爱写面经导致的

随便找一个实习或者是校招的看看

开场基础

自我介绍 ( 我是xxx, 毕业 xxx, 曾经工作于 xxx 负责 xxx, 拥有 xxx 经验 )
当初为什么会选择做这两个核心项目？ (我这边预计一个是公司项目，一个手写的项目，一个AI项目)
- 对于 AI 项目，AI发展是趋势，而且在公司的时候参加过黑客松，之前开过一个头，后面有空了之后就打算把他完善一下
- 由于在之前的公司少了一部分微服务,高并发相关的业务需求,所以单独写一个项目用于完善该部分的经验

项目1

项目中用到了分片上传、断点续传，具体如何保证最终上传的文件是完整正确的？
如何保证所有分片拼接后绝对正确，不只是简单判断无缺片？

这两个不会，预计后续补充该部分知识点。不过可以根据题目思路发散一些

保证文件完整正确, 先保证分片存在
如果分片存在 , 可以考虑根据后端存放的 metaData即后端存放每次分片发送过来的数据。然后每个分片单独比较该分片的数据。

AI 编程能力认知

日常 Go 开发中，是依赖 AI 编程更多，还是自己手写代码更多？

基本上使用 AI, AI 占比率 99% 。工作的时候主要使用 codex 和 cursor 这种具有高安全性并且性能够用的 Agent. 有时候会考虑使用 GLM 进行跑涉及多模块的需求。

平时使用 AI 编程，用过哪些实用的 Skill/能力？

写了一个 skills用于排查对账问题,我们服务客户60%的时间都是要解决客户的对账问题，排查是否缺少数据，是否有数据没有参与对账。通过写了一个 skill 把之前人为排查的顺序告诉 AI 让他来进行排查。最终效率提升了 50%
将内部接口暴露出来供外部使用，组内封装过过个MCP接口, 通过使用各个环境的 Apikey 进行访问每个环境的数据。

你用过的这些 AI 编程 Skill，存在哪些不好用、有局限的地方

局限的地方 : 对于较为明显的问题，实际上人一眼就能看出来,但是跑AI的话预计要等5-10分钟。不好用: 因为部分接口还没有封装暴露成为MCP,导致现有 skills需要的数据需要人手动传入

项目1

项目使用 Kafka 做任务调度，重试机制、失败恢复的具体实现方案是什么

这两个也没有接触过,不过可以根据感觉来回答

在点赞服务，使用 kafka 进行异步统计。如果在任务调度中失败了,我们会尝试 3次重试，如果重试也失败之后,会把该数据放到死信队列中, 死信队列的数据单独启动一个定时任务来进行处理这部分数据。如果多次失败，会有对应的告警和日志，并且可以在监控中观测到，这时候就需要人为到定位，是不是第三方服务不稳定或者是传入了错误的请求导致的。
当然我们也可以考虑业务折中的方案，我们对于点赞服务，只需要确保用户能够正常的维护是否点赞这个功能，而对于点赞数在业务上允许他可以不稳定更新

重试、退避策略、失败恢复，是否依赖 MySQL 状态表 + 定时扫表实现调度？具体流程是什么。如上

项目 2

详细介绍项目中的长会话上下文管理方案。
你项目中做过受限子任务编排，具体展开讲讲实现思路与作用。

这两个完全是知识盲区了

六、场景题

设计异步任务创建接口，如何保证接口幂等，避免重复创建任务？

根据业务字段进行重复性校验。例如一个异步任务需要时间范围,操作对象 . 那么就查看是否已经有 <操作对象,时间范围> 的组合存在,如果存在则不创建
使用进程级的限流, 防止前端一秒内多次点击从而频繁发送相同的请求

生产环境接口原本响应几十毫秒，突然耗时飙升至数秒：如何快速排查问题？如何紧急止损？

一般这种异常都会有对应的告警同时会有完整的tracing. 如果没有的话可以考虑通过监控图观察异常情况的发生时间,然后去对应时间点查询日志。并且根据对应接口最近改动进行比较
如果接口特别影响使用, 那么可以考虑使用本地缓存 cover一下实际请求实现降频 . 或者是回退最近改动的代码。如果在可以接受范围内的话，可以考虑定位出来之后再解决

若问题在版本更新后出现，优先从哪些方向排查根因？

最近代码的改动，大概率是
如果涉及第三方服务，可以排查第三方服务是否稳定

哪些具体代码改动，会直接导致接口耗时从几十毫秒飙升至数秒？

数据库层面, 开发环境和线上环境数据不一致，可能新增了某些大量查询或者是更新的操作，但是后端没有做限制和处理
缓存层面, 可能引入了某些大型配置文件,但是这些配置文件的 json.unmarshal没有使用缓存进行控制或者说未命中缓存导致频繁 unmarshal
网络层面, 代理或者是某些三方接口网络不稳定。导致等待http请求，并且http timeout设置的很大，导致等待了很长
硬件层面, 其他进程的占用飙升导致我们服务只能拥有少部分资源导致速度变慢

项目主要使用 MySQL 吗？有没有实际做过慢查询优化、SQL 调优相关工作？

用的 pgSQL .有过慢查询优化的经历

最主要常见的就是，业务需要支持账户+时间的查询。但是历史表结构并没有 <account + timestamp>的索引。主要优化就是在其上面创建索引
其他优化方向也大同小异。主要是根据业务方向进行调整，使用 ESR 原则进行优化

综合评分：58 / 100

按 2 年 Golang 社招标准看：方向对、有真实业务痕迹，但项目深度、技术闭环和面试表达都偏弱，目前更接近「能聊几句」而不是「能扛住追问」。

分项打分

维度	分数	简评
项目深度与闭环	45	分片上传、Kafka、AI 长会话多处空白，硬伤
场景题 / 排查能力	68	有思路，但缺具体手段和分层排查
AI 工程实践	75	Skill/MCP 有真实落地，是亮点
数据库 / SQL	70	有索引优化经历，但深度不够
表达与面试策略	55	「不会」「根据感觉答」会直接扣印象分
岗位匹配（深信服向）	60	偏业务+AI，缺系统/网络/高并发细节

优点

AI 工程有真实产出：对账 Skill、MCP 暴露内部接口、效率提升 50%，比空谈「会用 Cursor」强很多，2 年经验里这是差异化点。
知道业务折中：点赞数允许最终一致，说明有业务取舍意识，不只堆组件。
慢查优化有落点：account + timestamp 索引、提到 ESR，说明碰过真实 PG/MySQL 问题。
耗时飙升题有分层意识：库 / 缓存 / 网络 / 机器都想到了，方向基本正确。

缺点

项目答不上核心题
分片完整性、长会话、子任务编排直接写「不会 / 盲区」。面试官会默认：项目是挂上去的，不是你做的。
技术答案停在「感觉层」
- 分片：只说到 metaData 比对，没提分片 hash、整文件 MD5、ETag、合并校验。
- Kafka：重试/死信方向对，但缺幂等、offset、重试是否可重入、和「定时扫表」方案的对比。
- 幂等：业务唯一键有思路，但「进程级限流」解决不了分布式重复创建，应用层锁 / Redis SETNX / DB 唯一索引没讲。
AI 占比 99% 很危险
面试官会追：没有 AI 时你怎么 debug？怎么读 pprof？怎么自己写并发？建议改成「生成 + 审查 + 自测」比例，强调你负责设计和验收。
排查题缺「可操作清单」
耗时飙升应落到：QPS、P99、DB 慢查、连接池、GC、锁等待、下游 RT、最近发布；止损应有限流、降级、回滚、熔断，而不是只说「本地缓存 cover」。
准备姿态偏被动
多处「这两个不会，后续补充」「根据感觉来回答」——面试现场不能这样说，要说「这块我负责的是 X，完整方案是 Y，边界是 Z」。

建议（按优先级）

1. 先补项目闭环（最高优先级）

每个项目至少能讲清：背景 → 你的职责 → 关键路径 → 数据一致性 → 失败怎么处理 → 指标。

分片上传建议补齐并能口述：

上传前：文件 hash / uploadId
分片：chunkIndex + chunkHash，落盘后校验
续传：查已上传分片列表
合并：校验分片齐全 + 按序合并 + 整文件 hash
可选：秒传（文件 hash 已存在则跳过）

Kafka / 异步任务建议补齐：

至少一种可靠方案：本地消息表 / Outbox，或 Kafka + 幂等消费
重试：有限次 + 指数退避 + 死信 + 告警
明确：为什么不用「只扫 MySQL 状态表」，或两者如何配合

AI 项目（长会话 / 子任务）若写在简历上：

上下文：滑动窗口 / 摘要 / 向量检索，各自取舍
子任务：状态机或 DAG，超时、取消、部分失败怎么处理

写了却讲不清，比不写更伤。

2. 场景题改成「标准答题模板」

幂等：客户端 requestId + Redis/DB 去重表 + 业务唯一键；限流只防刷，不是幂等。
耗时飙升：监控定位时段 → 看发布/依赖 → 拆 RT（本机/DB/下游）→ 止损（回滚/限流/降级）→ 再查根因。
版本后出问题：优先 diff 发布内容、配置、SQL、缓存 key、依赖版本。

3. 调整 AI 叙事

建议口径：

AI 提效写样板和排查脚本；核心协议、一致性、并发、线上问题由我设计并验证；Skill 是把可重复排查流程固化，不是替代判断。

准备 1～2 个「没有 AI 也搞定」的案例（慢 SQL、死锁、goroutine 泄漏等）。

4. 把「不会」改成「边界诚实」

可以说：「合并校验是同事做的，我负责分片落盘和续传列表；完整方案我了解是 hash 校验这条链路。」
不要说「根据感觉答」。

5. 针对深信服多补一块

这类公司常挖：网络、并发、资源占用、稳定性。建议再准备：

goroutine / channel / context 取消
连接池、超时、熔断
pprof 怎么用
一次真实线上/准线上问题的复盘（现象→排查→根因→防再发）

结论

评价	说明
当前水平	业务感 + AI 落地尚可，系统与项目深度不够
面试风险	项目关键题答空时，很容易被判定「包装项目」
提分空间	把 3 个项目各自补成 10 分钟可讲、5 分钟可追问的闭环，分数有望到 75+

如果你愿意，我可以按这份面经，直接帮你改一版「可上场口述」的标准答案（分片上传 + Kafka 重试 + 幂等 + 耗时排查）。

大文件上传

Thu, 30 Jul 2026 00:00:00 +0000

需求分析

对于一个大文件 >= 50mb 的上传, 走单个文件上传的接口很容易超时

单个请求时长过长，容易出发网关/前端axios 超时
中间失败就要整个文件重传
也可能遇见中间件请求大小限制

业务流程

前端拆分文件
通过 /post-init . 初始化本次文件的基本信息

{
file_name  // 文件名
file_size // 文件大小
totalChunks // 总分片数
// .. 
}

/post-init 为每个分片创建临时目录, 然后将本次的 uploadItem 存放到进程级 map中并且返回upload-id
前端分片带上 upload-id 和 chunk_index 以及本次的数据到 post-chunk 接口
所有数据上传完之后前端调用 post-merge接口进行数据到合并，通过 upload-id 遍历每一个分区

一些问题

数据上传信息记录由进程级 map 进行记录，重启之后会丢失 , 并且不支持跨实例续传
- 业务上是允许的，因为客户环境只有每次升级才会进行重启，升级前后的上传操作从业务上看确实需要客户重新操作一次
- 项目是分环境分数据库部署的，没有多实例要求

优化点

业务没有断点续传。如果失败的话需要整体重传
- 如果上传失败了，我们需要重新传整改文件
- 旧的文件也不会主动清理掉，磁盘上会一直留着，直到运维来清理他
并不能保证拼接后绝对正确。

面经每日一看

Wed, 22 Jul 2026 00:00:00 +0000

本篇面经来自 : https://www.nowcoder.com/feed/main/detail/ac0efc95550947c0a55693799dbfa380?sourceSSR=search

个人背景与项目挖掘

Q : 简单介绍一下目前在职的情况，以及寻找新机会（离职）的原因是什么？

Q : 介绍一下你在做的项目，核心思想和解决的痛点是什么？

两个很普通的问题 : 总结

问题 2 : 预计到时候要准备一篇 500 字的演讲稿方便背诵。已添加到 Memo 中 ddl 预计下个月

Go 语言基础

常识题

Q : 项目里用到了 Gin 框架，请问 Gin 第一层的参数绑定（Parameter Binding）底层是怎么实现的？

Gin 支持 Bind 和 ShouldBind 两种调用

func (c *Context) ShouldBind(obj any) error {
	b := binding.Default(c.Request.Method, c.ContentType())
	return c.ShouldBindWith(obj, b)
}

func (c *Context) Bind(obj any) error {
	b := binding.Default(c.Request.Method, c.ContentType())
	return c.MustBindWith(obj, b)
}

其中通过 Method 来分发对应的实现

func Default(method, contentType string) Binding {
	if method == http.MethodGet {
		return Form
	}
	switch contentType {
// ... 
		return BSON
	default: // case MIMEPOSTForm:
		return Form
	}
}

shouldbind 不额外封装 http-code，但是bind额外封装。

func (c *Context) ShouldBindWith(obj any, b binding.Binding) error {
	return b.Bind(c.Request, obj)
}

func (c *Context) MustBindWith(obj any, b binding.Binding) error {
	err := c.ShouldBindWith(obj, b)
	if err != nil {
		var maxBytesErr *http.MaxBytesError
// ... 
		switch {
		case errors.As(err, &maxBytesErr):
			c.AbortWithError(http.StatusRequestEntityTooLarge, err).SetType(ErrorTypeBind) //nolint: errcheck
		default:
			c.AbortWithError(http.StatusBadRequest, err).SetType(ErrorTypeBind) //nolint: errcheck
		}
		return err
	}
	return nil
}

具体更核心的实现，预计就是读取 http 的请求根据各种字段进行处理。预计只要回答到这一步即可

todo : 整理这部分内容单独到 Gin 中

Q : Go 语言中的 Channel 有什么特点？在使用它的时候需要注意什么？

吐槽一下 : 说实话实际工作中用到 channel 的地方真的很少

目前的印象来说 :

channel 的发送操作和接收操作会相互阻塞直到双方准备完毕

使用它有什么需要注意的：记得 close

todo : 这个后续预计会在系统整理高并发那一块处理，或者是在补充《协程池》这篇文章后进行针对学习

Q : 如果一个 Channel 已经关闭了，再往里面写数据会发生什么情况？

WrongAnser : 从上面的回答来看，如果接收方的channel关闭，但是发送方的没关闭，预计是会一直阻塞，然后程序运行后会出错 all sleep goroutine, deal lock 印象中是这样

True : panic: send on closed channel

todo : 会一并同上面的问题一起处理

代码输出题

1
2
3

有一个切片 s := make([]int, 3)，
然后往里追加数据 s = append(s, 1, 2, 3)，
最终 fmt.Println(s) 打印输出的结果是什么？

这个问题是默认补0吧，println不是sprintf(%v)感觉会输出地址？不过预计答案是 0,0,0,1,2,3

纠正 : fmt.Println 对 slice 用的就是类似 %v 的默认格式，打印的是元素内容：[0 0 0 1 2 3]

Redis

Q : Redis 的分布式锁怎么实现的 ?

不知道，印象中是 setNx 但是没实际实现过

todo : 补在memo中

Q : 如果现在想做一个排行榜功能，应该用 Redis 的哪种数据结构？

Zset, 不过如果要处理 100w 的排行的话需要在业务上额外处理一下，例如定时排序+Zset 不过这个作业目前还没完成只是知道一个概念

todo : 补在memo中

Q : Redis 的字符串类型中，有没有哪个指令能够对已存储的数字进行累加？

没看懂这个什么问题，字符串类型的累加？ IncrBy() 吗，需要注意的是如果没有key和有key的情况。这个在查询和缓存计数的时候有考，预计在下周总结出来

Q : 了解 Redis 的缓存雪崩、缓存穿透和缓存击穿吗？分别是什么以及怎么解决？

吐槽 : 梦会实习面经

缓存雪崩指的是 : 大量数据没有命中缓存导致都打到数据库上

缓存穿透 : 指的是数据在缓存和数据库中都不存在

缓存击穿 : 热点 key 正好过期，此时又有大量数据引入

解决办法忘记的差不多了，不过从现在的业务理解上面看

给数据库进行限流降级，保住一部分用户的使用。另外使用其他可用的Redis
都不存在，那就用布隆过滤器过滤一下，本质上就是给不存在的key增加一个缓存
和方法2差不多，也是缓存一下这个过期的大V key

Kafka

Q : Kafka 是怎么保证消息消费的有序性的？

没用过 Kafka 不知道

todo : 推进 kakfa 的学习

SQL

1
2

假设有一个部门表 department，包含以下四列：ID（主键）、UID、age（年龄）、dept_id（部门 ID）。
需求：查询平均年龄在 20 岁以上的部门 ID。

吐槽 : 没想到 26年的面试也是这么存粹，还有手撕sql的环节

这里简单手撕一下，估计牛客上面有原题输入输出什么的预计，这周末去刷一下

1
2
3

select dept_id from ( 
    select dept_id,avg(age) as avg  from department where avg > 20 group by dept_id
)

猜测是这样

手撕代码

`1`	`golang语言用协程交替打印1-100`

这个炫技做法就是参考我这里的实现吧协程池，用协程池开2个goroutine 输出就行了？不过输出的时候全局变量要上锁

感觉不用搞这么麻烦，直接手动开启两个 gouroutine ，然后用 atomic并发安全的基本类也行？

不过怎么实现交替，用管道通信？一个携程输出完然后传给另外一个直到 100 然后close ?

写了一下没写出来，看着是写入方和接收方不能够同时操作 …

todo: 实现 1-100交替输出

type printer struct {
	numerChan  chan atomic.Int64
	changeFlag atomic.Bool
}

func main() {
	wg := sync.WaitGroup{}
	wg.Add(3)

	p := printer{
		numerChan:  make(chan atomic.Int64),
		changeFlag: atomic.Bool{},
	}

	printNum := atomic.Int64{}
	go func() {
		p.numerChan <- printNum
	}()

	trueGoroutine := func(x atomic.Int64) {
		fmt.Println(x)
	}
	falseGoroutine := func(x atomic.Int64) {
		fmt.Println(x)
	}
	select {
	case printNum = <-p.numerChan:
		if printNum.Load() == 100 {
			defer close(p.numerChan)
			wg.Done()
			wg.Done()
			wg.Done()
		} else if p.changeFlag.Load() {
			go trueGoroutine(printNum)
			printNum.Add(1)
			p.numerChan <- printNum
		} else {
			go falseGoroutine(printNum)
			printNum.Add(1)
			p.numerChan <- printNum
		}
	}
	wg.Wait()
}

AI Summary

总评

答对：4 / 11（另有 2 道半对） 评分：48 / 100

按技术题计（不含自我介绍/项目介绍）。能答对的多是「知道用什么」，卡在「怎么做对 / 边界 / 落地」。

逐题核对

#	题目	判定	说明
1	Gin 参数绑定	✅	Bind/ShouldBind、按 Method/ContentType 分发，方向对，面试够用
2	Channel 特点与注意	⚠️	「互相阻塞」只覆盖无缓冲；「记得 close」不准确
3	往已关闭 channel 写	❌	你自己标了 Wrong；正确是 `panic: send on closed channel`
4	`make([]int,3)` + append	✅	`[0 0 0 1 2 3]` 正确
5	Redis 分布式锁	❌	只想到 setNx，缺过期、value、续期、释放校验
6	排行榜用啥	✅	ZSet 正确
7	字符串累加	✅	INCR/INCRBY 正确
8	雪崩/穿透/击穿	⚠️	定义大致对，方案混、不完整
9	Kafka 有序性	❌	空白
10	SQL 平均年龄	❌	应用 `HAVING`，不能 `WHERE avg > 20`
11	协程交替打印	❌	没写出；现有代码结构也不对

优点

会追源码：Gin 那题不是背概念，而是顺着 ShouldBind → Default → MustBindWith，面试里加分。
知道错在哪：closed channel、slice 打印都能自纠，学习闭环在。
选型直觉还行：排行榜 ZSet、计数 INCR，方向不偏。
有复盘习惯：todo / memo 落点清楚，比「看完就过」强。

缺点

基础边界不熟：channel close、SQL HAVING、手撕交替打印 —— 都是高频送分题。
中间件偏「听过没用过」：Redis 锁、Kafka 几乎空。
缓存三兄弟：定义能背一半，方案和场景对不上（击穿该用互斥/singleflight，不是「再缓存一下」）。
手撕偏复杂：交替打印绕 atomic + channel of atomic，反而写挂；面试要最小正确实现。

建议（按优先级）

本周先补这 4 个，能直接拉到 ~65：

SQL

SELECT dept_id FROM department GROUP BY dept_id HAVING AVG(age) > 20
Channel

无缓冲/有缓冲、close 后读零值、写 panic、nil channel 永久阻塞、谁负责 close
交替打印（双 channel 或一个 channel + 两个 goroutine 即可）

func main() {
	ch1, ch2 := make(chan struct{}), make(chan struct{})
	var wg sync.WaitGroup
	wg.Add(2)
	go func() {
		defer wg.Done()
		for i := 1; i <= 100; i += 2 {
			<-ch1
			fmt.Println("A:", i)
			ch2 <- struct{}{}
		}
	}()
	go func() {
		defer wg.Done()
		for i := 2; i <= 100; i += 2 {
			<-ch2
			fmt.Println("B:", i)
			if i < 100 {
				ch1 <- struct{}{}
			}
		}
	}()
	ch1 <- struct{}{}
	wg.Wait()
}

Redis 锁一句话版

SET key uuid NX EX 30 → 业务 → Lua 校验 uuid 再 DEL；进阶再提 Redlock / 看门狗续期。

下周： Kafka「单分区有序 + 同 key 进同分区」；缓存三兄弟各配 1 个标准方案（随机 TTL / 布隆或空值 / mutex）。

面试表达： Gin、ZSet 这类题用「结论 → 一句原理 → 一句坑」三段式，比贴大段源码更稳。

一句话： 选型感和复盘习惯不错，但基础题失分多；先把 SQL / Channel / 手撕 / Redis 锁补实，分数会比补 Kafka 涨得更快。

面经每日一看

Thu, 09 Jul 2026 00:00:00 +0000

学累了我就看面经，看多了就会发现都是一些什么神人在卷，然后就不想学了

本篇面筋来自 : https://www.nowcoder.com/discuss/631514581503926272?sourceSSR=users

店匠科技一面

算法题

两数之和

暴力做法 N^2 匹配
优化做法通过 Map 进行标记

func twoSum(nums []int, target int) []int {
    hashTable := map[int]int{}
    for i, x := range nums {
        if p, ok := hashTable[target-x]; ok {
            return []int{p, i}
        }
        hashTable[x] = i
    }
    return nil
}

聊项目

系统数据模型怎么设计的

说实话我自己做的项目都数据库表可以说是抄的，我们系统的呢

对于一张数据表 historytrade_trans 我们拥有

对于一张 Tradeacc 表我们拥有

Trans表中，我们把会演进的内容放到了 detail 中，好处是如果增加或者是删除字段不需要频繁更改列

通用设计表的步骤 :

区分实体 :

主数据 :

特征 : 数据少,变，被引用
例如 : 账户表
默认倾向 : 宽表 + 局部 Json

事件 :

特征 : 多,追加写,按时间查
例如 : 成交表
默认倾向 : 窄表 + payload

关系 :

特征 : 关联 A-B
例如 : 关系表
默认倾向 : 极简列 + 联合唯一

监控关注的业务指标

我们只关注 IP 层级的限速
入库率

八股

Session 是什么

不清楚
前端有session，可以直接拿到apifox用

一致性

不清楚

分布式事务

不清楚

店匠科技二面

算法题

一个文件里有40亿个数字，找出最大的10个数字

写不下去了有点累

面经 on GzzhM

[深信服] 面经每日一看

开场基础

项目1

AI 编程能力认知

项目1

项目 2

六、场景题

分项打分

优点

缺点

建议（按优先级）

1. 先补项目闭环（最高优先级）

2. 场景题改成「标准答题模板」

3. 调整 AI 叙事

4. 把「不会」改成「边界诚实」

5. 针对深信服多补一块

结论

大文件上传

需求分析

业务流程

一些问题

优化点

面经每日一看

个人背景与项目挖掘

Go 语言基础

常识题

代码输出题

Redis

Kafka

SQL

手撕代码

AI Summary

总评

逐题核对

优点

缺点

建议（按优先级）

面经每日一看

店匠科技 一面

算法题

聊项目

系统数据模型怎么设计的

监控关注的业务指标

八股

Session 是什么

一致性

分布式事务

店匠科技 二面

算法题

店匠科技一面

店匠科技二面