Webook-One on GzzhM

关注 one

Sat, 08 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现了一个完整的用户关系功能支持关注、取消关注、获取关注列表

流程设计

需求分析 :

要求支持用户的关注，取消关注，获取关注列表，获取关注数量的功能

模块分析 :

完全独立的一个业务，单独拆分成一个模块

关注模块

支持的功能

关注某人
取消关注
查看用户粉丝列表
查看用户关注列表
查看用户关注数量

表结构设计

表结构维护 Follower 和 Followee 以及 status 进行维护关系之间的展示

并且创建唯一索引 <follower_followee> 和普通索引 <followee_follower> 来优化查询用户的关注列表和粉丝列表

type FollowRelation struct {
	ID int64 `gorm:"primaryKey,autoIncrement,column:id"`

	Follower int64 `gorm:"type:int(11);not null;uniqueIndex:follower_followee,priority:1;index:followee_follower,priority:2"`
	Followee int64 `gorm:"type:int(11);not null;uniqueIndex:follower_followee,priority:2;index:followee_follower,priority:1"`

	Status uint8

	// 这里你可以根据自己的业务来增加字段，比如说
	// 关系类型，可以搞些什么普通关注，特殊关注
	// Type int64 `gorm:"column:type;type:int(11);comment:关注类型 0-普通关注"`
	// 备注
	// Note string `gorm:"column:remark;type:varchar(255);"`
	// 创建时间
	Ctime int64
	Utime int64
}

缓存设计

使用 Hash 结构维护一个 follow 和 followee 的关注和被关注数量

使用 TxPiepline 进行一致性控制

在关注和取消关注的时候进行同步的 +1 和 -1 操作

其他细节

拉黑，屏蔽 的功能不额外创建表进行存放。考虑这个操作是一个低频操作，因此使用 status 直接存放到关系表里面
对于关系表，一个用户关注100个人，那么行数就会增加100倍。使用阿里的 tablestore 进行类似分库分表的优化
获取用户关注数量和粉丝数量的时候。优先去获取 Redis 的数量然后再通过 Mysql Count 进行统计
获取关注列表不进行缓存。
- 考虑是一个低频操作缓存命中率低
- 并且是一个分页查询不好缓存

难点 & 亮点

问题 :

维护关注数量 , 我们可以采用单独创一张表进行实现。但是为关注服务直接创一张表太重了

方案 :

因此使用 Redis 进行直接统计计数在关注和取消关注的时候分别操作
在获取关注数量的时候使用 Cache-Aside快慢路径，优先获取 Redis 的数据然后再根据 Count 进行计数。因为我们关注表的索引设计，保证了能够命中索引

问题 :

创建了唯一索引后 <followee_follower> 。这个只能解决查询粉丝数量，但是对于关注数量并不能很好的命中索引

方案 :

反向创建一个普通索引，不需要额外创建唯一索引因为原有的索引就能控制。

亮点 :

使用 tablestore 进行维护大数据量级的关系信息。避免自身系统的复杂性
使用 TxPiePline 进行控制同时写入粉丝和关注的计数。
获取关注和粉丝列表是一个分页接口考虑用户使用频率低缓存命中率差。不进行额外缓存
取消关注通过表设计的 status 进行处理更新 status 就可以完成取消关注，软删除。并且在关注功能的时候，使用 Upsert 保证语意

缺点

对于关系维护的大数据量级处理只是引入了三方的 tablestore 进行处理比较简单
如果 Redis 崩溃，那么会有大部分 Count操作进入到我们的Mysql 中并没有很好的容错机制

总分：68 / 100

对「2 年经验、讲关注关系模块」的面试准备来说：骨架够用，能过一轮筛选，但扛不住有经验的面试官追问。 更像「能把做过的事串起来」，还没到「能把设计讲透、把坑讲清楚」。

优点

需求边界清晰：关注 / 取消关注 / 列表 / 数量，模块独立，简历表述和正文能对上。
表设计基本正确：Follower + Followee + 唯一索引防重复关注，反向普通索引服务粉丝查询，这是面试里常见的加分点。
有取舍意识：列表不缓存（低频 + 分页）、拉黑用 status 软状态、取消关注用 status + Upsert，说明不是只会「全量加 Redis」。
有自我批评：缺点里提到 Redis 挂了打爆 MySQL、tablestore 引入偏简单，态度加分。

缺点（面试里容易被打穿）

一致性讲错/讲浅了
TxPipeline 只保证 Redis 内部多命令原子，不保证 MySQL ↔ Redis 一致。面试官一问「DB 成功、Redis 失败怎么办？」现在的稿子接不住。
索引表述前后矛盾
前文唯一索引是 follower_followee，难点里写成「唯一索引 <followee_follower>」——细节错了会显得没真正想清楚。
计数方案深度不够
Hash + 同步 ±1 + Cache-Aside，缺：key 设计、并发丢更新、缓存击穿/雪崩、冷启动回源、与 DB 对账。
亮点偏「名词」
tablestore、Pipeline 写得很空，2 年经验候选人若只背名词，追问「为什么不用分表 / 为什么不用计数表」会立刻露馅。
业务边界漏洞
未关注却要拉黑、自己关注自己、重复关注并发、软删后重新关注的语义、分页游标 vs offset，基本没准备。
几乎没有 Golang 工程视角
接口分层、Repo、事务边界、幂等、错误码、超时降级——对「Golang 岗」这是硬伤。
文档完成度差
xxxx、TxPiepline 拼写、序号重复（两个「2.」），会给面试官「准备潦草」的印象。

建议（按优先级）

优先级	做什么
P0	把一致性故事补全：写路径（先 DB 再 Redis / Outbox / 对账）、读路径降级、Redis 不可用时的限流与熔断
P0	画一张「关注 / 取消关注」时序图，标清事务、Upsert、status、计数更新顺序
P1	准备 3 个追问标准答：并发重复关注、未关注拉黑、百万粉丝列表分页
P1	把 tablestore 改成「可选扩展」：先讲单机/单库上限与分片思路，再提引入外部存储的原因与代价
P2	补一层 Go 实现：`FollowService` 接口、幂等、GORM 事务片段，能对着代码讲 2 分钟
P2	修正文案与术语：Pipeline 拼写、索引名统一、标题 description 写完整

分项参考（面试官视角）

维度	分数	说明
需求与模块拆分	78	清楚，但偏浅
存储与索引	72	方向对，表述有错
缓存与一致性	55	最大短板
难点/亮点说服力	60	有点，深度不够
自我认知与表达	70	有缺点意识，文档粗糙
对 2 年岗的匹配度	68	能讲项目，难打深水区

一句话：当成「项目介绍提纲」大约 70+；当成「能过中高级追问的面试稿」现在大概 60 出头。把 DB–缓存一致性 和 3～5 个边界追问 补扎实，整体可以冲到 80+。

feed one

Fri, 07 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现关注,点赞, 收藏, 发布文章 Feed 流的实现

流程设计

需求分析 :

对于用户关注的博主, 希望能够在博主发布文章的第一时间进行通知
对于点赞 , 关注,收藏操作希望能够第一时间进行通知

模块分析 :

提供一个 Feed 服务供给业务方读取和写入

Feed 模块

支持的功能

通用的写入收件箱
业务定制化的写入收件箱并且根据业务定制考虑优先写入到发件箱
通用的查询用户 Feed 流
业务定制化的查询用户 Feed 流

表结构设计

对于收件箱和发件箱维护一个大JSON列进行处理

创建 uid和 ctime 的索引

type FeedPushEvent struct {
	Id int64 `gorm:"primaryKey,autoIncrement"`
	// 收件人
	UID int64 `gorm:"index"`
	// Type 用来标记是什么类型的事件
	// 这边决定了 Content 怎么解读
	Type string
	// 大的 json 串
	Content string
	Ctime   int64 `gorm:"index"`
	// 这个表理论上来说，是没有 Update 操作的
	Utime int64
}

缓存设计

无。因为需要保证实时性并不考虑设计缓存

但是引入 kafka 进行削峰。因为在业务上能够容忍 1s -10s 的响应误差

其他细节

在文章服务写入收件箱的时候考虑定制化服务

对于大V 关注的人很多, 写扩散来说会产生很多内容。因此根据用户粉丝数量来判断写入发件箱还是收件箱

同样的查询用户 Feed 流的时候同样在文章服务做定制化服务

因为大V 可能发送了文章之后又设置了隐藏，因此会额外根据 status 进行一层过滤

难点 & 亮点

难点 :

问题：

对于文章服务, 如果是一个大V 采用写扩散会一时间产生很多数据，但是普通用户无所谓。但是对于一个普通用户使用读扩散会导致请求多次数据库

方案 :

设计文章服务混合使用推拉模型，而点赞/关注服务只进行写扩散

难点 :

问题 :

读路径可能存在业务方定制和非业务方定制 , 并且还需要考虑数据聚合

方案 :

考虑优先读取业务定制的内容,通过每个handle 自己的实现进行读取。然后再通过通用逻辑进行读取。另外对于第三方业务方如果降级的情况会考虑不进行读取。全局limit查询之后再聚合内容进行排序

亮点 :

使用 Kafka 进行异步的处理 Feed 流
设计了一个通用的和业务定制化的 Feed 流。关联之前开发的点赞、收藏、文章服务

缺点

Feed 流的存储比较简单，非常粗暴的使用大JSON 进行存储并且数据表并没有做定期归档
写入服务还可以再优化，根据判断用户是否是活跃用户，判断是否要使用写扩散保证活跃用户的使用体验

作为面试官，按「2 年经验、能讲清一个完整 Feed 项目」来打分。

总分：62 / 100

维度	得分	满分	说明
需求与业务理解	12	15	关注/点赞/收藏/发文通知说清楚了
架构与方案设计	14	25	有推拉混合，但细节和取舍不够
数据与存储	8	15	表结构过简，缺容量与演进
工程实现（Kafka/异步）	10	15	有削峰思路，缺可靠性细节
难点与亮点表达	10	15	方向对，面试官追问容易露怯
自我反思与边界	8	15	有缺点意识，但深度不够

优点

业务闭环清晰：从「谁要被通知」到「Feed 读写服务」再到「文章大 V 定制」，简历点能对上故事。
推拉混合有意识：大 V 写发件箱、普通人写收件箱，这是 Feed 面试的核心考点，方向正确。
知道自己的短板：大 JSON、无归档、可按活跃用户优化写扩散——自我认知加分。
工程上有基本取舍：用 Kafka 换 1–10s 延迟，比「全都要实时」更真实。

缺点（面试里容易被打穿）

