Redis on JasperSao的博客

Go 项目反推：Feed 流系统实战——Feed 流设计

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

承接 Go 项目反推：Feed 流系统实战——数据库与 GORM，这一篇继续拆解 feedsystem_video_go 的核心 Feed 流：从推拉模型到游标分页，再到热榜、关注流、话题流与缓存策略。

什么是 Feed 流

打开抖音/微博，往下刷，不断出来新内容，这就是 Feed 流。

这个项目的 4 种 Feed 流

类型	说明	排序方式
最新视频	全站最新发布的视频	按时间倒序
热榜	最热门的视频	按热度排序
关注流	只看关注的人发的视频	按时间倒序
话题流	某个话题下的视频	按时间倒序

推模型 vs 拉模型

拉模型（这个项目用的）

发视频：只写Video表（不做额外操作）
刷视频：实时查询Video表（拉取数据）

数据流动：用户刷的时候才从 DB 拉。

推模型

发视频：写Video表 + 把视频ID推送到所有粉丝的Feed列表里
刷视频：直接从自己的Feed列表读（不用查DB）

数据流动：发的时候就推给粉丝了，粉丝刷的时候直接读。

推拉结合

普通用户发视频 → 推送给粉丝（粉丝少，推送成本低）
大V发视频 → 不推送，粉丝读的时候实时拉取

对比

	拉模型	推模型	推拉结合
发视频成本	低	高（大V要推给几百万粉丝）	中
刷视频成本	高（每次都要查DB）	低（直接读列表）	中
实时性	实时	略有延迟	中
复杂度	简单	复杂	最复杂
场景	用户量小	用户量大	抖音/微博

这个项目用拉模型，因为是学习项目，用户量小，拉模型简单够用。

游标分页 vs 页码分页

页码分页

第1页：GET /feed?page=1&size=10
第2页：GET /feed?page=2&size=10

对应 SQL：

SELECT * FROM videos ORDER BY create_time DESC LIMIT 5 OFFSET 0 -- 第1页
SELECT * FROM videos ORDER BY create_time DESC LIMIT 5 OFFSET 5 -- 第2页

问题：数据变化时可能重复或漏数据

数据库：[100, 90, 80, 70, 60, 50, 40, 30]

第1页（page=1, size=3）：跳过0条，取3条 → [100, 90, 80]

插入新视频110，数据库变成：[110, 100, 90, 80, 70, 60, 50, 40, 30]

第2页（page=2, size=3）：跳过3条，取3条 → [80, 70, 60]

视频80重复出现了！

为什么？因为 OFFSET 是基于"位置"的，不是基于"数据"的。新视频插入后，原来第 4 个位置的视频 80 变成了第 5 个，但 OFFSET 还是 3，所以又取到了。

游标分页（这个项目用的）

第1页：GET /feed?limit=10
 返回：video_list + next_time=1000

第2页：GET /feed?limit=10&latest_time=1000
 返回：video_list + next_time=900

对应 SQL：

SELECT * FROM videos ORDER BY create_time DESC LIMIT 10
SELECT * FROM videos WHERE create_time < 1000 ORDER BY create_time DESC LIMIT 10

为什么游标分页不会重复？

第1页：WHERE create_time < now() LIMIT 3
 返回 [100, 90, 80]
 next_time = 80的时间

插入110

第2页：WHERE create_time < 80的时间 LIMIT 3
 返回 [70, 60, 50]

没有重复！

游标是基于数据的值（时间），不是位置。新视频插入不影响查询条件。

对比

	页码分页	游标分页
请求方式	page=2	latest_time=1000
数据变化时	可能重复或漏数据	不会重复
SQL	OFFSET 跳过	WHERE 条件过滤
场景	后台管理系统	Feed 流、时间线

游标分页的实现

服务器代码

func (repo *FeedRepository) ListLatest(ctx context.Context, limit int, latestBefore time.Time) ([]*video.Video, error) {
 query := repo.db.WithContext(ctx).Model(&video.Video{}).Order("create_time DESC")

 // 关键：如果有游标，加上WHERE条件
 if !latestBefore.IsZero() {
 query = query.Where("create_time < ?", latestBefore)
 }

 query.Limit(limit).Find(&videos)
 return videos, nil
}

游标怎么生成的

// 取本页最后一条视频的时间作为游标
var nextTime int64
if len(baseVideos) > 0 {
 nextTime = baseVideos[len(baseVideos)-1].CreateTime.UnixMilli()
}

本页最后一条视频的时间 = 下一页的起点。

响应结构

type ListLatestResponse struct {
 VideoList []FeedVideoItem `json:"video_list"`
 NextTime int64 `json:"next_time"` // 游标
 HasMore bool `json:"has_more"` // 还有没有更多
}

完整流程

客户端：GET /feed?limit=10
 ↓
服务器：SELECT * FROM videos ORDER BY create_time DESC LIMIT 10
 ↓
返回：video_list + next_time = 本页最后一条的时间
 ↓
客户端：GET /feed?limit=10&latest_time=next_time
 ↓
服务器：SELECT * FROM videos WHERE create_time < next_time ORDER BY create_time DESC LIMIT 10
 ↓
返回：video_list + next_time = 新的游标
 ↓
...循环，直到 has_more = false

热榜实现

热榜排序算法

query := repo.db.WithContext(ctx).Model(&video.Video{}).
 Order("popularity DESC, create_time DESC, id DESC")

排序规则：热度高的优先，热度相同按时间倒序，时间也相同按 ID 倒序。

热度分数怎么算的

func UpdatePopularityCache(ctx context.Context, cache *rediscache.Client, id uint, change int64) {
 now := time.Now().UTC().Truncate(time.Minute)
 windowKey := cache.Key("hot:video:1m:%s", now.Format("200601021504"))
 member := strconv.FormatUint(uint64(id), 10)

 cache.ZincrBy(opCtx, windowKey, member, float64(change)) // 热度+change
 cache.Expire(opCtx, windowKey, 2*time.Hour)
}

每次点赞/评论/关注，热度+1。

热榜查询流程（冷热分离）

func (f *FeedService) ListByPopularity(ctx context.Context, limit int, reqAsOf int64, offset int, ...) {
 // 1. 确定时间窗口（最近60分钟）
 asOf := time.Now().UTC().Truncate(time.Minute)

 // 2. 生成60个ZSET的key
 keys := make([]string, 0, 60)
 for i := 0; i < 60; i++ {
 keys = append(keys, f.rediscache.Key("hot:video:1m:%s", asOf.Add(-time.Duration(i)*time.Minute).Format("200601021504")))
 }

 // 3. 合并成一个ZSET（快照）
 dest := f.rediscache.Key("hot:video:merge:1m:%s", asOf.Format("200601021504"))
 f.rediscache.ZUnionStore(opCtx, dest, keys, "SUM")

 // 4. 从合并后的ZSET取top N
 members, _ := f.rediscache.ZRevRange(opCtx, dest, start, stop)

 // 5. 根据ID去查视频详情
 videos, _ := f.repo.GetByIDs(ctx, ids)

 return videos
}

快照 key 是什么

快照 key 就是"合并结果的缓存"。

没有快照key：
 用户A请求 → 合并60个ZSET → 返回
 用户B请求 → 合并60个ZSET → 返回
 100个用户请求 → 合并100次 → 浪费！

有快照key：
 用户A请求 → 合并60个ZSET → 存到快照key → 返回
 用户B请求 → 发现快照key已存在 → 直接用 → 返回
 100个用户请求 → 只合并1次 → 省资源！

代码：

dest := f.rediscache.Key("hot:video:merge:1m:%s", asOf.Format("200601021504"))
exists, _ := f.rediscache.Exists(opCtx, dest)
if !exists {
 f.rediscache.ZUnionStore(opCtx, dest, keys, "SUM")
 f.rediscache.Expire(opCtx, dest, 2*time.Minute)
}
members, _ := f.rediscache.ZRevRange(opCtx, dest, start, stop)

快照 key 2 分钟后过期，下次请求重新合并，拿到最新数据。

关注流实现

核心代码

func (repo *FeedRepository) ListByFollowing(ctx context.Context, limit int, viewerAccountID uint, latestBefore time.Time) ([]*video.Video, error) {
 var videos []*video.Video
 query := repo.db.WithContext(ctx).Model(&video.Video{}).Order("create_time DESC")

 if viewerAccountID > 0 {
 // 子查询：找到我关注的所有人
 followingSubQuery := repo.db.WithContext(ctx).
 Model(&social.Social{}).
 Select("vlogger_id").
 Where("follower_id = ?", viewerAccountID)

 // 只查这些人发的视频
 query = query.Where("author_id IN (?)", followingSubQuery)
 }

 if !latestBefore.IsZero() {
 query = query.Where("create_time < ?", latestBefore)
 }

 query.Limit(limit).Find(&videos)
 return videos, nil
}

等价 SQL

SELECT * FROM videos
WHERE author_id IN (
 SELECT vlogger_id FROM socials WHERE follower_id = 123 -- 我关注的人
)
AND create_time < 1000 -- 游标
ORDER BY create_time DESC
LIMIT 10

子查询是什么

子查询就是"查询里的查询"，拆成两步理解：

第1步（子查询）：
 SELECT vlogger_id FROM socials WHERE follower_id = 123
 → 结果：[456, 789]（用户A关注的人）

第2步（主查询）：
 SELECT * FROM videos WHERE author_id IN (456, 789)
 → 结果：视频100（B发的）、视频200（C发的）

子查询是一次 SQL 搞定，数据库内部优化，比两条 SQL 更快。

流程

用户A关注了B和C
 ↓
子查询：从social表找到 [456, 789]
 ↓
主查询：从video表找 author_id 是 456 或 789 的视频
 ↓
返回：视频100（B发的）、视频200（C发的）
 ↓
用户D的视频300不会出现（A没关注D）

话题流实现

核心代码

func (repo *FeedRepository) ListByTag(ctx context.Context, tagName string, limit int) ([]*video.Video, error) {
 var videos []*video.Video
 err := repo.db.WithContext(ctx).Model(&video.Video{}).Table("videos").
 Joins("JOIN video_tags ON video_tags.video_id = videos.id").
 Joins("JOIN tags ON tags.id = video_tags.tag_id").
 Where("tags.name = ?", tagName).
 Order("videos.create_time desc").
 Limit(limit).
 Find(&videos).Error
 return videos, err
}

等价 SQL

SELECT videos.* FROM videos
JOIN video_tags ON video_tags.video_id = videos.id
JOIN tags ON tags.id = video_tags.tag_id
WHERE tags.name = 'Go语言'
ORDER BY videos.create_time DESC
LIMIT 10

三张表的关系

tags表：
┌────┬──────────┐
│ id │ name │
├────┼──────────┤
│ 1 │ Go语言 │
│ 2 │ Python │
└────┴──────────┘

video_tags表（多对多关联）：
┌──────────┬─────────┐
│ video_id │ tag_id │
├──────────┼─────────┤
│ 100 │ 1 │ ← 视频100有"Go语言"标签
│ 100 │ 2 │ ← 视频100也有"Python"标签
│ 200 │ 1 │ ← 视频200有"Go语言"标签
└──────────┴─────────┘

videos表：
┌────┬──────────┐
│ id │ title │
├────┼──────────┤
│ 100 │ Go入门 │
│ 200 │ 并发编程 │
└────┴──────────┘

查询流程

1. 从tags表找到"Go语言"的id = 1
2. 从video_tags表找到tag_id = 1的video_id = [100, 200]
3. 从videos表找到id = [100, 200]的视频

JOIN一次搞定。

三级缓存架构

这个项目在 Feed 查询里用了三级缓存：

请求 → L1本地缓存 → L2 Redis → L3 MySQL
 ↓ 快 ↓ 较快 ↓ 慢
 纳秒级 毫秒级 毫秒级

代码

type FeedService struct {
 localcache *cache.Cache // L1：本地缓存（进程内存，3秒过期）
 rediscache *rediscache.Client // L2：Redis缓存
 repo *FeedRepository // L3：MySQL
}

// L1：本地缓存
localcache: cache.New(3*time.Second, 5*time.Second)

// L2：Redis缓存（50ms超时）
cacheCtx, cancel := context.WithTimeout(ctx, 50*time.Millisecond)

// L3：MySQL
videos, err := f.repo.GetByIDs(ctx, ids)

查询流程

请求来了
 ↓
查L1本地缓存（进程内存）
 ├── 命中 → 直接返回（最快）
 └── 没命中
 ↓
 查L2 Redis（50ms超时）
 ├── 命中 → 写回L1 → 返回
 └── 没命中
 ↓
 查L3 MySQL
 → 写回L2 Redis → 写回L1 → 返回

singleflight 防并发

什么是 singleflight

Go 内置的工具，保证同一个请求只执行一次，其他并发请求等着用结果。

场景

100个用户同时请求热榜
 ↓
没有singleflight：
 用户1：查DB → 返回
 用户2：查DB → 返回
 ...
 用户100：查DB → 返回
 DB被查了100次！

有singleflight：
 用户1：查DB → 返回
 用户2-100：等着 → 用户1查完后直接用结果
 DB只被查了1次！

代码

type FeedService struct {
 requestGroup singleflight.Group
}

v, err, _ := f.requestGroup.Do(sfKey, func() (interface{}, error) {
 return f.repo.GetByIDs(ctx, []uint{videoID})
})

第 1 个请求：执行 func，查 DB
其他请求：同一个 sfKey，等着，拿到同样的结果

sfKey 是什么

请求的唯一标识：

sfKey := f.rediscache.Key("sf:entity:%d", videoID)
// 结果："sf:entity:123"

同一个视频 ID 的请求，sfKey 相同，会共享结果。

和分布式锁的对比

	分布式锁	singleflight
作用范围	多台机器	单机内
实现	Redis	Go 内存
复杂度	高	低
场景	分布式系统	单机内防并发

面试要点总结

Q: 推模型和拉模型的区别？

A: 推是发视频时推送给粉丝，拉是刷视频时实时查 DB。推的读快写慢，拉的读慢写快。抖音用推拉结合。

Q: 游标分页和页码分页的区别？

A: 游标用 WHERE 条件过滤，不会重复；页码用 OFFSET 跳过，数据变化时可能重复。Feed 流用游标分页。

Q: 热榜怎么实现的？

A: ZSET 按分钟分窗口，点赞时热度+1，查询时合并 60 个窗口算总分，快照 key 缓存合并结果。

Q: 关注流怎么实现的？

A: 子查询找关注列表，再查这些人发的视频。一次 SQL 搞定。

Q: 话题流怎么实现的？

A: 三表 JOIN（videos + video_tags + tags），查某个标签下的视频。

Q: 什么是 singleflight？

A: Go 内置工具，保证同一个请求只执行一次，其他并发请求等着用结果。和分布式锁类似，但作用于单机内。

Q: 三级缓存是什么？

A: L1 本地缓存（进程内存）→ L2 Redis → L3 MySQL。先查快的，没命中再查慢的。

Go 项目反推：Feed 流系统实战——Redis 缓存设计

Tue, 28 Jul 2026 00:00:00 +0800

承接 Go 项目反推：Feed 流系统实战——数据库与 GORM，这一篇继续反推 feedsystem_video_go 的 Redis 设计，梳理缓存读写、一致性与高并发防护，以及 Lua 限流和 ZSET 热榜的实现。

项目里 Redis 的 7 种用途

#	用途	数据结构	Key模式
1	JWT Token 缓存	String	`account:<id>`
2	Refresh Token 缓存	String	`account:<id>:refresh` / `refresh:<token>`
3	视频详情缓存	String(JSON)	`video:detail:id=<id>`
4	视频实体缓存	String(JSON)	`video:entity:<id>`
5	热榜	ZSET	`hot:video:1m:<时间窗口>`
6	分片上传会话	String(JSON)	`chunk_upload:<upload_id>`
7	接口限流	String(计数器)	`ratelimit:<prefix>:<subject>`