「无缓存」说得太绝对
实时性 ≠ 不能缓存。常见做法是：收件箱最近 N 条 Redis ZSet、发件箱热 Key、读路径短 TTL。直接说「无」会被追问「QPS 上去怎么办」。
表结构过于简陋
- 单表 Content 大 JSON：如何按 Type 过滤、分页、清理？
- uid + ctime 索引是否联合？大 V 粉丝千万级写入怎么分库分表？
- 发件箱表结构没写出来，推拉混合缺一半。
推拉切换规则模糊
「按粉丝数判断」——阈值多少？阈值变化怎么办？粉丝从 999 涨到 1001 历史数据怎么处理？面试官一追问就虚。
读路径描述含糊
「业务定制优先 → 通用逻辑 → 降级跳过 → limit 再聚合」——
多 Handler 如何保证全局时间序？每个源 limit 多少？聚合复杂度？降级后一致性？这些才是 2 年候选人该补的。
Kafka 只停在「削峰」
缺：幂等、顺序（按 uid 分区？）、失败重试/死信、重复投递、消费者并发与乱序。
亮点偏「做过什么」而非「解决了什么」
「用了 Kafka」「接了点赞收藏」——面试官更想听量化效果或具体坑（延迟、重复、空洞 Feed）。
文档结构略乱
功能列表编号重复、发件箱模型缺失、流程图依赖图片但文字没补关键路径。

建议（按优先级）

立刻补齐，面试可讲 3 分钟版

画清两条写路径 + 两条读路径
- 写：普通用户 → 写扩散进粉丝收件箱；大 V → 只写发件箱。
- 读：收件箱时间线 ∪ 关注列表里大 V 发件箱 → merge 按时间排序 → 分页。
把「粉丝阈值」说死
例：粉丝 ≥ 1万走拉模式；并说明阈值变更时只影响新内容、或异步回填策略。
缓存改成「有边界的有」
例：用户 Feed 首屏 200 条 ZSet；未命中再查 DB；写路径异步更新。强调与「可容忍秒级延迟」一致。
Kafka 准备 4 个追问答案
幂等（业务唯一键）、分区键（authorId/uid）、至少一次语义下的去重、消费失败策略。
亮点改成「问题 → 方案 → 结果」
例：「大 V 发文写扩散导致写放大 → 粉丝阈值切拉模式 → 峰值写 QPS 从 X 降到 Y」（没有真实数字就说「预期/压测方向」）。

建议你能背下来的追问清单

分页用 offset 还是 cursor？空洞/重复怎么处理？
取消关注、删文、隐藏后 Feed 如何失效？
点赞/收藏也写 Feed，和文章 Feed 如何统一 Type？
单用户收件箱无限增长怎么办（归档/TTL）？
降级某个业务 Handler 后，用户看到的 Feed 如何保证「还能刷」？

面试官结论

能过初级/中级偏初的筛选，但撑不起「独立设计过 Feed」的强叙事。
架构骨架有了（推拉混合 + 异步削峰 + 业务定制 Handler），但存储、缓存、一致性、容量、读聚合这几块偏薄，和 2 年「做过但未深挖」的画像吻合。

把推拉边界、读合并算法、Kafka 可靠性、缓存策略补成可口述的闭环后，有机会提到 75–80；再补上容量估算和一次真实故障/压测故事，才更像能打的中级候选人。

评论 one

Fri, 07 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 设计并实现了用户的评论功能, 支持多层级的评论回复

流程设计

需求分析 :

需要支持用户某篇文章进行评论
需要支持用户给评论进行评论
需要支持获取评论，以及获取子评论，创建评论，删除评论

模块分析 :

用户可以给文章进行评论也可以给用户的评论进行评论，可以抽象为用户给某个资源进行评论因此将评论单独抽象成一个服务

评论服务模块

支持的功能

获取第一页的评论
删除评论
创建评论
获取单条评论
获取子评论

表结构设计

设计 <PID, id> 外键, 因为我们不允许子评论出现在一个不存在的父评论上。并且我们希望在删除父评论的时候同步删除子评论。
引入 RootID, 因为是通过邻接表创建的评论结构。额外创建一个 RootId 列能够优化查询顶级评论下全部评论的时间
PID 和 RootID 的类型是 Sql.NullInt64 因为顶级节点的父节点是空。这里考虑优化成 -1

type Comment struct {
	ID int64

	Uid int64
	Biz   string `gorm:"index:biz_type_id"`
	BizID int64  `gorm:"index:biz_type_id"`


	PID sql.NullInt64 `gorm:"index"`
	// 外键指向的也是同一张表
	ParentComment *Comment `gorm:"ForeignKey:PID;AssociationForeignKey:ID;constraint:OnDelete:CASCADE"`

	RootID sql.NullInt64 `gorm:"index:root_ID_ctime"`
	Ctime  int64         `gorm:"index:root_ID_ctime"`

	// 评论的内容
	Content string

	Utime int64
}

获取评论列表功能设计

我们需要获取对应业务的第一页所有评论，并且返回前3条子评论

直接根据 biz 和 bizID 进行查询
考虑到并发问题使用 minID 进行偏移控制。如果使用 offset 可能会频繁变化
在降级到时候考虑不去读取子评论。遍历所有顶级节点然后并发的去查询子评论

其他细节

创建和删除的时候通过外键进行约束
查询顶级评论的时候根据 RootId 进行优化

难点 & 亮点

问题 :

对于多级评论的表结构设计

方案 :

使用邻接表的方案进行设计评论表。设计外键 <pid, id> 控制插入子评论的时候不应该插入到不存在的父评论。以及删除父评论的时候应该同步删除子评论

亮点 :

在查找第一页评论的时候需要返回对应的前3条子评论。考虑在服务降级的时候，不走这部分慢查询。
考虑用户可以评论别人的评论和文章将评论服务单独拆成一个服务并且使用 biz + biz_id 进行通用化处理
使用 minId 进行第一次分页查询，避免 offset 在高并发插入下会漏
表结构设计冗余 RootID 列，在查询顶级评论的时候能够直接查询全部回复，而不需要递归一整颗树

缺点

没有较好的缓存方案，例如加载第一页的时候可以考虑维护一个热榜评论，并且缓存第一页定时刷新

总分：68 / 100

对标 2 年 Golang、简历点「多层级评论」：能讲清主干，但深度、完整性和面试表达还不够稳，容易被追问卡住。

分项（满分）

维度	分	说明
需求分析 / 边界	14/20	功能列全了，缺非功能（QPS、延迟、一致性、审核）
表结构 / 建模	16/20	邻接表 + RootID + FK 方向对，细节经不起深挖
查询 / 分页	12/20	知道 minID、降级，论证不严谨，实现路径模糊
亮点可讲性	14/20	有点，但缺「为什么 / 怎么权衡 / 踩过什么坑」
表达与材料质量	12/20	结构尚可，笔误多、描述空、像草稿

优点

服务抽象合理：biz + biz_id 把「评文章 / 评评论」统一成资源评论，符合可扩展拆分，面试官一般认可。
树存储选型正确：邻接表 + 冗余 RootID 是常见方案；外键约束父子存在性、级联删也说得通。
有工程意识：第一页带前 3 条子评、降级不查子评、minID 代替 offset，说明想过热路径和并发插入。
有自省：主动写「缺缓存」比硬吹完整方案更加分。

缺点（面试里会被追的）

「多层级」与实现深度不匹配
简历写多层级，正文几乎是「顶级 + 若干子评」。要明确：产品是无限嵌套还是只展示两级；邻接表如何保证插入时 PID/RootID 一致。
分页说法不严谨
高并发下 offset 的问题主要是重复/跳过、深分页成本，不是简单「漏数据」。minID（游标）要讲清排序键（id 还是 ctime）、同时间戳、方向（上滑/下滑）。
级联硬删很脆
真实产品多为软删、子评保留并标「父评已删」。只说 OnDelete:CASCADE 会被问：误删恢复、审核下架、计数怎么维护。
「前 3 条子评」实现空洞
按时间还是热度？一次 SQL 还是 N+1？并发查子评的限流、错误、超时？降级开关与指标？这些不补，亮点站不住。
空值方案半吊子
sql.NullInt64 vs -1 只提「考虑」，没有索引、查询条件、GORM 写入的结论。
缺面试常问块
创建时事务与 RootID 赋值、内容长度/敏感词、计数（回复数）、鉴权（谁可删）、幂等、缓存一致性——几乎空白。
材料完成度低
description: xxxx、错别字、口语化、无接口草图/时序，显得准备不充分。

建议（按优先级）

准备 3 分钟口述稿：需求 → 为何独立评论服务 → 表（PID/RootID）→ 第一页查询（含前 3 条子评）→ 降级 → 已知不足（缓存）。控制在 2～3 分钟。
画清两种删除语义：硬删级联 vs 软删；选一种并说清对列表、计数、子评展示的影响。
把分页讲死：排序字段、WHERE id < ? ORDER BY id DESC LIMIT、为何不用 offset、边界 case。
补「前 3 条」实现：例如按 root_id 批量取 + 应用层截断，或窗口函数；说明为何不用「每条顶级再查一次」做默认路径。
补一条缓存方案（哪怕未做）：第一页热评 ZSet / 本地+Redis、失效（写删、TTL）、穿透与击穿——对应你自己写的缺点。
对齐简历用词：若只做两级展示，简历改成「支持回复与两级展示」；若真支持 N 级，补插入校验与查询深度限制。
准备 5 个追问答案：并发插评、父评不存在、删父留子、深分页、评论热点文章打爆 DB。

一句话结论

68 分：方向和关键词对，够「做过评论」的入门讲述；要过认真的 Golang 一面/二面，需要把分页、删除语义、子评批量查询和缓存权衡讲扎实，并把材料从草稿修到能直接口述的版本。

热榜 one

Fri, 07 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 实现多实例部署下的热榜异步计算和查询

流程设计

需求分析 :

需要能够获取到最近7天前100点赞的数据

模块分析 :

设计一个 RankService 支持获取 TopN 的操作

模块设计

提供一个基于本地缓存 + Zset 实现的热榜设计并且通过分key 热点信息
提供一个离线计算的热榜服务, 使用小根堆进行维护数据。使用分布式锁启动时固定实例进行计算热榜

难点 & 亮点

问题 :

热榜服务要求高可用高性能以及处理较大的数据怎么做到 ?

方案 :

使用本地缓存 + Redis 的方式进行处理高可用。如果本地缓存和redis 缓存都实效加载本地已过期的进行兜底
较大的数据可以采用分key 的方式进行处理。或者通过业务折中的方式，例如只考虑最近7天的 top 数据，最近 7 天可能最多也就100w条