1. 缓存读取流程（video_service.go 的 GetDetail）

func (vs *VideoService) GetDetail(ctx context.Context, id uint) (*Video, error) {
 cacheKey := vs.cache.Key("video:detail:id=%d", id)

 // 第一步：查缓存（50ms 超时）
 getCached := func() (*Video, bool) {
 opCtx, cancel := context.WithTimeout(ctx, 50*time.Millisecond)
 defer cancel()

 b, err := vs.cache.GetBytes(opCtx, cacheKey)
 if err != nil {
 return nil, false // 缓存没命中
 }
 var cached Video
 if err := json.Unmarshal(b, &cached); err != nil {
 return nil, false // 数据损坏
 }
 return &cached, true // 缓存命中
 }

 // 尝试读缓存
 if v, ok := getCached(); ok {
 return v, nil // 命中，直接返回
 }

 // 缓存没命中，查数据库...
}

为什么缓存读取要设 50ms 超时？

50ms 超时不是判断"没命中"，而是防止 Redis 卡住的降级策略：

缓存没命中：Redis 快速返回"key 不存在"，几毫秒就完成
Redis 卡住：网络抖动、Redis 内部阻塞、连接池耗尽，可能卡几秒

没有超时：Redis 卡住 → 请求一直等着 → 用户体验很差有 50ms 超时：Redis 超过 50ms 没响应 → 放弃缓存 → 直接查数据库

为什么不设更短的超时，比如 5ms？

Redis 正常操作本身需要几毫秒，设 5ms 正常情况都可能超时，缓存形同虚设。50ms 是平衡点：覆盖正常操作 + 轻微网络波动，同时不会让用户等太久。

2. 缓存写入

setCached := func(video *Video) {
 b, err := json.Marshal(video)
 if err != nil {
 return
 }
 opCtx, cancel := context.WithTimeout(ctx, 50*time.Millisecond)
 defer cancel()
 _ = vs.cache.SetBytes(opCtx, cacheKey, b, vs.cacheTTL)
}

为什么缓存要设过期时间（TTL）？

TTL = Time To Live，缓存的"保质期"。

主要原因：数据一致性

09:00 缓存存了视频标题"今天天气真好"
09:05 作者把标题改成"今天下雨了"
 → 数据库更新了，但缓存还是旧的
09:06 用户查这个视频 → 从缓存读到"今天天气真好"
 → 看到的是过期数据

没有 TTL：缓存永远是旧数据，用户看到的和数据库不一致有了 TTL（比如 10 分钟）：最多 10 分钟后缓存自动过期，下次请求加载最新数据

这是用时间换一致性：允许短暂不一致，但最终会一致。

次要原因：缓存空间有限

缓存满了需要淘汰旧数据，TTL 帮助自动清理。

3. 缓存删除（主动失效）

为什么不等 TTL 过期，要主动删缓存？

看 video_service.go 删视频时：

func (vs *VideoService) DeleteVideo(ctx context.Context, id uint) error {
 // 先删数据库
 if err := vs.repo.DeleteVideo(ctx, id); err != nil {
 return err
 }
 // 再删缓存
 if vs.cache != nil {
 cacheKey := vs.cache.Key("video:detail:id=%d", id)
 _ = vs.cache.Del(context.Background(), cacheKey)
 }
 return nil
}

DB 更新后立刻删缓存，下次请求来了缓存没命中，从数据库加载最新数据。

4. 缓存和 DB 的一致性策略

两种方案对比

方案	做法	风险
先删缓存，再更新 DB	删缓存 → 写 DB	删完缓存、还没写 DB 时，另一个请求读 DB 旧数据写入缓存
先更新 DB，再删缓存	写 DB → 删缓存	写完 DB、还没删缓存时，另一个请求读到旧缓存

为什么"先更新 DB 再删缓存"更安全？

方案 1：先删缓存，再更新 DB

00:00 请求A：删缓存
00:01 请求B：查视频 → 缓存没命中 → 从DB读到旧数据 → 写入缓存
00:02 请求A：更新DB为新数据

结果：DB是新数据，缓存里是旧数据（脏数据）

发生概率不低，因为"删缓存"到"更新 DB"之间可能有几百毫秒（DB 写入比 Redis 慢）。

方案 2：先更新 DB，再删缓存

00:00 请求A：更新DB为新数据
00:01 请求B：查视频 → 从缓存读到旧数据（概率小）
00:02 请求A：删缓存

结果：即使请求B读到旧缓存，00:02缓存就被删了

出问题窗口极小：必须在"更新 DB"和"删缓存"之间，恰好有另一个请求来读。

共同风险点：删缓存失败了怎么办？

00:00 更新DB成功 → DB是新数据
00:01 删缓存失败（网络抖动、Redis挂了）
 → 缓存还是旧数据

解决方案：靠 TTL 兜底

代码里删缓存都用了 _ = 忽略错误：

_ = vs.cache.Del(context.Background(), cacheKey)

即使删缓存失败，最多等 TTL 过期（比如 10 分钟），缓存自动失效，下次请求从 DB 加载新数据。

这是最终一致性：允许短暂不一致，但最终会一致。

5. 缓存穿透/击穿/雪崩

三个概念的区别

问题	现象	危害
缓存穿透	查询不存在的数据，缓存永远没命中	每次请求都打到 DB
缓存击穿	热点 key 过期，大量请求同时打到 DB	DB 瞬间压力暴增
缓存雪崩	大量 key 同时过期	DB 瞬间压力暴增

缓存击穿的解法（这个项目用的）

场景：一个热门视频的缓存过期了，100 个用户同时请求

// 缓存没命中，尝试获取分布式锁
lockKey := "lock:" + cacheKey
token, locked, lockErr := vs.cache.Lock(lockCtx, lockKey, 2*time.Second)

if lockErr == nil && locked {
 // 拿到锁：去查DB，回填缓存
 defer func() { _ = vs.cache.Unlock(context.Background(), lockKey, token) }()

 video, err := vs.repo.GetByID(ctx, id)
 if err != nil {
 return nil, err
 }
 setCached(video)
 return video, nil
}

// 没拿到锁：等待别人回填缓存（最多100ms）
for i := 0; i < 5; i++ {
 time.Sleep(20 * time.Millisecond)
 if v, ok := getCached(); ok {
 return v, nil // 别人已经回填了，直接用
 }
}

// 降级：直接查DB
video, err := vs.repo.GetByID(ctx, id)

核心逻辑：让一个请求干活，其他请求等着用结果

❌ 没有锁的击穿场景：
100个请求同时来 → 缓存没命中 → 100个都去查DB → DB压力x100

✅ 有锁的保护：
100个请求同时来 → 缓存没命中
 ↓
请求1：拿到锁 → 查DB → 写缓存 → 返回
请求2-100：没拿到锁 → 等20ms → 查缓存 → 命中 → 返回

时序示例（DB 查询 15ms）：

00:00 请求1拿到锁，开始查DB（耗时15ms）
 请求2-100没拿到锁，开始sleep 20ms
00:15 请求1查完DB，写入缓存
00:20 请求2-100醒来，查缓存 → 命中！

降级策略（DB 查询很慢时）：

请求 2-100 最多等 100ms（5次x20ms），如果请求 1 还没完成，降级去查 DB。

但这种情况很少见，DB 查询通常几毫秒到几十毫秒。

缓存穿透的解法（这个项目没做）

缓存穿透：查询不存在的数据，比如 GET /video/999999999，数据库里没有，每次请求都打到 DB。

方案	做法
缓存空值	查 DB 没结果，也写入缓存（value=""），设短 TTL
布隆过滤器	在缓存前加一层，快速判断 key 是否存在

项目为什么没做：视频 ID 通过 Feed 流返回，不存在"查不存在 ID"的正常场景。接口有限流保护，攻击成本高。

缓存雪崩的解法（这个项目没做）

缓存雪崩：大量 key 同时过期，DB 瞬间压力暴增。

方案	做法
随机 TTL	给缓存 TTL 加随机值，避免同时过期
多级缓存	L1 本地缓存 + L2 Redis 缓存
永不过期 + 异步更新	缓存不设 TTL，由后台任务定期更新

项目用的是固定 TTL，没做随机化，业务量可控。

6. 限流中间件（ratelimit.go）

限流是什么？

防止用户发太多请求打垮服务器。像银行取号机：每分钟最多服务 100 个人，第 101 个人来了告诉他"请稍后再来"。

限流中间件是什么？

Gin 中间件，所有请求都要经过它：

用户请求 → 限流中间件检查 → 通过 → handler处理 → 返回
 ↓
 超限 → 直接返回429 "too many requests"

限流实现原理

func Limit(cache *rediscache.Client, keyPrefix string, maxRequests int64, window time.Duration, keyFunc KeyFunc) gin.HandlerFunc {
 return func(c *gin.Context) {
 subject, ok := keyFunc(c)
 key := buildKey(keyPrefix, subject)

 count, err := cache.IncrementWithExpire(c.Request.Context(), key, window)
 if err != nil {
 c.Next()
 return
 }
 if count > maxRequests {
 c.AbortWithStatusJSON(http.StatusTooManyRequests, gin.H{"error": "too many requests"})
 return
 }
 c.Next()
 }
}

IncrementWithExpire 的 Lua 脚本

local count = redis.call("INCR", KEYS[1])
if count == 1 then
 redis.call("PEXPIRE", KEYS[1], ARGV[1])
end
return count

限流流程（1 分钟内最多 100 次）：

00:00.000 请求1来 → INCR → count=1
 因为count==1，是第一个请求
 → PEXPIRE设60000毫秒（60秒）过期

00:00.001 请求2来 → INCR → count=2
 count!=1，不设过期（沿用之前的）

...

00:00.500 请求100来 → INCR → count=100
 → 通过（100 <= 100）

00:00.600 请求101来 → INCR → count=101
 → 拒绝！（101 > 100）
 → 返回429 "too many requests"

01:00.000 key自动过期，Redis删除这个key
 计数器归零

01:00.001 请求来 → INCR → count=1（重新开始计数）
 → PEXPIRE重新设60秒
 → 通过

为什么用 Lua 脚本？

原子执行 = 两条命令之间不会有其他命令插队

没有 Lua 脚本（可能被插队）：

00:00 你的程序：INCR key → count=1
00:01 另一个程序：INCR key → count=2
00:02 你的程序：EXPIRE key 60秒
00:03 另一个程序：EXPIRE key 60秒

你的 INCR 和 EXPIRE 之间，被别人插队了。

有 Lua 脚本（不会插队）：

00:00 你的程序：开始执行Lua脚本
 INCR key → count=1
 EXPIRE key 60秒
00:01 Lua脚本执行完，其他程序才能执行

注意：原子执行 ≠ 回滚，原子执行 = 不插队

如果 INCR 成功了，EXPIRE 失败了，INCR 的结果不会撤销。

为什么需要原子执行？

如果分开写：

count = redis.INCR(key) // count=1
// 这里程序崩了，EXPIRE没执行
redis.EXPIRE(key, 60秒) // 没执行到

结果：key 永远不过期，计数永远不会归零，限流永久生效。

Lua 脚本保证 INCR 和 EXPIRE 一起执行，不会出现"只执行了一半"的情况。

EXPIRE 和 PEXPIRE

EXPIRE：单位是秒
PEXPIRE：单位是毫秒

限流的 key 设计

func buildKey(keyPrefix, subject string) string {
 return fmt.Sprintf("feedsystem:ratelimit:%s:%s", keyPrefix, strings.TrimSpace(subject))
}

两种维度：

KeyByIP：按 IP 限流，防止单 IP 攻击
KeyByAccount：按用户 ID 限流，防止单用户刷接口

7. ZSET 热榜（popularity_cache.go）

ZSET 是什么？

Redis 的有序集合，每个元素有一个分数，自动按分数排序。

ZSET "热榜"
┌─────────┬─────────┐
│ 元素 │ 分数 │
├─────────┼─────────┤
│ video_5 │ 1000 │ ← 最热
│ video_2 │ 800 │
│ video_8 │ 500 │
│ video_1 │ 100 │ ← 最冷
└─────────┴─────────┘

热榜更新代码

func UpdatePopularityCache(ctx context.Context, cache *rediscache.Client, id uint, change int64) {
 // 删掉旧缓存
 _ = cache.Del(context.Background(), cache.Key("video:detail:id=%d", id))
 _ = cache.Del(context.Background(), cache.Key("video:entity:%d", id))

 // 写入热榜
 now := time.Now().UTC().Truncate(time.Minute) // 当前时间，精确到分钟
 windowKey := cache.Key("hot:video:1m:%s", now.Format("200601021504")) // 热榜key
 member := strconv.FormatUint(uint64(id), 10) // 视频ID

 _ = cache.ZincrBy(opCtx, windowKey, member, float64(change)) // 热度+change
 _ = cache.Expire(opCtx, windowKey, 2*time.Hour) // 2小时后过期
}

滑动窗口设计

热榜 key 是 hot:video:1m:202607281430，意思是"2026 年 7 月 28 日 14:30 这一分钟的热榜"。

00:00 video_5被点赞 → hot:video:1m:202607281430 → video_5分数+1
00:30 video_5又被点赞 → hot:video:1m:202607281430 → video_5分数+1
01:00 新的一分钟 → hot:video:1m:202607281431

每分钟一个 ZSET，2 小时后自动过期。

为什么要按分钟分窗口？

如果用一个大的 ZSET（不分窗口）：

所有点赞都写到同一个key "hot:video"

1月1日：video_5被点赞1000次，分数=1000，排第一
1月2日：video_8被点赞500次，分数=500
1月3日：video_5被点赞0次，但分数还是1000，还是排第一

问题：旧视频的热度永远不衰减，新视频永远追不上。

按分钟分窗口：

每分钟一个ZSET：

hot:video:1m:202607281430 → 14:30这一分钟的热度
hot:video:1m:202607281431 → 14:31这一分钟的热度
hot:video:1m:202607281432 → 14:32这一分钟的热度

查热榜时，把最近几个窗口合并：

14:35查热榜：
→ 合并 14:30、14:31、14:32、14:33、14:34、14:35 这6个窗口
→ 算总分，排序

好处：

14:30 的热度，到 14:35 时已经衰减了（只有 1/6 权重）
14:35 新产生的热度立刻反映
热榜是"最近几分钟"的热度，不是"历史累计"

ZSET 常用操作

// 分数增加
cache.ZincrBy(ctx, key, member, score)

// 按分数倒序取 top N
cache.ZRevRange(ctx, key, 0, 99) // 取前100名

// 合并多个ZSET
cache.ZUnionStore(ctx, dst, keys, "SUM")

// 设置过期时间
cache.Expire(ctx, key, 2*time.Hour)

面试要点总结

Q: 缓存和 DB 的一致性怎么保证？

A: 先更新 DB，再删缓存。删缓存失败靠 TTL 兜底，最终一致性。

Q: 缓存穿透/击穿/雪崩的区别和解法？

A: 穿透是查不存在的数据（缓存空值/布隆过滤器），击穿是热点 key 过期（分布式锁 + 等待重试），雪崩是大量 key 同时过期（随机 TTL）。

Q: 限流怎么实现的？

A: Redis 计数器，Lua 脚本原子执行 INCR + PEXPIRE，超限返回 429。

Q: 为什么用 Lua 脚本？

A: 保证 INCR 和 EXPIRE 原子执行，不会被其他命令插队，避免"只执行了一半"的问题。

Q: 热榜怎么实现的？

A: ZSET 按分钟分窗口，点赞时 ZincrBy 加分数，查热榜时合并最近几个窗口算总分。分窗口实现热度自动衰减。

Go 项目反推：Feed 流系统实战——认证体系

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

承接 Go 项目反推：Feed 流系统实战——请求生命周期，这一篇继续反推 feedsystem_video_go 的认证代码，梳理 JWT、Refresh Token、Token 撤销，以及软硬鉴权中间件之间的关系。