问题 :

Zset 不可能进行较大数据量大计算, 这会给机器带来很大的压力

方案 :

采用定时任务离线计算。
使用优先队列维护一个小根堆，固定 TopN 的数量。每次分批进行获取数据加载计算

亮点 :

考虑在多实例部署的情况下, 可能会存在多个实例同时计算一个热榜，并且每个热榜都会有细微的偏差。使用分布式锁+自动续约的机制控制同一时间只有一个节点在进行计算
使用 Hacknews 模型 Score = (p - 1) / (T + 2)^G 公式进行计算热点信息。防止点赞数量被老贴市场霸占
在 Redis 存 TopN 的时候晴空 Content 避免占用较大的内存

缺点

缓存方式比较简单
强一致性不足

总分：62 / 100

按「2 年 Golang 后端」面试标准看：方向对、有架构意识，但深度不够、表述不严谨、经不起追问。能过初筛讲清故事，很难稳住深挖。

维度	分数	简评
问题定义与业务抽象	70	TopN + 近 7 天边界清楚
架构设计完整性	65	多级缓存 + 离线计算主链路合理
技术细节与落地	50	缺关键实现、参数、边界条件
难点亮点说服力	68	锁、堆、HN 公式有亮点，但讲不透
表达与专业度	55	错别字、占位符多，像草稿
面试可追问准备	48	几乎没有「被问住」时的备用料

优点

主路径合理：查询走本地缓存 → Redis → 兜底；计算走离线 TopN + 小根堆，符合热榜常见做法，不是乱堆关键词。
有业务折中意识：用「近 7 天 / 约 100 万」控数据量，比硬扛全量排序更像有生产经验。
亮点选得对：多实例分布式锁、Hacker News 时间衰减、ZSet 不存 Content——这些正是面试官能追问的点。
主动暴露缺点：缓存简单、强一致不足，至少说明你知道系统边界，比只会吹「高可用高性能」好。
有架构图：比纯文字更容易在面试里讲清读写两条链路。

缺点（面试会被卡住的地方）

简历描述太空：「多实例部署下的热榜异步计算和查询」没有规模、指标、职责边界，面试官第一问就会要数字。
方案停在名词层：分 key、小根堆、分布式锁、自动续约都点到了，但缺：
- 分 key 规则（按天？按互动类型？怎么合并 TopN？）
- 堆的维护时机与批大小
- 锁用 Redis/etcd？续约失败怎么办？持锁实例挂了呢？
- 本地缓存过期后仍兜底，跨实例一致性怎么说？
公式只写了不解释：Score = (p - 1) / (T + 2)^G 里 p/T/G 含义、G 怎么选、和「点赞数排序」差在哪，不讲等于没亮点。
图文对不齐：图里有并发 Queue、分区、forceGetLocal，正文几乎没展开，面试官对着图一问，你会空。
「高可用」论证弱：本地 + Redis 失效后用过期数据，是降级不是高可用；没有说明降级 SLA、空榜、穿透、击穿。
表达不专业：xxxx、实效→失效、晴空→清空、Hacknews，会直接拉低可信度。
缺点写完就停了：「强一致性不足」没有影响面和为何可接受，像没想完。

建议（按面试准备优先级）

补一组可说的数字：数据量、TopN、计算周期、单次计算耗时、QPS、缓存命中率、锁超时/续约周期。没有真实数也要给合理量级。
准备 3 层回答：一句话结论 → 架构步骤 → 细节/权衡。例如「为何小根堆」：只要 Top100，堆复杂度 O(n log k)，比全量排序或大 ZSet 更合适。
把追问清单写进稿子，至少覆盖：
- 多实例本地缓存不一致怎么办？
- 计算中途失败，半成品会不会写进 Redis？
- 分 key 后如何得到全局 Top100？
- 锁续约失败 / 时钟漂移 / 脑裂
- 缓存击穿（热榜 key 过期瞬间）
讲清 HN 公式：老帖高赞为何会被新帖追上；G 调大/调小的业务含义。
把图里的并发 Queue 讲成 Go 实现：channel + worker pool、batch size、背压，对应 2 年经验该有的落地感。
润色表述：去掉占位符和错别字；简历改成「近 7 天 Top100 热榜：离线小根堆计算 + Redis ZSet + 本地缓存，分布式锁保证单实例计算」。
缺点改成「已知取舍」：例如强一致不必要，因为热榜允许分钟级延迟；用计算周期 + TTL 把最终一致说清楚。

面试官视角一句话

作为 2 年经验候选人，这份材料证明你做过热榜、懂分层和折中，但目前更像设计草稿，不像能扛 20–30 分钟深挖的面试稿。把「分 key / 锁续约 / 公式参数 / 并发队列 / 降级语义」补实，并清掉错别字，分数大概能到 75–80；再补上指标和失败场景，才比较稳。

搜索 one

Thu, 06 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 设计并实现了搜索

流程设计

需求分析 :

支持用户创建标签, 查看已有标签, 删除标签
支持用户给指定文章打标签
支持用户查询对应关键字的文章并且把打过标签的文章优先返回

模块分析 :

考虑标签应该是一个通用的功能所以将标签单独拆分一个模块

并且不希望业务直接写入ES，单独设计一层搜索和插入服务。将读和写拆成两个服务

标签服务模块

支持功能

覆盖标签
创建标签
获取用户的全部标签
获取用户给某篇文章打的全部标签

表结构设计

设计 Tag 表, 和 TagBiz 表用于统计用户创建的 tag 和用户给文章标记的 Tag

索引设计 :

在 Tag 表上设计了 uid 为索引，保证获取用户的全部标签的时候能够命中

在TagBiz表设计了 biz_id,biz 和 uid 设计了索引, 同时tagBiz 设置 target_id 外键连接 tag 表

考虑 uid 的不可变性, 设计 tagBiz 表的时候冗余了 uid 的设计，从而在查寻用户给某篇文章打的标签的时候不需要去Join Tag表加速查询

缓存设计

在获取用户的全部标签的时候, 考虑使用缓存预加载进行优化

在程序启动的时候，提前全量扫描一次数据库
将数据分key 加载到 redis-list 中
在获取全部标签的时候预先读取缓存再去操作数据库

插入搜索模块

支持

通用的插入逻辑 content_id,content
业务定制化的 user 和 article 的插入逻辑

Es 索引设计

文章表结构设计 :

title , content , id ,status . 这里引入 status 主要是为了后续用户可以查看到仅自己可以见的文章处理

用户表设计 :

nickename, email(text), phone, id . email设计称为 text 而不是keyword是因为正常人很难记住邮箱

数据插入处理

使用 Kafka 开启 3个 Consumer 分别监听文章, User, Any 的插入

因为我们在索引中引入了 id 字段, 保证了在并发场景下是 upsert 语意

查询搜索模块

支持查询有关用户的信息
支持查询有关文章的信息
- 并且将用户打过标签文章的内容优先返回

联合 Tag 查询

Es 支持通过父子关系和内嵌文章进行联合查询但是性能过差。我们这里采用二次查询的方式实现联合查询

先查询 Tag 里面的内容，查询当前用户已经打过标签的文章 id
再去查询有关keywords的文章信息，并且使用 TermQuery Boost 增加在第一次查询出来的权重

难点 & 亮点

问题 :

用户在给某个文章打标签的时候都会加载一次自己已有的全部标签, 预计这里会是一个高频的全量扫表过程

方案 :

使用 Redis-list 预加载一次全部用户的全部标签内容
每次查询优先查询缓存再查询数据库,对于未命中的内容再次更新缓存

问题 :

在获取用户给某篇文章的所有标签内容处理时都需要去 Join 一次 Tag 表 . Join操作会变慢

方案 :

因为 Uid 的不可变性。我们设计的 tag 是基于 Uid 的。不存在用户A给文章 A打了标签。突然这个标签变成用户 B 的情况。所以在 TagBiz 冗余了 Uid 字段加速查询

问题 :

用户对一篇文章重复打标签可能会有并发问题。因为我们使用 kafka 进行发送Es信息

方案 :

在对应 producer 的时候, 使用 key 绑定对应的uid 保证同一个uid 的内容只会发送到同一个分区

亮点 :

实现了两个 Tag 内容之前的查询 , 使用二次查询的方法实现用户查询有关文章的时候, 优先返回已打标签的文章

亮点 :

搜索服务拆分成 sync 和 search ,读写分离。业务方面不直连 Es . 并且支持 InputAny 方便业务快速上线

亮点 :

预加载的时候使用 pipeline 进行打包发送 redis 指令

缺点

仅实现了文章和标签的相关服务。实现内容过少，并没有聚合点赞收藏等业务
Kafka 部分少了兜底机制

总分：61 / 100

定位：2 年经验、项目深挖准备材料。能讲清主流程和模块边界，但多处方案经不起追问，Golang 工程深度偏弱。面试中「能讲」可以，扛不住连环追问。

维度	分数	说明
需求与模块拆分	72	标签独立、读写拆分思路清楚
表结构 / 索引	65	有索引与冗余意识，外键与命名易被挑
缓存设计	42	启动全量预加载是明显硬伤
ES / 搜索	60	二次查询 + Boost 合理，缺量化与一致性
Kafka / 并发	48	问题与解法错位
难点亮点表达	68	有结构，但方案可信度不足
自我认知	70	知道功能少、缺兜底
Golang 工程深度	35	几乎看不到语言/并发/落地细节

优点

需求 → 模块 → 表 → 缓存 → MQ → ES 叙事完整，面试官能跟着走。
标签独立模块 + sync/search 读写分离 + 业务不直连 ES，符合中级对边界的基本要求。
TagBiz 冗余 uid 避免 Join、ES 二次查询 + Term Boost（相对 nested/父子文档）是可讲的取舍。
有难点/亮点/缺点框架，并提到 Kafka 缺兜底、功能未聚合，比只会吹亮点强。
提到 pipeline 批量写 Redis、id upsert，说明接触过落地细节。

缺点（面试里最容易被打穿的点）