一、jwt.go 文件结构

文件位置：internal/auth/jwt.go

jwtSecret() → 获取密钥
Claims → Token 里存什么
GenerateToken() → 生成 accessToken（JWT 格式，15 分钟）
GenerateRefreshToken() → 生成 refreshToken（随机字符串）
ParseToken() → 验证 Token（签名 + 过期）

二、密钥与 Claims

jwtSecret()：获取密钥

优先使用环境变量 JWT_SECRET，没有就随机生成：

JWT_SECRET=*** go run ./cmd

如果没有设置环境变量，每次服务器启动时密钥都会改变，之前签发的 Token 将全部失效，所有用户都要重新登录。因此正式环境必须设置稳定且足够随机的 JWT_SECRET。

Claims：Token 里存什么

type Claims struct {
 AccountID uint // 用户 ID
 Username string // 用户名
 jwt.RegisteredClaims // 标准字段（过期时间、签发时间等）
}

可以把 Claims 类比为一张有有效期的身份证，上面记录用户名、用户 ID、签发时间和过期时间。

需要注意：JWT Payload 只是经过 Base64URL 编码，并不是加密，客户端也能读取其中的内容。因此 Claims 里不能放密码、密钥等敏感数据。

三、生成 Token

GenerateToken()：生成 accessToken

1. 创建 Claims，写入用户 ID、用户名和 15 分钟后的过期时间
2. 使用 HS256 算法创建 Token 对象
3. 使用 JWT Secret 签名，生成 Token 字符串

结果是一串类似 eyJhbG...xxxx 的 JWT。它内部包含经过编码的 Header 和 Payload，以及用于防止内容被篡改的签名。

HS256 只负责签名和验签，不负责加密。其他人虽然可以读取 Payload，但没有 JWT_SECRET 就无法生成有效签名。

GenerateRefreshToken()：生成 refreshToken

Refresh Token 和 Access Token 完全不同：

accessToken → JWT 格式，携带 Claims，并使用密钥签名
refreshToken → 随机字符串，本身不携带用户信息

项目使用 32 个随机字节，再转换为 64 位十六进制字符串。Refresh Token 不需要携带 Claims，它只需要成为一个难以猜中的长期凭证。

双 Token 时间设定

accessToken 15 分钟：泄露后的可利用时间较短
refreshToken 7 天： 用于换取新的 Access Token，减少重复登录

Access Token 有效期短，降低泄露风险；Refresh Token 有效期长，保证使用体验。二者配合，在安全性和便利性之间取得平衡。

四、验证 Token

ParseToken()：验证 Token

输入：客户端发送的 Token 字符串
输出：Claims（用户 ID、用户名）或错误

流程：

1. 解析 Token
2. 确认签名算法是 HS256
3. 使用 JWT Secret 验证签名
4. 检查 Token 是否过期
5. 全部通过 → 返回 Claims
6. 任一失败 → 返回错误

这里不是“解密 Token”，因为 JWT Payload 没有被加密。服务器做的是解析内容并验证签名。

还需要注意：ParseToken() 只检查格式、签名和过期时间，不检查 Token 是否已被撤销。

五、Refresh 流程

Access Token 过期后，可以使用 Refresh Token 换取新的 Access Token：

客户端：Access Token 过期，这是 Refresh Token，请签发新的 Access Token

服务器：
 1. 使用 Refresh Token 查询 Redis 中的 refresh:<token>
 2. 查询成功后得到 accountID
 3. 查询数据库，确认 Refresh Token 与账户记录匹配
 4. 生成新的 Access Token
 5. 将新 Token 写入数据库和 Redis
 6. 返回给客户端

可以类比为：短期门禁卡过期后，使用长期凭证到前台换一张新卡。

关键点是：使用 Refresh Token 换取 Access Token，而不是反过来。

六、Token 撤销

JWT 的签名和过期时间一旦确定，单靠 ParseToken() 无法让一个尚未过期的 Token 提前失效。因此项目额外在 Redis 和 MySQL 中保存当前有效 Token。

登出时删除旧 Token：

删除 Redis 中的三个 Key：
 account:<id> → accessToken
 account:<id>:refresh → refreshToken
 refresh:<token> → accountID

清空 MySQL 中的字段：
 token
 refresh_token

删除后，即使旧 JWT 的签名正确且尚未过期，中间件也无法在 Redis 或 MySQL 中匹配到它，因此会拒绝请求。

修改密码时也可以使用相同思路：

清空旧 Token
→ 签发新 Token
→ 让其他设备上的旧登录状态立即失效

七、JWTAuth 中间件

文件位置：internal/middleware/jwt/jwt.go

处理流程：

1. 从请求头读取 Authorization
2. 检查格式是否为 Bearer <token>
3. 调用 auth.ParseToken() 验证格式、签名和过期时间
4. 调用 check() 检查 Token 是否仍是当前有效 Token
5. 验证通过后将用户信息写入 Gin Context

客户端发送：

Authorization: Bearer ***

check()：为什么同时查询 Redis 和 MySQL

第一步：查询 Redis
 查到 → 对比请求 Token 是否为当前有效 Token
 相同 → 放行
 不同 → 拒绝，Token 已被替换或撤销

 Redis 未命中或不可用 → 查询 MySQL

第二步：查询 MySQL
 查到账户 → 对比数据库保存的 Token
 相同 → 放行，并回填 Redis
 不同 → 拒绝

Redis 是缓存，速度快但可能未命中或不可用；MySQL 是持久化的数据来源，可以作为兜底。MySQL 本身也可能发生故障，因此更准确的说法是“Redis 失败时降级查询 MySQL”，而不是“MySQL 永远可用”。

check() 主要完成两件事：

将请求中的 Token 与服务器保存的当前 Token 对比，判断是否已被撤销
将用户信息写入 gin.Context，方便后续 Handler 使用

八、两种鉴权

JWTAuth（硬鉴权）：
 没有 Token 或 Token 无效 → 拒绝请求

SoftJWTAuth（软鉴权）：
 没有 Token → 继续放行
 有 Token且有效 → 识别用户身份后放行

项目中的使用示例：

JWTAuth（必须登录）：
 /logout
 /rename
 /uploadAvatar

SoftJWTAuth（不强制登录）：
 /feed/listLatest
 /feed/listByPopularity

用户没有 Token 也能浏览 Feed；携带有效 Token 时，系统可以识别用户并提供个性化结果。

可以类比为：

JWTAuth → 会员俱乐部，没有会员卡不能进入
SoftJWTAuth → 商场，没有会员卡也能进入，有会员卡则能获得个性化服务

九、面试要点

JWT 如何生成：Claims + HS256 + JWT Secret 签名
JWT 不等于加密：Payload 可以读取，签名用于防篡改
双 Token：短期 Access Token + 长期 Refresh Token
Refresh 流程：使用 Refresh Token 换取新的 Access Token
Token 撤销：清理 Redis 与 MySQL 中保存的 Token，使旧 JWT 立即失效
中间件 check()：优先查询 Redis，未命中或不可用时查询 MySQL
两种鉴权：JWTAuth 强制登录，SoftJWTAuth 允许匿名访问

这一套设计实际上让 JWT 从“完全无状态”变成了“带服务端状态的认证方案”。它牺牲了一部分无状态带来的简单扩展能力，换取了主动登出、修改密码后强制失效和单会话控制等能力。

Go 项目反推：Feed 流系统实战——请求生命周期

Tue, 21 Jul 2026 00:00:00 +0800

承接 Go 项目反推：Feed 流系统实战——从 Docker 到开源贡献，这一篇继续反推 feedsystem_video_go 的后端代码。这次不再从整体架构看项目，而是以 POST /account/login 为例，追踪一个请求从进来到返回的完整路径。

路由基础

router.go 是什么

router.go = 路由表 = “地址簿”。它告诉服务器：什么方式 + 访问哪个路径 → 转发到哪个函数。

POST /account/login → accountHandler.Login
POST /account/register → accountHandler.CreateAccount
GET /healthz → 返回 {"status":"ok"}