缓存方案危险
启动全量扫库、把「全部用户全部标签」塞进 Redis List：冷启动、内存、扩缩容、局部失效都没讲。2 年经验里这是减分点，不是加分点。List 也不适合标签的增删改；一致性（写标签后如何更新缓存）几乎空白。
并发问题与解法错位
「重复打标签」应落到：DB 唯一约束 / 事务 / 幂等。Kafka 按 uid 分区只保证同 uid 有序，解决不了重复打标、更解决不了跨服务幂等。面试官一追问就会露馅。
ES 细节经不起问
- email 用 text：理由偏弱，应讲分词、模糊、精确匹配、keyword 多字段。
- status 字段只点到，未见权限/过滤怎么做。
- upsert、同步延迟、最终一致性、失败重试几乎没准备。
表设计表述不严谨
TagBiz target_id 外键、索引 (biz_id, biz) + uid 缺查询路径说明；「覆盖标签」语义不清。
缺量化与 Golang 深度
无 QPS、延迟、数据量、缓存命中率。无接口抽象、超时取消、consumer 并发、错误处理、压测——对 Golang 岗这是硬伤。
材料完成度
「其他细节」空、序号重复、resume「搜索」与正文「标签+搜索」焦点略散。

建议（按优先级）

1. 重写缓存故事（必改）
改成：按 uid 懒加载 / 热点预热；Hash 或 String+JSON；打标/删标时删缓存或局部更新；讲穿透、击穿、雪崩之一即可。删掉「启动全量预加载所有用户」。

2. 对齐「重复打标」叙事
主答：唯一索引 (uid, biz, biz_id, tag_id) + 幂等；Kafka 分区 key 只作为「同步有序/同用户串行」的补充，不要当并发正解。

3. 补 3 个可量化数字
例：标签人均条数、搜索 P99、sync 延迟、日增量。没有真实数据就给设计目标量级，比没有强。

4. 准备 5 个追问答案

标签写后搜索多久可见？
sync 失败怎么办？（重试、DLQ、对账）
缓存与 DB 不一致怎么办？
Boost 权重怎么定、如何验证效果？
为何不用 nested / join / 宽表？

5. 补 Golang 落地半页
Consumer 并发模型、context 超时、接口分层、ES client 错误处理、本地单测怎么 mock——面试官常从这里区分 1 年和 2 年。

6. 收束简历表述
简历写「标签 + 搜索（读写分离）」或主讲一条线，避免「实现了搜索」却大段讲标签预热。

面试官一句话结论

能过初筛讲项目，过不了深挖。 模块拆分和二次查询+Boost 可以撑住 10–15 分钟；缓存全量预加载和「Kafka 解决重复打标」会把印象从「还行」拉到「基础不扎实」。把这两处改掉，材料有机会到 75+；再补量化与 Golang 细节，更接近 2 年合格线。

打赏 one

Wed, 05 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 支持用户使用微信支付进行文章的打赏功能以及用户对账流程

流程设计

需求分析 :

用户能够选择一篇文章通过微信支付进行打赏
支付成功后用户能够在自己的余额里面看到扣款以及被打赏的金额，同时可以看到对应的流水

模块设计 :

考虑支付是一个通用的模块, 并且支付可以额外对接审计，账号，反洗钱等模块所以把支付模块单独拆分出来

设计 支付、用户资产、打赏 三个模块

功能分析 :

用户模块支持 :

查看业务流水
更新用户资产

打赏模块支持 :

查看文章打赏记录
发起支付请求

支付模块支持 :

向第三方发起支付请求
接受微信支付的calback
查询发起的支付信息

难点 & 亮点

问题 :

微信支付回调后如果成功那么不会在此推送消息, 我们使用 MQ进行通知下游,如果MQ发送失败那么将丢失该信息

方案 :

引入本地消息表
使用本地事务开启支付表和本地消息表的写入。并且设置消息表 init
只有当MQ发送成功之后才会设置本地表 success 。
定时任务定时轮询 init 的任务进行补偿

问题 :

由于本地消息表的引入, 可能带来重复消费的问题

方案 :

在下游账户处理模块，设置了 biz_id + biz + account + account_type 的联合唯一索引
并且引入 redis 进行查询优化, 预先判断 redis 的状态

问题 :

可能存在微信回调消息发送失败, 微信回调只会默认会在 30分钟之后不再回调不管成功或是失败

方案 :

定时任务定期扫描超过约30分钟的未完结订单主动查询微信状态并写回

问题 :

获取打赏信息的时候 ,我们会先去查询打赏表的数据,如果打赏表数据还未完成。会通过慢路径查询支付表的信息进行更新用于加快状态的轮询。

方案 :

考虑限流时候降级, 对于限流的时候不走慢路径
在账户资产更新 MQ 的时候会一并更新对应的状态

亮点 :

模块拆分与边界 + gRPC

支付只关心第三方与支付单状态
打赏只关心业务单和分账意图
账户只关心余额与流水

缺点

缺少定时自动对账的机制。涉及 打赏-支付-记帐 三个流程
在 MQ 更新账户资产和打赏表的时候。并不是强一致的, 我们优先更新打赏表, 如果之后调用 rpc 处理账户资产失败了。那么会发送告警由人工手动修复

其他细节

支付消息必然发送成功

支付的一个核心步骤是由微信来回调的 . 我们原先的处理是

微信回调
更新支付表状态
发送消息给 MQ 通知账户变更

如果这里 MQ 发送失败,那么将会丢失这笔消息。但是支付消息可以认为是一个非常关键的功能。

所以考虑优化引入了本地消息表

表结构设计

主要字段 content 和 status
我们通过 content 记录原有的 MQ 信息使用 status 维护 MQ 的状态分为 init,success,failed

{
id: "id"
content: ""
stauts: ""
Ctime: ""
Utime: ""
}

流程优化设计 :

使用事务控制更新支付表状态和写入本地事务表并且初始化 init
只有当我们成功发送 MQ 之后才把本地事务表设置 success
- 这里可能会造成重复发送
开启一个定时任务，批次获取 init 的状态, 然后发送 MQ 消息。如果半小时内都发送失败设置 failed . 发送成功之后设置 success

接口幂等性分析

由于改造了本地事务之后，可能会产生重复消费数据 . 我们在下游账户更新的时候

通过 redis+ 本地索引来处理。

我们设置账户流水表的唯一索引 biz,biz_id,account,account_type 进行过滤

biz_id 就是微信回调里面带的 tradeNoId

使用 redis 进行初步过滤使用唯一索引进行兜底

打赏详情降级处理

我们打赏的时候会先查询我们打赏表如果打赏已经是支付状态会直接返回
否则会去查询一遍支付表

对于限速的状态,我们会抛弃这个慢路径。这条慢路径，由 MQ 进行处理, MQ 会较慢一点时间更新到支付表的状态。

func (s *WechatNativeRewardService) GetReward(ctx context.Context, rid, uid int64) (domain.Reward, error) {
	// 快路径
	r, err := s.repo.GetReward(ctx, rid)
	if err != nil {
		return domain.Reward{}, err
	}
	if r.Uid != uid {
		// 说明是非法查询
		return domain.Reward{}, errors.New("查询的打赏记录和打赏人对不上")
	}

	// 有可能，我的打赏记录，还是 Init 状态
	// 已经是完结状态
	if r.Completed() || ctx.Value("limited") == "true" {
		// 我已经知道你的支付结果了
		return r, nil
	}

	// 这个时候，考虑到支付到查询结果，我们搞一个慢路径
	// 你有可能支付了，但是我 reward 本身没有收到通知
	// 我直接查询 payment，
	// 只能解决，支付收到了，但是 reward 没收到
	// 降级状态，限流状态，熔断状态，不要走慢路径
	resp, err := s.client.GetPayment(ctx, &pmtv1.GetPaymentRequest{
		BizTradeNo: s.bizTradeNO(r.Id),
	})
	if err != nil {
		// 这边我们直接返回从数据库查询的数据
		s.l.Error("慢路径查询支付结果失败",
			logger.Int64("rid", r.Id), logger.Error(err.Error()))
		return r, nil
	}
	// 更新状态
	switch resp.Status {
	case pmtv1.PaymentStatus_PaymentStatusFailed:
		r.Status = domain.RewardStatusFailed
	case pmtv1.PaymentStatus_PaymentStatusInit:
		r.Status = domain.RewardStatusInit
	case pmtv1.PaymentStatus_PaymentStatusSuccess:
		r.Status = domain.RewardStatusPayed
	case pmtv1.PaymentStatus_PaymentStatusRefund:
		// 理论上来说不可能出现这个，直接设置为失败
		r.Status = domain.RewardStatusFailed
	}
	err = s.repo.UpdateStatus(ctx, rid, r.Status)
	if err != nil {
		s.l.Error("更新本地打赏状态失败",
			logger.Int64("rid", r.Id), logger.Error(err.Error()))
		return r, nil
	}
	return r, nil
}

总分：72 / 100

对应 2 年经验中级偏上：系统设计与可靠性意识不错，能讲清主链路和几个关键问题；但深度、闭环和对面试追问的准备还不够稳。

评分拆解

维度	分数	说明
需求与业务理解	14/20	主流程清楚，但对账、分账、退款几乎空缺
模块拆分与边界	16/20	支付 / 打赏 / 账户划分合理，亮点明确
可靠性设计（消息必达、补偿）	18/20	本地消息表 + 定时补偿是加分项
幂等与一致性	12/20	有唯一索引思路，但一致性模型讲得偏浅
降级与工程细节	8/10	慢路径 + 限流降级有工程味道
表达与面试可讲性	4/10	结构散、术语错误多，容易被追问打穿

优点

边界意识好
「支付只关心第三方与支付单」「打赏关心业务单」「账户关心余额流水」——这是面试里很吃香的表述，说明做过拆分，不是堆接口。
抓住了支付域真难点
微信回调只推一次成功、MQ 可能丢、回调有时效——都点到了，再配本地消息表 + 定时扫 init 补偿，对 2 年经验来说已经超过很多只会 CRUD 的候选人。
幂等有兜底思路
biz + biz_id + account + account_type 唯一索引 + Redis 前置过滤，主路径对、兜底也对。
会主动说缺点
缺自动对账、账户与打赏非强一致靠告警人工修——面试官通常加分，显得务实。
有可落地的代码片段
GetReward 快慢路径 + limited 降级，能证明不是纯理论。

缺点（面试里容易被打穿的点）

「对账」名不副实
简历写「对账流程」，正文却写「缺少定时自动对账」。2 年经验可以不做完整对账，但简历与口述必须对齐，否则会被认定夸大。
一致性模型说不清
「优先更新打赏表，RPC 失败靠人工」——面试官会问：为何不先账后业务 / 同事务 / Outbox 统一出口？最终一致还是人工一致？超时重试与幂等如何配合？这里准备不足。
本地消息表细节偏薄
- failed 后怎么办？（死信、告警、人工重放）
- 发送成功但改 status 失败 → 重复投递，下游如何保证？
- 定时任务并发扫同一批 init 如何防重？
- content 序列化格式、版本兼容？
  这些是「本地消息表」题的标配追问。
Redis 幂等设计不严谨
「预先判断 Redis 状态」太模糊：key 是什么？TTL？先 Redis 还是先 DB？Redis 挂了怎么办？正确叙事应是：DB 唯一约束是真相，Redis 只是加速，不能单独当幂等源。
Golang / 工程深度弱
全文几乎没有：gRPC 超时与重试、context 传递、回调验签、并发安全、事务边界、错误码。2 年 Golang 岗会被追问这些。
表达与硬伤
calback、stauts、ctx.Value("limited")（类型不安全、难测）、JSON 伪结构不规范——细节会拉印象分。
退款 / 部分失败 / 重复打赏 几乎未覆盖
支付面试常问：重复回调、金额篡改校验、订单超时关单、退款与冲正。

建议（按优先级）

1. 先改简历表述（立刻做）

改为：「实现微信支付打赏；用本地消息表保证支付结果可靠投递；账户侧幂等入账」
不要写「完整对账」，除非补一版：按日对 支付成功单 vs 账户流水 vs 打赏状态 的差异报表 + 告警。

2. 准备一张 2 分钟口述主链路
发起打赏 → 建业务单/支付单 → 微信下单 → 回调验签 → 本地事务写支付状态+Outbox → 发 MQ → 账户幂等入账 → 更新打赏状态；失败靠定时补偿 + 主动查单。

3. 把三个「追问答案」写死

为何本地消息表而不是直接依赖微信重试？
重复消息如何保证只加一次钱？
打赏已成功、账户失败如何发现与修复？（最好从「人工」升级到「对账任务 + 可重放」）

4. 补齐技术细节清单（半页纸即可）

回调验签、金额与 out_trade_no 校验
Outbox 状态机：init → sending → success / failed
定时任务：分页、FOR UPDATE SKIP LOCKED 或租约，避免多实例抢同一批
幂等：先插流水（唯一索引）再改余额；冲突当成功返回
主动查单：状态机只允许 Init→Success/Failed，禁止回退

5. 代码展示再打磨

限流标记不要用 ctx.Value("limited")，改成明确参数或中间件注入的 Limiter/Degrade 标志
慢路径更新打赏状态时说明：是否只更新、是否再触发入账（避免查询接口变成写副作用）

6. 面试话术升级一句
不要只说「模块拆了」；说：「支付可复用到会员/订单，打赏是支付的一种业务形态，账户是账本，三者用 MQ 最终一致，用唯一键兜底。」

面试官结论

这份材料说明候选人做过真实支付链路，懂拆分和消息可靠性，对 2 年经验够用；但若现场只能复述文档、答不上一致性与对账追问，分数会掉到 60 左右。把「对账诚实化 + Outbox/幂等细节 + 2 分钟口述」补上，冲击 80+ 更稳。

不停机数据迁移 one

Mon, 03 Aug 2026 00:00:00 +0000

简历 preview

简历上 : 支持一套通用的同构数据不停机迁移方案, 支持全量和增量校验使用 kafka 进行减轻数据库压力并且动态的根据数据库状态进行切换挂载和运行

方案描述 :

由于我在拆分了点赞、阅读、收藏相关的微服务, 考虑微服务中一个服务一个数据库进行数据隔离。从而实现了一套数据迁移方案。因为不修改原有数据存储架构，所以采用同构的方案 , 并且考虑这个服务属于关键服务，因此选用不停机迁移方案

考虑在 100w条数据的情况下,如果进行校验后立即进行修复会给数据库带来很大的负担因此使用 kafka 进行削峰的处理

另外通过额外重写 gorm 中 connPool 的exec、prepare、query Func 实现双写

并且通过重写 Commit 和 Rollback 实现双写的事务控制

困难点和改进 :

引入 kafka 进行异步的优化全量校验与修复的过程。
优化单条校验的逻辑采用批量校验的逻辑。并且考虑硬删除的业务场景，在校验原表和目标表的条件下，同步进行目标表和原表的差异校验防止硬删除产生的不一致问题
支持使用者动态切换数据迁移 原表only,读原表写目标表，读目标表写原表，目标表only 的配置
支持根据数据库状态，判断是否高负载从而判断是否要挂载校验任务。并且通过 context cancel() 实现，尽可能只有同一个全量/增量校验程序在运行

缺点 :

因为 ConnPool 返回值 sql.Result 并不暴露 Error 的设置，所以对于双写的错误并不能很好的暴露出来，只能进行打log和监控
事务控制的实现并不能保证一致性，只能做到主表最大可控，但是对于目标表如果失败了只能等待全量校验与修复

不停机迁移数据

相比较于停机迁移数据，主要的困难点在于一边迁移一边有新数据产生

并且因为我们切换原表和目标表的时候，如果运气不好会导致出现一些数据不一致。不停机数据迁移很难做到最终数据一致性

数据校验

为了防止重复写一些 dirty code, 放弃在 dao层维护两个数据库的思路

重建了一套通用的双写逻辑。由业务方提供 equal 的方法，对于某些校验不严格的业务方可以考虑

不需要 time 就可以认为 equal 以及自定义精度误差等等

流量控制和性能优化

在数据库高负载的情况下会自动挂起全量校验只有当数据库低负载的时候才会进行
尽可能多的进行异步处理和并发处理。对于全量数据与校验采用异步处理，对于目标表和原表的校验以及目标表和原表的差异校验采用异步处理的方式进行

面试题

Q: 不停机迁移的基本步骤是什么

数据初始化，完成首轮数据的同步和数据库表的建立。对于 mysql 可以使用 mysqldump 进行同步，如果是异构数据的话，可以考虑内部批量轮询的方式进行首次同步
这时候可以考虑启用全量校验进行一次数据的校验与修复
读取并写入原表同时写入目标表。同时进行全量校验与修复
写入并读取目标表同时写入原表。同时进行全量校验与修复如果业务稳定可以考虑只运行增量校验
完全使用目标表

Q : 你的数据校验方案是什么

支持全量的数据校验和增量的数据方案。通过用户是否传递 utime + sleepTime 考虑走的是全量校验还是增强校验
同步的进行原表和目标表的校验以及目标表和原表的差异检查。批量获取原表的数据并且批量的获取目标表的数据，使用业务方提供的 equal method 进行比对，如果存在不想等的在轮询完成之后批量通过 kafka 发送给下游修复。批量获取目标表的数据，并且检查是否在原表存在，如果不存在同时发送对应的 event 给下游

Q : 你的数据修复方案是什么？如何保证数据正确性？怎么解决并发问题？

使用 kafka 进行异步的通知修复。 kafka 仅仅只是做触发器，并不存放detail信息用于实际修复。
对于数据修复情况只会有3种场景，target 不存在那么需要insert，not equal 需要进行 update, base_missing 则需要删除。考虑 insert & update 的并发问题，使用 upsert 进行控制
并不能够在单词修复保证数据的正确性，数据的正确性最终交由多次校验与修复来控制

Q : 在数据迁移的每个阶段，你是怎么考虑保护着数据库的

尽可能的进行批量操作。批量的查询数据库，本地机器进行比对
使用 kafka 进行异步的校验与修复
考虑调度时机进行校验任务的运行，对于数据库高负载的情况挂载正在运行的任务

Q : 如果 kafka 瓶颈了怎么办，消息积压了怎么办？

优化消费者。尽可能改成批量消费
并行处理数据库修复流程

Q : 为什么你要使用 Kafka 直接校验之后修复数据不行吗

直接进行修复数据 , 会给数据库带来很大的负担。 Mysql 单库的读写有瓶颈，尽可能保证大量的读和写操作不同时进行

Q: 增量校验和修复、业务写数据、全量校验和修复同时进行，有什么并发问题？怎么解决？

同时进行会带来更多的数据库操作，带来负担。并且我们在事务以及双写操作上必然会有并发问题，在我们切换目标表和原表的时候最终总会有不一致的情况。
采用超时控制, 优化任务调度时间。所有的不一致问题，最终都是由反复校验反复修复解决的

Q : 怎么保证在数据迁移的时候不影响业务

调度时间的控制。在低负载的情况下进行
可以考虑在内部数据跑完几次全量校验之后只开启增量校验，每次仅校验一周之内的数据

总分：62 / 100

按「2 年经验、能讲清一个核心项目」来评：能过初筛，但扛不住深挖。

评分拆解

维度	分数	说明
项目背景与动机	12/15	微服务拆库、同构不停机，动机清楚
方案完整性	14/25	四阶段迁移有框架，关键细节和边界含糊
技术深度	10/20	提到 ConnPool 双写、Kafka 削峰，但原理讲不透
问题意识与权衡	12/15	能主动说缺点，这点加分
面试表达与结构化	8/15	有 Q&A，但表述乱、有笔误、答不到位
与 2 年经验匹配度	6/10	选题够大，但「最终靠反复校验」像在回避设计

优点

选题合适：不停机迁移 + 双写 + 校验修复，是面试官愿意追问的「有难度」项目。
有诚实的缺点：ConnPool 错误难暴露、事务只能保主表——比空谈「强一致」强很多。
有业务抽象意识：业务方提供 Equal，比硬编码字段对比更像工程实践。
有保护库的意识：批量、Kafka 削峰、高负载挂起任务，方向对。
准备了面试题清单：说明有意识在「被问什么」。

缺点（面试里会被打穿的点）

核心一致性说不清
「切换时总会不一致」「最终靠反复校验」可以当结论，但不能当唯一答案。面试官会问：双写失败怎么回滚？阶段切换的窗口期如何缩小？源表为准 / 目标表为准时，修复方向怎么定？
Kafka 用法站不住脚
「只做触发器、不带 detail」——那消费者靠什么修？再查一次库？查到的是哪一侧？积压时只说「批量消费 / 并行」，没有分区键、幂等、重试、死信、顺序。
并发问题答得空
业务写、全量校验、增量修复同时跑，只提「超时 + 调度」不够。应有：同一主键的冲突策略、upsert 的版本/utime 条件、校验批次与写路径的可见性。
双写实现太薄
重写 ConnPool / Commit / Rollback 是亮点，但文档几乎没展开：嵌套事务？只读语句？Prepare 缓存？目标库延迟？失败是「打日志继续」还是「业务失败」？
表达与严谨性差
「挂载」应为「挂起」；「增强校验」应为「增量」；步骤编号重复；句子碎、逻辑跳。面试口述时会显得准备乱。
缺可量化结果
100 万量级提了，但没有：迁移耗时、校验一轮多久、峰值 QPS、不一致率下降、切换窗口多长。2 年经验项目，数据是加分项。