类比：router.go 是前台接待（“办 login 业务找张三”），handler.go 是张三的工位（“我来处理”）。

路由组

accountGroup := r.Group("/account")

创建一个路由组，前缀是 /account。组里的所有路由，路径前面自动加上前缀：

accountGroup.POST("/login", ...) → 实际路径 POST /account/login
accountGroup.POST("/register", ...) → 实际路径 POST /account/register

类比：把用户相关接口都放在 /account 这个“文件夹”下。

路由注册

accountGroup.POST("/login", loginLimiter, accountHandler.Login)

三个参数：

"/login" → 路径（拼上 /account，变成 /account/login）
loginLimiter → 限流中间件（先过这一关）
accountHandler.Login → 最终处理请求的函数（过了限流才到这里）

请求流程：

POST /account/login 进来
 ↓
loginLimiter（限流中间件）
 ↓
accountHandler.Login（handler 处理）

函数引用 vs 函数调用

accountGroup.POST("/login", loginLimiter, accountHandler.Login)

accountHandler.Login 是函数本身，不是调用。Go 里函数可以当变量传来传去，和 CS61A 的高阶函数一个意思：

accountHandler.Login → 函数本身（把函数“交给”路由器，等有人请求时再调用）
accountHandler.Login(c) → 调用函数（立刻执行）

类比：给你一张纸条写上张三的电话号码（函数引用） vs 现在立刻拨打电话（函数调用）。

现在不执行，等有人发 POST /account/login 时，路由器才会调用 Login(c) 并传入请求信息。

三层架构

结构创建

router.go 第 40-42 行：

accountRepository := account.NewAccountRepository(db)
accountService := account.NewAccountService(accountRepository, cache)
accountHandler := account.NewAccountHandler(accountService)

创建三个“工人”：

Repository → 操作数据库的人（查表、写表）
Service → 处理业务逻辑的人（校验密码、生成 Token）
Handler → 接收请求的人（解析参数、返回结果）

依赖关系：db → Repository → Service → Handler → 路由

类比：先招档案员（Repository）给数据库钥匙，再招业务员（Service）管档案员，再招前台（Handler）对接业务员，最后门口挂牌子（路由）：“办 login 业务找前台”。

Handler 结构体

type AccountHandler struct {
 accountService *AccountService
}

func NewAccountHandler(accountService *AccountService) *AccountHandler {
 return &AccountHandler{accountService: accountService}
}

AccountHandler 是一个结构体，里面有一个字段 accountService。NewAccountHandler 创建这个结构体并把 Service 存进去。

分层的意义

handler 只管：解析请求 → 调用 service → 返回结果
service 处理：校验密码 → 生成 Token → 写数据库
repo 处理： 操作数据库

handler 不关心密码怎么校验、Token 怎么生成，它只管“调用 service”。

文件目录结构

internal/http/router.go → 路由目录，负责“找谁”
internal/account/handler.go → 用户模块，负责“怎么干”
internal/account/service.go → 用户模块，负责“核心逻辑”
internal/account/repo.go → 用户模块，负责“操作数据库”

按模块分目录：account 目录下放所有跟用户相关的代码，video 目录下放所有跟视频相关的代码。

Handler 层：Login 函数

handler.go 第 116-133 行：

func (h *AccountHandler) Login(c *gin.Context) {
 var req LoginRequest // 声明容器
 if err := c.ShouldBindJSON(&req); err != nil { ... } // 解析 JSON
 account, err := h.accountService.FindByUsername(...) // 查数据库存不存在
 accessToken, refreshToken, err := h.accountService.Login(...) // 校验密码+生成Token
 c.JSON(200, LoginResponse{Token, RefreshToken, ...}) // 返回给客户端
}

完整流程：

1. 解析客户端发的 JSON（用户名、密码）
2. 去数据库查这个用户存不存在
3. 存在的话，让 service 校验密码、生成 Token
4. 把 Token 返回给客户端

ShouldBindJSON

c.ShouldBindJSON(&req)

把客户端发的 JSON 解析到 req 变量里。客户端发 {"username": "zhangsan", "password": "***"}，解析后 req.Username = "zhangsan"，req.Password = "123456"。

ShouldBindJSON vs json.NewDecoder：两个干的事一样，都是把 JSON 解析到变量里。c.ShouldBindJSON(&req) 是 Gin 封装的一行搞定；json.NewDecoder(r.Body).Decode(&req) 是原生写法，要三行还要检查 err。类比：自动挡 vs 手动挡。

Service 层：Login 函数

handler 调用 service 的 Login：

accessToken, refreshToken, err := h.accountService.Login(c.Request.Context(), req.Username, req.Password)

service.go 的 Login 做了 6 件事：

1. 查数据库拿用户信息（FindByUsername）
2. bcrypt 校验密码
3. 生成 accessToken 和 refreshToken
4. Token 存进 MySQL（调用 repo.Login）
5. Token 存进 Redis（3 个 key）
6. 返回两个 Token

ctx（context）

ctx = 请求的“身份证”，带着两个信息：

超时时间：这个请求最多等多久
取消信号：客户端断开了，别再查了

每一层都要传 ctx，这样整条链路都能感知到“客户端还在不在”。

类比：你去饭店点菜，等了 5 分钟走了。没有 ctx → 厨师还在炒，炒完发现你走了，菜倒掉。有 ctx → 服务员告诉厨师“客人走了”，厨师立刻停手。

bcrypt 校验密码

bcrypt.CompareHashAndPassword([]byte(account.Password), []byte(password))

传入两个参数：数据库里存的加密密码（哈希）和用户这次输入的明文密码。bcrypt 把明文密码加密，和数据库里的对比，一样返回 nil（成功），不一样返回 error（失败）。

为什么不存明文？数据库被黑了，黑客拿到的是加密字符串，反推不出原始密码。

[]byte() = 把字符串转成字节数组，bcrypt 只接收这种格式。

双 Token（JWT）

登录成功返回两个 Token：

accessToken → 短期有效（15分钟），用来证明“我是谁”
refreshToken → 长期有效（7天），用来续期 accessToken

为什么两个？只用一个 token 的问题：设太短 → 用户每 15 分钟重新登录，体验差；设太长 → 被偷了就一直能用，不安全。双 token 解决了这个问题：accessToken 短，被偷了也很快过期；refreshToken 长，用户不用频繁登录；accessToken 过期了，用 refreshToken 换新的。

类比：accessToken = 门禁卡（每天过期，重新刷卡续期），refreshToken = 身份证（长期有效，门禁卡丢了拿身份证补办）。

Token 根据用户信息生成（不是纯随机）：

accessToken → 包含用户ID + 用户名 + 过期时间（15分钟）
refreshToken → 只包含用户ID + 过期时间（7天）
用密钥加密生成一串乱码字符串

为什么有 ID 又有用户名

ID（account.ID） → 数据库主键，不可变，用来精确查找
用户名（username）→ 可以改，用来方便识别

类比：身份证号（ID）不可变，查账户用；姓名（username）可以改，写在凭证上让人看。生成 Token 时两个都存：ID 用来查人，用户名用来识别。

Repo 层：Login 函数

service 调用 repo 把 Token 存进 MySQL：

as.accountRepository.Login(ctx, account.ID, accessToken, refreshToken)

repo.go 里用 GORM 操作数据库：

ar.db.WithContext(ctx).Model(&Account{}).Where("id = ?", id).Updates(
 map[string]interface{}{"token": token, "refresh_token": refreshToken})

翻译：在 account 表里，找到 id 等于 id 的那一行，更新 token 和 refresh_token。

等价 SQL：

UPDATE account SET token = 'xxx', refresh_token = 'yyy' WHERE id = 1;

GORM = 用 Go 代码描述“我要干什么”，GORM 帮你翻译成 SQL。

Redis 缓存

登录成功后，Token 存两份：

MySQL 存一份 → 保险，重启不丢，但慢
Redis 存一份 → 快，验证时直接查这里

Redis 存了 3 个 key：