建议（按优先级）

1. 把故事讲成一条线（30 秒版）
背景（拆库）→ 约束（不停机、同构）→ 四阶段 → 双写怎么做 → 校验/修复怎么兜底 → 已知局限。每阶段说清「读谁、写谁、以谁为准」。

2. 补齐 5 个必追问答案（写到能口述）

双写失败：主成功副失败怎么办？是否影响接口返回？
事务：主提交、目标失败时数据状态与补偿路径
Kafka：消息体设计、幂等键、消费失败重试、为何不直接同步修
硬删除：双向 diff 的具体算法（按主键批量 in-query）
切换：如何判断可以进下一阶段（不一致率、连续 N 轮全量通过）

3. 准备一组数字
例如：数据量、双写延迟、全量一轮时间、Kafka 吞吐、挂起阈值、最终不一致量级。

4. 把「反复校验」升级成「有界收敛」
说明：在「源为准」阶段修复方向固定；切换前要求不一致 < 阈值；切换后短窗口只开增量；为何认为会收敛而不是越修越乱。

5. 润色简历与口述

简历：一句话写清「四阶段双写 + 全量/增量校验 + Kafka 异步修复 + 负载感知调度」
去掉口语和错别字；每个 Q 控制在「结论 → 做法 → 权衡」三层

6. 区分「你做了什么」和「方案通用知识」
mysqldump 初始化、四阶段迁移是通识；面试官更想听你改 ConnPool、Equal 抽象、双向校验、挂起任务这些「你亲手做的」。

面试官结论

材料证明你做过这件事，也知道难点在一致性和库压力，作为 2 年经验的项目素材够用。但当前深度停在「知道概念 + 知道会有问题」，还不足以在中高级追问里稳住。

把一致性边界、Kafka 契约、双写失败语义、切换判定补全后，这份准备可以冲到 75–80；再加可量化结果和一次完整口述演练，才更接近「能让面试官点头」的水平。

阅读、点赞、收藏 one

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

简历 preview

简历上 :

实现了一个通用的阅读、点赞、收藏服务。使用 Kafka 进行解耦

数据库表设计 :

通用表设计 :

id,biz,bizid,readCnt,CollectCnt,LikeCnt

为 bizid 和 biz 创建一个联合唯一索引

点赞表设计 :

id,biz,bizid,uid,status

为 bizid 和 biz和uid 创建一个联合唯一索引, 用 status进行软删除

数据库处理

对于阅读、点赞、收藏操作都会涉及到一个 check-dothing 的并发问题

即 : 当用户点赞的时候文章是否已经点赞过了，如果点赞过需要+1，否则创建，这里统一采用 do on conflict update 处理

不过需要注意的是 : update 的时候我们需要保证自增所以需要使用 gorm.Expr 来获取数据库运行的值，而不是直接 select-update

缓存处理

对于写入方，优先写入数据库，后写入redis

对于查询方，优选查redis 然后再查数据库

对于写入的过程，因为我们使用的 redis key 是一次缓存了 3个 like,read,collect 三个字段

所以我们自增的时候使用的是 HINCRBY 指令，对于 key 不存在的情况下会有歧义。所以使用 lua 控制了一下仅只有 key 存在的时候才会自增

消息队列

新增统计事件引入 kafka 给阅读、点赞服务解耦

在阅读文章服务，使用 kafka 异步发送，设置 10次每批，1s超时进行聚合发送消息

消费端同样设置 10条每批，1s超时来进行组合消费

每次消费使用一个 map 进行聚合同个biz+biz_id的内容，优化之前一次点赞就需要一次 insert 的操作

并且通过开启事务进行消费，防止 MVCC 中的刷盘操作，将原先要进行10次的刷盘降低到1次。

问题

一致性问题的处理

不处理

从业务上来说，没有必要要求阅读数、点赞数或者收藏数量一定是严格准确的，因为即便不准确，也不会对用户产生什么不好的影响。

更进一步说，只有高并发的文章才会有并发问题。而高并发的文章，阅读数、点赞数或者收藏数本身就很多，你少一点点无所谓。

亮点

大量使用了事务，来保证在同时操作两个表的时候，保持住 ACID 语义。

大量使用了 Upsert 语义 , 因为很多情况下我们都不知道数据库中是否已经存在数据

大量使用 lua 脚本来保证缓存中的数据是正确的, 但是没有彻底解决缓存一致性的问题

在查询接口中，只缓存总数数据，, 并不会缓存个人是否收藏或者点赞的数据。

总分：62 / 100

按「2 年 Go 后端」面试标准看：方向对、有工程意识，但表达粗糙、关键点浅、经不起追问。面试里能撑 15–20 分钟开场，深入一追容易露怯。

分项打分

维度	分数	说明
业务建模与表设计	14/20	通用计数表 + 点赞明细表思路正确，索引方向对
并发与数据正确性	12/20	知道 Upsert / Expr，但 check-then-act、事务边界讲不清
缓存设计	12/20	Cache-Aside + Lua 防空 key 自增有亮点，一致性论证弱
消息队列与解耦	13/20	Kafka 批量、聚合、减刷盘有工程味道
表达与面试叙事	6/10	口语化、错别字多，「大量使用」空洞，像笔记不像口述稿
亮点与深度	5/10	亮点空泛，缺少权衡、失败场景、可观测性

优点

表设计合理：biz + biz_id 抽象通用互动能力，点赞用 (biz, biz_id, uid) 唯一 + status 软删除，符合常见业务。
踩过真实坑：ON CONFLICT + gorm.Expr 自增、Redis HINCRBY 空 key 用 Lua 护栏，说明写过代码而不只是背概念。
有吞吐意识：Kafka 批量生产/消费、按 biz+biz_id 聚合、事务合并刷盘，对 2 年经验来说是加分项。
一致性取舍有业务理由：承认最终一致、高热内容允许误差，比死磕「强一致」更成熟——前提是能讲清边界。

缺点（面试官会盯的）

「不处理一致性」太绝对：面试官会问：DB 成功 Redis 失败？Kafka 重复消费？取消点赞与计数对不上？需要有策略（补偿、对账、幂等），不能只说「少一点点无所谓」。
亮点写法很伤：连续「大量使用事务/Upsert/Lua」像模板，没有场景、没有代价。事务多 ≠ 好，还可能拖慢吞吐。
技术细节易被打穿：
- 写库再写缓存：失败怎么回滚/补偿？
- Lua「仅 key 存在才 incr」：key 不存在时计数会丢吗？靠查询回源还是异步重建？
- Kafka 聚合：幂等键、乱序、部分失败重试怎么做？
- 「防止 MVCC 刷盘」表述不严谨，容易被纠正。
缺个人态查询设计：只说不缓存「是否点赞」，但列表页如何批量查个人态？N+1？位图/本地缓存？没写。
表达与文档质量差：优选/check-dothing、front matter 的 xxxx、标点混乱，会降低「能讲清楚」的印象。

建议（按面试口述改）

改成 STAR 口述结构：背景（互动服务压力）→ 方案（表 + Kafka + Redis）→ 难点（空 key、重复消费）→ 结果（QPS/延迟/错误率，哪怕是压测数字）。
准备 3 个追问标准答：
- DB/Redis 不一致：异步对账 + 定时校准热点 key
- Kafka 至少一次：消费幂等（唯一键 + Upsert）
- 取消点赞：status 翻转 + 计数 GREATEST(cnt-1,0)，防负值
删掉「大量使用」，改成「在点赞写明细+改计数时用事务；计数更新用 Upsert；缓存用 Lua 保证 key 存在才 HINCRBY」。
补一张口述链路：读请求 → Redis Hash → miss 回源 DB 回填；写请求 → DB Upsert →（可选）发 Kafka → 消费者聚合写计数 → 更新缓存。
亮点换成可量化的 2–3 条：例如「批量聚合把热点文章写放大降到约 1/N」「Lua 避免幽灵 key」「个人态与总数分离降低缓存体积」。

面试官一句话结论

材料有「做过互动域」的骨架，适合当提纲；按现在写法直接上面试，深度和表达大概卡在 及格偏上。把一致性策略、幂等、失败路径和口述结构补齐，冲到 75–80 比较现实。

发帖服务 one

Sat, 25 Jul 2026 00:00:00 +0000

简历 preview

简历上 : 设计并实现了一个文章服务

考虑文章的业务属性, 创作者支持保存草稿和发布文章。设计了线上库和制作库两个库表设计。

采用 ESR 原则，考虑会有用户查看自己的文章，用户查看某篇文章详情,以及热榜查看对应时间的文章。设定过了 _create,auth_id . 这两个索引

文章服务支持

制作库保存草稿, 设置隐私文章, 发布制作库内容, 按照 ID 查看文章,或许作者文章列表, 获取发布文章列表

支持 MongoDB 和 OSS 的扩展
设计合理的缓存服务
考虑并发场景

细节

数据库索引设计

主要涉及到的业务有 : 作者查看当前文章，和最近一周的热榜设计

对于作者查看当前文章预计查询是 select from where auth_id = '' and statuts = '' 因此设计了 auth_id 的索引

对于最近一周的热榜设计，因为热榜计算是一个频繁的操作，预计查询是 select from where _create >= now-7week 因此设计了 _create 的索引

数据库并发处理

隐私文章功能 :

需要同步改动制作库和线上库的状态。

系统设计的时候选择的是同库不同表的流程因此采用数据库事务进行一致性处理，对于更新失败的操作进行回滚。从业务角度考虑，就算更新失败了也只是让用户多重试几次。

如果是不同库的情况，可以考虑在接口层面增加多次重试。

发布功能 :

对于发布功能, 线上库存在两个状态,线上没有文章需要create,线上有文章需要 update

防止数据库层面的同一篇文章多次竞态问题使用upsert进行操作。

缓存设计

对于列表接口 :

根据习惯习惯缓存第一页内容,大部分用户只会访问第一页的内容。细节: 缓存之前需要清空文章的content 节省内存资源。

在更新，删除，隐私的接口增加对应的删除缓存的操作。

对于查看detail接口 :

根据用户习惯，往往只会查看列表第一篇文章的内容。因此考虑在拉取列表后，缓存第一篇文章的内容。仅在 content < 1M 的时候进行缓存。缓存设置了一个很短的过期时间，防止浪费。

对于发布接口 :

考虑作者发布文章后就会有人阅读，因此在发布的时候就设置缓存。

其他细节

MongoDB

尝试接入 MongoDB 进行存储文章数据。接入 MongoDB 之后发现，MongoDB 返回的 ID 是 String 类型。破坏了原先接口的定义。因此引入了雪花算法进行对其接口

OSS

接入 OSS，在发布文章之后，对于线上库的文章内容进行优化。线上库不保存文章内容，文章内容全部存储在 OSS 中

对接阅读统计服务

使用 channel + ctxWithTimeout 进行批量发送阅读统计给 MQ。供下游消费

作为 Golang 面试官，我按「2 年经验、能独立负责一个业务模块」的标准，对这份 发帖/文章服务 面试准备稿打分如下。

综合评分：68 / 100

维度	得分	说明
业务理解与架构设计	18/25	制作库/线上库分离思路正确，有业务驱动意识
数据库与索引	12/20	有索引意识，但 ESR 理解偏浅，热榜查询设计不完整
并发与一致性	13/20	提到事务、upsert、重试，但缺少边界与失败场景
缓存设计	14/20	第一页缓存、去 content、失效策略有亮点，缺 key 设计与一致性细节
工程化与 Golang 表达	6/15	几乎无 Go 实现细节，MQ 只一笔带过
面试表达与完整性	5/10	结构尚可，错别字多，placeholder 未填，缺 Q&A 演练

结论：作为 2 年经验候选人，项目经历是真实的、方向也对，但这份准备稿更像「项目笔记摘要」，还不足以支撑 45–60 分钟的深度技术面。能过初筛，若在索引、一致性、缓存、Go 并发等点被追问，容易失分。

优点

1. 业务建模有思考

「制作库 + 线上库」分离是内容类系统的常见做法，能解释：

草稿编辑 vs 线上可读
发布时从制作库同步到线上库

这比只会说「CRUD 增删改查」高一档。

2. 缓存策略贴近真实访问

只缓存第一页 —— 符合大部分用户行为
列表缓存去掉 content —— 说明考虑过内存成本
写操作删缓存 —— 知道 Cache Aside 的基本思路
详情预缓存第一条 + 短 TTL + < 1M 限制 —— 有「预测性缓存」意识

3. 并发场景有触点

发布用 upsert 防竞态
隐私状态双库同步用事务
不同库场景考虑接口层重试

说明不是只写 happy path。

4. 扩展能力有落地

MongoDB 接入 + 雪花 ID 对齐 int64 接口
OSS 存正文、DB 存元数据
channel + ctxWithTimeout 批量发 MQ

有「存储分层 + 异步解耦」的工程感。

缺点

1. ESR 原则理解不准确（高风险扣分点）

文档写「采用 ESR 原则，设计了 _create 和 auth_id 两个索引」。

ESR（Equality / Sort / Range）说的是 复合索引字段顺序，不是两个单列索引。面试官很可能追问：

作者查文章：auth_id = ? AND status = ? → 更合理的是 (auth_id, status) 或 (auth_id, status, ctime DESC)
热榜：ctime >= now-7d 且可能要 status = published → 单列 _create 往往不够，还要考虑排序字段（阅读量、score）

若被问到「为什么不用复合索引」，目前文档撑不住。

2. 热榜设计过于粗糙

now-7week 应为 7 天（笔误会减印象分）
没说明热榜指标（UV、阅读量、点赞、时间衰减）
没说明是实时算还是定时任务 + 缓存
频繁计算却只提 _create 索引，逻辑链不完整

3. 一致性问题讲不深

隐私文章「制作库 + 线上库同步」只说了事务和重试，缺：

同库不同表 vs 跨库：最终一致性怎么做
事务失败后用户看到什么状态
OSS 与 DB 不一致怎么办（DB 更新了，OSS 上传失败）
是否需要 Saga / 补偿 / 幂等键

2 年经验不要求精通分布式事务，但要能讲清 自己的方案边界。

4. 几乎没有 Golang 相关内容

这是 Golang 面试准备，但全文没有：

context 怎么用、超时怎么传
goroutine 泄漏怎么防
errgroup / worker pool 怎么做批量 MQ
接口设计、依赖注入、分层（handler/service/repo）
单元测试、压测数据

channel + ctxWithTimeout 只一句，深度不够。

5. 表达与细节问题

statuts、auth_id/author_id 混用、_create 命名不规范
「习惯习惯」重复
description 仍是 xxxx
相比同系列的 register_login tidy，这篇 没有 Q&A 脱稿演练，面试时容易散

6. 缺少可量化的结果

没有 QPS、P99 延迟、缓存命中率、发布失败率等，「设计合理」缺少说服力。

改进建议

一、把每个技术点补成「STAR + 追问应答」

建议每个模块固定四句话：

背景：为什么这么做
方案：具体怎么实现
取舍：为什么不用别的方案
结果：数据或线上表现

示例（索引）：

作者列表查询是 author_id + status + 按创建时间倒序分页。我用复合索引 (author_id, status, ctime DESC)，遵循 ESR：等值条件在前，排序字段在中间。热榜是近 7 天已发布文章按 score 排序，定时任务每 5 分钟算一次，结果放 Redis ZSet，读路径不走 DB。

二、重点补强 5 个高频追问

追问	建议准备内容
为什么制作库/线上库要分开？	读写隔离、草稿不影响线上、发布可审核
发布接口如何保证幂等？	幂等键、upsert 条件、版本号 / status 机
缓存一致性怎么保证？	key 设计、先更 DB 再删缓存、延迟双删要不要
为什么用 MongoDB？MySQL 行不行？	文档结构、字段变化、大正文；MySQL 可以但 OSS 后 MySQL 更合适
MQ 批量发送失败怎么办？	batch 大小、重试、dead letter、ctx 超时

三、补 Golang 实现细节（至少 3 点）

发布流程：ctx 超时、errgroup 并行写 DB + 上传 OSS
阅读统计：带 buffer 的 worker，select + ctx.Done() 优雅退出
接口层：统一错误码、middleware 鉴权、作者只能改自己的文章

能画一张流程图或贴 20 行核心代码，比纯文字强很多。

四、OSS + DB 一致性单独成段

建议明确：

先发 OSS 还是先写 DB？
发布失败如何回滚 / 清理孤儿文件？
读路径：DB 存 content_url，CDN /cache 怎么处理？

五、参考 `register_login tidy` 的结构改版

那篇有「脱讲稿 + 问题列表 + 标准答法」，这篇建议对齐：

## 30 秒 elevator pitch
## 架构图（制作库/线上库/OSS/缓存/MQ）
## 核心接口（Publish / SaveDraft / SetPrivate / List / Detail）
## 5 个技术亮点（每个 1 分钟）
## 10 个高频面试题 + 参考答案
## 踩坑（MongoDB ObjectId、缓存大对象、双库不一致）

六、修正文档硬伤

统一术语：author_id、status、ctime
修正「7 week」→「7 day」
填满 front matter 的 description
通读去掉错别字

面试官视角的一句话评价

「候选人做过真实的文章发布模块，有制作库/线上库、缓存、OSS、MQ 等完整链路意识；但对索引、一致性、Go 并发和面试表达深度不足。若能在 ESR、发布幂等、缓存 key 设计、双库一致性边界上准备充分，可从『大概做过』提升到『能独立负责』，分数有望到 80+。」

如果你愿意，我可以按面试官口吻，直接把这篇 tidy 文档改成「可背诵版」（含 10 道追问 + 参考答案），或对照 register_login tidy 的结构帮你重写一版。

高可用高扩展高安全的登陆与注册的设计 one

Fri, 24 Jul 2026 00:00:00 +0000

脱讲稿

简介 : 设计并实现了完整的高安全性,高可用,高扩展的登陆与注册服务

自述 :

我给系统设计了一个支持手机号码、微信登陆、邮箱注册的登陆与注册服务。使用长短JWT + Session 控制用户的登陆登出。处理了跨域和限流问题,并且对于手机登陆支持切换云服务商支持 failover 策略。功能拥有完整的链路控制，并且使用 wrk 进行压测。

高安全性 :

做了限流, 手机验证, 设备验证

高可用 :

支持切换多个云服务商

高扩展的 :

基于面向接口编程. 并且采用 DDD 设计支持 repo 层切换多个存储方案，支持 SMS 和微信登陆切换各种服务

问题 1

什么是 Gin 的 middle-ware ？能解决什么问题？

Gin 框架提供的一种 AOP 编程机制, 支持实际业务逻辑前后进行插入额外处理。能够解决以下几类问题

Web治理 : 实现 http 层面的熔断、限流、降级

可观测性 : 可以聚合日志，metrics，tracing

身份的认证与鉴权

什么是跨域问题，怎么解决？

跨域的问题本质是请求发送方和接收方 host 和端口不匹配的问题。对于跨域问题，浏览器会预先发送一个 preflight option方法，询问允许访问的范围。

Gin 框架支持使用 Cros 中间件进行处理跨域问题，设置对应的 allow-origins,allow-headers,allow-method即可

跨域问题需要设置哪些头部？上面的已经回答

什么是 cookie，什么是 session ?

http 本身是无状态协议，为了保护用户的登陆状态，浏览器支持本地存储一个 kv 数据, 这个数据可以理解为 cookie

由于 cookie 的安全性问题，隐私信息一般不存放在 cookie中，因此引入 session 机制

session 机制允许绑定一个 session_id 给前端，具体身份校验逻辑可以存放在后端避免隐私信息泄漏

cookie 和 session 比起来有什么缺点？

cookie 不依赖后端存储，并且本身可以设置一些安全性配置例如 domain,expires,secure

缺点的话就是不允许存放敏感信息，容易丢失

–

Session ID 可以放在哪里？如果Cookie禁用

cookie, header, redis,本地缓存,sql 等各种地方

用户密码加密算法的选取

尽可能选择高安全系数的,不宜破解的。技术选型的时候考虑过 md5,pbkdf2,bcrypt

因为 md5 需要在数据库中额外存储盐值的原因最终选择 bcrypt

使用 wrk 压测的时候，发现密码加密和不加密的情况下性能相差10倍, 但是这是不可避免的

怎么做登陆校验 ?

正确性校验 :

在登陆的时候获取对应的账号和密码，去数据库中查找，并且使用 bcrypt 进行比对正确的话则返回对应的 jwt 用于保护用户状体啊

状态维护:

每次获取对应的短token进行 jwt解析，解析失败则登陆失败

安全性处理:

在 JWT 中维护一个 user-agent字段，每次比对该字段是否相同
使用 Redis 限流控制每次的登陆

刷新 Session 过期时间的几种方案
快要过期的时候刷新 ; 这个可能会有 gap
每次访问都刷新。会频繁的读redis
固定时间刷新，增加 updateAt字段