key: "account:1" → accessToken TTL 24小时
key: "account:1:refresh" → refreshToken TTL 7天
key: "refresh:xxxxx" → accountID TTL 7天

为什么存 3 个？第 1 个验证 Token 时查，第 2 个刷新 Token 时查，第 3 个用 refreshToken 反查用户 ID。

Redis 不可用时降级：跳过缓存，只靠 MySQL，功能不丢，只是慢一点。

中间件

怎么执行的

中间件 = 挡在 handler 前面的一道关卡。两个关键函数：

c.Next() → 放行，让请求继续走到下一个中间件或 handler
c.Abort() → 拦截，不让请求继续走，handler 不会执行

类比：c.Next() = 安检通过，放你进去；c.Abort() = 安检不过，拦住你。

为什么是两层函数

func Limit(cache, name string, ...) gin.HandlerFunc { // 外层：传配置
 return func(c *gin.Context) { // 内层：处理请求
 c.Next()
 }
}

外层传配置，内层处理请求。外层函数执行一次，创建中间件；内层函数每次有人访问都执行一次。

类比：外层 = 装修奶茶店（执行一次，买机器、买原料）；内层 = 每天营业（执行无数次，客人来了做奶茶）。

gin.HandlerFunc = Gin 要求中间件必须是这种格式的函数。

gin.Context 的数据传递

中间件把用户 ID 塞进 c 里：

c.Set("accountID", accountID) // 中间件：往 c 里存

handler 从 c 里取出来：

value, exists := c.Get("accountID") // handler：从 c 里取

c 就是一个“传话筒”，中间件往里塞东西，handler 从里拿东西。c 是临时对象，只活在一次请求里，请求结束就没了，不会存到 Redis。

类比：安检员检查完证件，在你手上盖个章“1号”（中间件 c.Set）；柜员看你手上的章，知道你是“1号”（handler c.Get）。

错误到 HTTP 状态码的映射

ClassifyHTTPStatus 就是一张对照表：

error 类型 → 状态码 → 含义
nil（没错误） → 200 → 成功
ErrUnauthorized（未登录） → 401 → 未授权
ErrValidation（参数错误） → 400 → 请求格式错
gorm.ErrRecordNotFound（查不到）→ 404 → 资源不存在
其他错误 → 500 → 服务器内部错误

handler 里用法：

c.JSON(apierror.ClassifyHTTPStatus(err), gin.H{"error": err.Error()})

翻译：看一眼 error 是什么类型，返回对应的状态码。

1. 用户发 POST /account/login

2. router.go 找到这条路由，先过 loginLimiter（限流中间件）

3. 进入 handler.go 的 Login 函数：
 - 解析 JSON（拿到 username 和 password）
 - 调用 service.FindByUsername（查用户存不存在）
 - 调用 service.Login（校验密码 + 生成 Token）

4. 进入 service.go 的 Login 函数：
 - 再查一次数据库（拿到密码哈希）
 - bcrypt 校验密码
 - 生成 accessToken 和 refreshToken
 - 调用 repo.Login（把 Token 存 MySQL）
 - 把 Token 存进 Redis（3 个 key）

5. 进入 repo.go 的 Login 函数：
 - 用 GORM 把 Token 写进 account 表

6. Token 一层一层返回：repo → service → handler → 客户端

涉及 4 个文件：

router.go → 注册路由，把路径和函数连起来
handler.go → 解析请求，调用 service
service.go → 校验密码，生成 Token，存数据库和缓存
repo.go → 操作 MySQL

涉及 2 个存储：

MySQL → 存用户信息和 Token（持久化，重启不丢）
Redis → 缓存 Token（快，重启会丢）

Go 项目反推：Feed 流系统实战——从 Docker 到开源贡献

Sun, 19 Jul 2026 00:00:00 +0800

承接 Go 语言基础：从变量到指针、Go 语言进阶：方法、接口与错误处理、Go 语言工程化：模块管理与项目结构、Go 语言并发：从 Goroutine 到 Worker Pool 和 Go Web 开发：从 net-http 到 Gin，这一篇跳出语法学习，反推一个真实的开源项目——feedsystem_video_go（279 star，Go + Vue 3 短视频 Feed 流系统），从跑通项目到提交 PR，走一遍完整的工程实战。

项目概览

这个项目是一个短视频 Feed 流系统，技术栈：

后端：Go + Gin + GORM + RabbitMQ + Redis
前端：Vue 3 + TypeScript
基础设施：Docker Compose 编排 MySQL、Redis、RabbitMQ

核心功能包括用户注册登录、视频发布、点赞评论、关注取关、Feed 流推送。架构上采用 API + Worker 的消息队列模式。

Docker Compose：启动基础设施

项目的三个"帮手"——MySQL、Redis、RabbitMQ——通过 Docker Compose 一键启动：

cd ~/dev/projects/feedsystem_video_go
docker compose up -d mysql redis rabbitmq

docker compose up — 根据 docker-compose.yml 启动服务
-d — 后台运行（detach），不占终端窗口
mysql redis rabbitmq — 只启动这三个，不启动 backend/worker/frontend

镜像 vs 容器

Docker 里有两个核心概念：

镜像 = 打包好的集装箱（里面有程序 + 配置），是静态文件
容器 = 集装箱正在运行的实例

类比：.app 文件是镜像，双击打开后正在运行就是容器。

端口映射

MySQL 默认端口 3306，但本机可能已经装了 MySQL 占用了 3306。所以 docker-compose.yml 里写的是：

ports: "3307:3306"

意思是：外部访问 3307 → 转发到容器内部的 3306。就像你家门牌号是 3307，但内部房间编号是 3306。项目配置文件里写的也是 3307，Go 程序连接 MySQL 时用的就是 3307。

通过 docker compose ps 可以查看所有容器的运行状态：

NAME IMAGE STATUS PORTS
feedsystem_video_go-mysql-1 mysql:8.0 Up 5 minutes (healthy) 0.0.0.0:3307->3306/tcp
feedsystem_video_go-redis-1 redis:7-alpine Up 5 minutes (healthy) 0.0.0.0:6379->6379/tcp
feedsystem_video_go-rabbitmq-1 rabbitmq:3 Up 5 minutes (healthy) 0.0.0.0:5672->5672/tcp

0.0.0.0 表示"接受任何来源的连接"，即对外部开放。

启动 Go 后端

基础设施就位后，启动后端：

cd backend
CONFIG_PATH=configs/config.compose-local.yaml go run ./cmd

CONFIG_PATH=... — 告诉程序用哪个配置文件（里面写好了 MySQL 3307、Redis 6379、RabbitMQ 5672 的地址）
go run ./cmd — 编译并运行 cmd/main.go 入口程序

日志解读

启动后会看到几段日志：

第一段：依赖下载

go: downloading github.com/gin-gonic/gin v1.11.0
go: downloading gorm.io/gorm v1.31.1

Go 在下载第三方库，类似 npm install，下载一次以后就不需要了。

第二段：连接建立

Loading config from configs/config.compose-local.yaml
Redis connected (cache enabled)
RabbitMQ connected

注意没有 “MySQL connected”，因为 GORM 连接 MySQL 是在后面 AutoMigrate 时才真正连接。

第三段：Gin 路由注册

[GIN-debug] GET /healthz
[GIN-debug] POST /account/register
[GIN-debug] POST /account/login
[GIN-debug] POST /video/publish
[GIN-debug] POST /like/like
[GIN-debug] POST /feed/listLatest

格式是 HTTP方法路由路径，后面的 (4 handlers) 表示这条路由经过几个中间件（如限流 + JWT 鉴权 + 业务处理）。

第四段：消息队列

DLX ready: exchange=dlx.events queue=like.events.dlx
Timeline consumer 已启动, queue=video.timeline.update.queue

DLX = Dead Letter Exchange（死信队列），专门处理失败的消息。

第五段：启动完成

Server is running on port 8080

为什么不把 Go 也放进 Docker？

Docker 适合最终部署，不适合日常开发调试。本地直接 go run 的好处：

日志直接打印在终端，实时可见
改了代码立刻能跑，不用重新打包镜像
出错了能直接看到报错信息