怎么保护 session_id ?主要还是启用 https协议，设置 cookie 的 secure
怎么做到在session_id 和 jwt-token泄漏之后保护着客户？记录登陆的额外信息
如何保护 Web 服务？针对 IP限流、整个集群限流

这几个问题主要在问题 8 会引申

问题 2

你用 Redis 解决过什么问题？

业务上 :

用来标记某些 handle 是否完成。例如某些需要在全环境修复的任务
分布式锁控制针对于 IP 限流的一些账户创建
Stream 实现的轻量化 mq 队列用于实现异步的消费
存储一些实时性不高的例如快照的信息
使用 Zset 进行热榜功能的排序
使用 Redis 单机线程安全的特性实现限流

你知道 Redis 支持哪些数据结构，用过哪些？用来解决什么问题？

string,list,hash,set,zset . 问题 1 的扩展

各个数据结构的底层实现？

不知道，有对应的 memo 。预计会单独开辟一个文章

当你更新数数据的时候先更新数据库还是先更新缓存，有没有一致性问题

先更新数据库，然后删除缓存。对于更新操作采用 Cahce-Aside 的方式会有一致性问题

我们只有在 Get 操作的时候才会重新写入缓存

(这里说实话，忘记了开发的时候的想法了，创建一个memo处理一下)

如何解决一致性问题

这里主要是 check-do thing 的模型吧。尽可能使用原子操作，例如 lua 或者是 atomic

（同样单独使用 memo 进行处理）

问题 3

什么是依赖注入，如何在 Go 实现依赖注入

依赖注入，就是 A 要调用 B 上面的方法, A 在构造的时候要求传入构造好的 B 而不是自己初始化一个 B 。

通过引入 wire包进行依赖注入

什么是面向接口编程？为什么要面向接口编程？

业务之间组件和组件的通信必须依赖接口。即如果 A 调用 B，那么 B 必须是一个接口。

面向接口编程最主要的一点就是提升扩展性，避免代码堆积。

什么是长短 token ？为什么要用长短两个 token ？

长 token 用于控制短 token 的刷新

短 token 用于进行登陆的校验

长短token的设计是为了安全性，如果只有一个 token 有效期设置的很短用户频繁登陆，很长的话会有安全问题

长短 token 的过期时间应该怎么设置？

根据业务需求和产品经理来判断，长 token 一般会很长例如半年，一个月。短token 可以是 2小时或者是 1天

怎么保证长token的安全性，万一泄漏了怎么办？

携带一些设备信息，例如 user-agent 手机设备号，在对于敏感操作的时候，增加手机号验证

使用 JWT token 怎么退出登陆,使用长短 token 之后怎么退出登陆

增加一个 session_id 进行维护，在 Redis 中维护一个黑名单

扩展问题

Q : 对于系统支持微信、手机号、邮箱注册，数据库表是怎么设计的

A : 对于这三个字段单独设计了唯一索引,我们认为任意一个渠道注册进来就是单独的一个账号

Q : 那么如果我后续想要实现手机号和微信和邮箱是一个账号怎么办

A :

看一下业务层面是否要迁移历史数据

如果不迁移历史数据的话 :

创建部分联合索引加上 _create 限制，保证就新的数据需要遵守该索引
业务层面强制这三类业务注册的时候就一起绑定手机号或者是邮箱

如果要迁移历史数据的话

优先保证内部数据迁移跑完
并且合并多个账户之间的数据。这里可能复杂点预计需要强制用户绑定手机号才可以进行功能操作 xxx
创建索引
改善业务层面的登陆与注册服务

Q : Gin 实现了哪些限流降级熔断

遗留

尝试把 SMS 服务单独在拆一个场景出来，增加异步的内容

可以设置一个同步转异步的容错机制。当第三方不可用的时候，将当前请求存储到数据库中，后续再单独启动一个 gouroutine 异步的发送出去

AI Judge

你现在是 Golang 面试官，下面是一个拥有2年经验的求职者的一个面试准备 。 请你结合现有系统实现 和 xxx.md 给其中的内容进行打分 满分100分，给出 优缺点和建议 。

对照 webook 实现后，这份准备材料按 2 年经验后端面试 标准评分如下。

总分：62 / 100

维度	分数	说明
项目叙事与亮点提炼	14/20	有多通道登录、长短 Token、限流、failover，但「三高」略夸大
与代码一致性	10/15	大方向对，细节与代码不一致，易被追问穿帮
安全与鉴权深度	12/20	知道 bcrypt / JWT / ssid，但机制说不清、有概念混用
Go 工程能力（DI/接口/分层）	12/15	这块相对扎实，和代码匹配
Redis / 中间件深度	7/15	用过什么能说，底层与一致性大量空白
表达与完整度	7/15	错别字多、多题空答、遗留太多

优点

项目选型对得上代码：邮箱密码、短信、微信；长短 JWT + ssid 黑名单；User-Agent 校验；SMS failover；Wire + 接口；Redis 滑动窗口限流；CORS；wrk 压测——这些在仓库里都能找到对应实现。
能讲清楚「为什么做」：长短 Token 的安全/体验权衡、接口便于换 SMS/Repo、bcrypt 有压测体感——比只会背概念强。
扩展题有业务意识：多渠道账号合并、历史数据迁移，这是面试官爱听的「产品 + 工程」题。
工程分层叙事清晰：依赖注入、面向接口，和 wire.go、UserCache 注释里的约束一致。

缺点（面试里会扣分的点）

1. 概念混用，容易被打穿

实际是 JWT 放 Header（x-jwt-token / x-refresh-token）+ Redis users:ssid 黑名单，不是经典 Cookie Session。
Cookie / Session 答得偏教材，和项目实现脱节；面试官一问「你们项目 Session 存在哪」，容易答乱。
「Session ID 可放 redis/本地缓存/sql」把 服务端存储 和 客户端携带位置 混在一起了。

2. 与代码不一致

讲稿说法	代码现实
短 Token 2h / 1 天，长 Token 月/半年	短 30 分钟，长 7 天（`redis_jwt.go`）
设备验证	仅比对 `User-Agent`，不是设备指纹
完整高可用 SMS	有 failover，但 `SendV1` 有逻辑问题；真实多厂商未必接好
DDD	更接近分层 + 接口，不是完整 DDD

短信登录流程本身也不完整：LoginSMS 校验成功后没发 Token，Token 却在 SendLoginSMSCode 里设置——若被问「短信登录时序」，会很难圆。

3. 关键答案有硬伤

bcrypt vs md5：选 bcrypt 主要因为自适应哈希/抗暴力破解，不是「md5 要额外存盐」。bcrypt 自带盐，理由说偏了。
跨域：不只是 host/port，还有 scheme；还缺 Credentials、ExposeHeaders（你们代码里刚好有 ExposeHeaders 暴露 JWT Header）。
缓存一致性：写了「忘了」——2 年经验被问 Cache-Aside / 双写，这是硬伤。
Gin 限流/降级/熔断：空题；项目有限流，没有完整熔断降级，却标题写了「高可用」。

4. 准备完整度不够

Redis 底层、一致性、Gin 治理、遗留 SMS 异步都标了 memo/空答。面试不是写博客进度，空题 = 扣分。

5. 自我包装过满

「完整的高安全性、高可用、高扩展」对学习项目偏重。2 年经验更稳妥的说法是：

练手项目，覆盖多登录方式、长短 Token、限流与 SMS 容错，重点验证接口化扩展。

建议（按优先级）

立刻改讲稿

用代码里的真实数字讲：AT 30min、RT 7 天；退出时 ssid 写入 Redis，TTL 与 RT 对齐。
统一术语：说「JWT + 会话标识（ssid）黑名单」，少说「Session 存在 Cookie」。
删掉或降级「设备验证」：改成「绑定 User-Agent，防简单 Token 盗用，不能防 UA 伪造」。
补齐空题，至少能答 2 分钟：
- Cache-Aside：先写 DB 再删缓存；并发下的短暂不一致
- Redis String/Hash/ZSet 各举一个本项目例子（验证码、用户信息、热榜）
- 限流：滑动窗口；熔断降级诚实说「项目未做，可讲思路」

对着代码能画一张时序图

邮箱登录 → 发 AT/RT → 中间件校验 AT + UA + ssid
Refresh：校验 RT → 查黑名单 → 发新 AT
Logout：ssid 入黑名单

面试官最爱顺着这条链路追问。

主动暴露已知坑（加分）

短信登录时序问题
Failover 主备不均 / SendV1 错误处理
FindOrCreate 主从延迟注释

「我知道问题在哪、怎么改」比「系统很完美」更像有 2 年经验。

表达

错别字（Cros、状体啊、Cahce）和口语化「不知道有 memo」直接改掉；面试可以诚实说「这块我回去补过」，但讲稿里不该留白。

面试官视角的一句话

项目素材够用（约 70 分的料），讲解与掌握大约 55–60 分；合在一起 62。
能过初筛讲项目，但深挖安全、缓存一致性、短信登录细节时风险大。把术语对齐代码、补空题、主动讲缺陷，冲到 75+ 比较现实。

Webook-One on GzzhM

关注 one

简历 preview

流程设计

关注模块

支持的功能

表结构设计

缓存设计

其他细节

难点 & 亮点

缺点

总分：68 / 100

优点

缺点（面试里容易被打穿）

建议（按优先级）

分项参考（面试官视角）

feed one

简历 preview

流程设计

Feed 模块

支持的功能

表结构设计

缓存设计

其他细节

难点 & 亮点

缺点

总分：62 / 100

优点

缺点（面试里容易被打穿）

建议（按优先级）

立刻补齐，面试可讲 3 分钟版

建议你能背下来的追问清单

面试官结论

评论 one

简历 preview

流程设计

评论服务模块

支持的功能

表结构设计

获取评论列表功能设计

其他细节

难点 & 亮点

缺点

总分：68 / 100

分项（满分）

优点

缺点（面试里会被追的）

建议（按优先级）

一句话结论

热榜 one

简历 preview

流程设计

模块设计

难点 & 亮点

缺点

总分：62 / 100

优点

缺点（面试会被卡住的地方）

建议（按面试准备优先级）

面试官视角一句话

搜索 one

简历 preview

流程设计

标签服务 模块

支持功能

表结构设计

缓存设计

插入搜索模块

Es 索引设计

数据插入处理

查询搜索模块

联合 Tag 查询

难点 & 亮点

缺点

总分：61 / 100

优点

缺点（面试里最容易被打穿的点）

建议（按优先级）

面试官一句话结论

打赏 one

标签服务模块

流量控制和性能优化

五、参考 `register_login tidy` 的结构改版