日志不是中间件

日志是 Go 标准库 log 包写出来的，是程序员手动写的"程序进行到哪一步了"的提示。中间件是处理请求的"关卡"，两者没有关系。

核心概念：缓存与消息队列

Redis 缓存

缓存 = 把经常用的数据放在"取用更快的地方"。

类比：冰箱里有水（MySQL，容量大但取用慢），你拿了一瓶放在桌上（Redis 缓存，取用极快），下次喝水直接从桌上拿，不用再去冰箱。

代码里 cache enabled 表示数据会先从 Redis 取，取不到再去 MySQL。

RabbitMQ 消息队列

消息队列是 API 和 Worker 之间的"传话筒"。API 处理完核心逻辑后，把"后续要做的事"发到队列，Worker 从队列里取任务执行。

前后端分离架构

后端和前端是两个完全不同的程序：

后端：Go 写的，负责业务逻辑、读写数据库，监听 8080 端口
前端：Vue 写的，负责页面展示、用户交互，监听 5173 端口

它们通过 HTTP 请求通信：用户在浏览器点"登录" → 前端发请求到 localhost:8080/account/login → 后端处理 → 返回结果 → 前端展示。

就像餐厅里厨房（后端）和前厅（前端）是两个地方，前厅接到顾客点单传给厨房，厨房做完菜传给前厅。

前端用 npm（Node Package Manager）管理依赖，跟 Go 的 go get、Python 的 pip install 是同一个道理：

cd frontend
npm install # 下载依赖
npm run dev # 启动开发服务器

Worker 进程模式

这是整个项目最核心的架构设计。Worker 是一个独立进程，和 API 分开启动：

cd backend
CONFIG_PATH=configs/config.compose-local.yaml go run ./cmd/worker

为什么要分开？

想象一个外卖平台：

方案 A：一个人又要接单又要送餐 — 接单时有新订单没人接，送餐时又有新订单没人接，效率低。

方案 B：两个人分工 — 前台专门接单（API），骑手专门送餐（Worker），前台接完单把订单放进"待送餐队列"（RabbitMQ），骑手从队列里取订单去送。

对应到项目：

角色	职责
API 进程	接收用户请求（点赞、评论、发布视频），处理核心业务逻辑，把"后续要做的事"发到消息队列
Worker 进程	监听消息队列，处理异步任务：更新点赞数、计算热度、推送通知

这个项目有四个 Worker：

LikeWorker — 处理点赞/取消点赞事件
PopularityWorker — 更新视频热度
SocialWorker — 处理关注/取关事件
CommentWorker — 处理评论事件

分开的好处

性能：用户点赞时，API 只需要返回"点赞成功"，不需要等热度计算完成
独立伸缩：请求量大时启动多个 API 进程，任务多时启动多个 Worker 进程
故障隔离：Worker 挂了 API 还能正常接收请求，API 挂了 Worker 还能把队列里的任务处理完

一句话总结：API 是"接单的"，Worker 是"干活的"，通过消息队列解耦。

开源贡献实战：修复 JWT 密钥缓存 Bug

跑通项目后，在实际使用中发现了一个真实 Bug。

问题复现

不设置 JWT_SECRET 环境变量，启动后端
注册一个账号
登录成功（页面提示"登录成功"）
但左侧栏仍然显示"未登录"
浏览器控制台报错：invalid or expired token (401)

登录本身成功，但所有需要鉴权的接口全部返回 401。

根因定位

文件：backend/internal/auth/jwt.go

func jwtSecret() []byte {
 secret := os.Getenv("JWT_SECRET")
 if secret == "" {
 b := make([]byte, 32)
 rand.Read(b)
 secret = hex.EncodeToString(b)
 }
 return []byte(secret)
}

问题出在这个函数每次调用都生成一个新的随机密钥：

登录时：GenerateToken() 调用 jwtSecret() → 拿到密钥 A → 用 A 签名 token
验证时：ParseToken() 调用 jwtSecret() → 拿到密钥 B → 用 B 验证
A ≠ B → 签名不匹配 → 返回 401

修复方案

用包级别的变量缓存密钥，保证每个进程只生成一次：

var cachedSecret []byte

func jwtSecret() []byte {
 if cachedSecret != nil {
 return cachedSecret
 }
 secret := os.Getenv("JWT_SECRET")
 if secret == "" {
 b := make([]byte, 32)
 if _, err := rand.Read(b); err != nil {
 log.Printf("FATAL: cannot generate JWT secret: %v", err)
 cachedSecret = []byte("fallback-unsafe-key-change-me")
 return cachedSecret
 }
 secret = hex.EncodeToString(b)
 log.Printf("WARNING: JWT_SECRET not set, generated random key.")
 }
 cachedSecret = []byte(secret)
 return cachedSecret
}

修复方案兼顾安全性（缓存保证签名一致）和灵活性（仍然允许随机密钥兜底）。

走通开源贡献流程

步骤	内容
1. 本地复现	按步骤触发 Bug
2. 阅读源码	从前端 → API → JWT 中间件，定位根因
3. 提 Issue	描述问题，附带复现步骤 → #15
4. Fork + 修复分支	`fix/jwt-secret-caching`
5. 提 PR	关联 Issue → #16

面试话术

在一个 279 star 的开源项目中发现了真实 bug
从前端（Vue/TypeScript）追踪到 API（Gin/Go）再到 JWT 鉴权中间件，定位了根因
提出的修复方案兼顾安全性和灵活性
走通了完整的开源贡献流程

这一篇从"跑通项目"出发，反推了 Docker Compose 编排、Gin 路由注册、Redis 缓存、RabbitMQ 消息队列、Worker 进程模式等工程概念，最后通过一次真实的开源贡献把整条链路串了起来。相比纯语法学习，反推真实项目能更快建立工程直觉。

Redis on JasperSao的博客

Go 项目反推：Feed 流系统实战——Feed 流设计

什么是 Feed 流

这个项目的 4 种 Feed 流

相关文件

推模型 vs 拉模型

拉模型（这个项目用的）

推模型

推拉结合

对比

游标分页 vs 页码分页

页码分页

游标分页（这个项目用的）

对比

游标分页的实现

服务器代码

游标怎么生成的

响应结构

完整流程

热榜实现

热榜排序算法

热度分数怎么算的

热榜查询流程（冷热分离）

快照 key 是什么

关注流实现

核心代码

等价 SQL

子查询是什么

流程

话题流实现

核心代码

等价 SQL

三张表的关系

查询流程

三级缓存架构

代码

查询流程

singleflight 防并发

什么是 singleflight

场景

代码

sfKey 是什么

和分布式锁的对比

面试要点总结

Q: 推模型和拉模型的区别？

Q: 游标分页和页码分页的区别？

Q: 热榜怎么实现的？

Q: 关注流怎么实现的？

Q: 话题流怎么实现的？

Q: 什么是 singleflight？

Q: 三级缓存是什么？

Go 项目反推：Feed 流系统实战——Redis 缓存设计

项目里 Redis 的 7 种用途

1. 缓存读取流程（video_service.go 的 GetDetail）

为什么缓存读取要设 50ms 超时？

为什么不设更短的超时，比如 5ms？

2. 缓存写入

为什么缓存要设过期时间（TTL）？

3. 缓存删除（主动失效）

为什么不等 TTL 过期，要主动删缓存？

4. 缓存和 DB 的一致性策略

两种方案对比

为什么"先更新 DB 再删缓存"更安全？

共同风险点：删缓存失败了怎么办？

5. 缓存穿透/击穿/雪崩

三个概念的区别

缓存击穿的解法（这个项目用的）

缓存穿透的解法（这个项目没做）

缓存雪崩的解法（这个项目没做）

6. 限流中间件（ratelimit.go）

限流是什么？

限流中间件是什么？

限流实现原理

IncrementWithExpire 的 Lua 脚本

为什么用 Lua 脚本？

为什么需要原子执行？

EXPIRE 和 PEXPIRE

限流的 key 设计

7. ZSET 热榜（popularity_cache.go）

ZSET 是什么？