Feed 流 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 流系统实战——SSE 实时推送与分片上传

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

承接 Go 项目反推：Feed 流系统实战——Feed 流设计，这一篇继续拆解 feedsystem_video_go 的两个关键能力：用 SSE 实时推送通知，以及用分片上传和断点续传处理大文件。

阶段6：SSE实时推送

SSE 是什么

SSE = Server-Sent Events，服务器主动给客户端推送消息。

就像外卖 APP 的订单状态：

你下单 → 服务器推送"商家已接单"
 → 服务器推送"骑手已取餐"
 → 服务器推送"骑手已送达"

客户端不用一直问"好了没？好了没？"，服务器有消息就主动推。

SSE vs WebSocket

	SSE	WebSocket
方向	服务器 → 客户端（单向）	双向
协议	HTTP	独立协议
复杂度	简单	复杂
场景	通知、状态更新、新闻推送	聊天、游戏、实时协作

这个项目用 SSE 推送通知（点赞、评论、关注），因为只需要服务器→客户端，不需要客户端→服务器。

为什么用 SSE 不用轮询

方案	做法	问题
轮询	客户端每隔几秒问一次"有新消息吗？"	浪费资源、实时性差、大部分请求返回空
SSE	服务器有消息就推，没有就等着	省资源、实时性高

项目里 SSE 用在哪

用户A给用户B的视频点赞
 ↓
LikeWorker处理点赞事件
 ↓
NotificationWorker收到MQ消息
 ↓
创建Notification记录，写入DB
 ↓
SSEHub.Push(userID, notification)
 ↓
用户B的浏览器收到推送，实时显示"xxx点赞了你的视频"

SSEHub 数据结构

type SSEHub struct {
 mu sync.RWMutex
 clients map[uint][]chan *Notification // userID -> 多个通知channel
 db *gorm.DB
}

数据结构：

map[uint][]chan *Notification

用户1 → [channel1, channel2] （可能多个设备）
用户2 → [channel3]
用户3 → [channel4, channel5, channel6] （三个设备）

代码实现

Notification 表结构

type Notification struct {
 ID uint
 RecipientID uint // 接收者ID
 SenderID uint // 发送者ID
 Type string // 通知类型：like、comment、follow
 TargetID uint // 目标ID（视频ID、用户ID）
 Content string // 通知内容
 IsRead bool // 是否已读
 CreatedAt time.Time
}

SSEHub 核心方法

// 订阅：用户连接时调用
func (h *SSEHub) Subscribe(userID uint) chan *Notification {
 ch := make(chan *Notification, 20) // 缓冲区20
 h.mu.Lock() // 写锁
 h.clients[userID] = append(h.clients[userID], ch)
 h.mu.Unlock()
 return ch
}

// 取消订阅：用户断开时调用
func (h *SSEHub) Unsubscribe(userID uint, ch chan *Notification) {
 h.mu.Lock() // 写锁
 defer h.mu.Unlock()
 chs := h.clients[userID]
 for i, c := range chs {
 if c == ch {
 chs = append(chs[:i], chs[i+1:]...)
 if len(chs) == 0 {
 delete(h.clients, userID)
 } else {
 h.clients[userID] = chs
 }
 close(c)
 return
 }
 }
}

// 推送：有新通知时调用
func (h *SSEHub) Push(userID uint, n *Notification) {
 h.mu.RLock() // 读锁
 defer h.mu.RUnlock()
 chs, ok := h.clients[userID]
 if !ok {
 return
 }
 for _, ch := range chs {
 select {
 case ch <- n: // 往channel里塞消息
 default: // 塞不进去就跳过（防阻塞）
 }
 }
}

SSEHandler - 处理 SSE 连接

func (h *SSEHub) SSEHandler(c *gin.Context) {
 userID, ok := sseAccountID(c)
 if !ok {
 c.JSON(http.StatusUnauthorized, gin.H{"error": "invalid account"})
 return
 }

 // 设置SSE响应头
 c.Writer.Header().Set("Content-Type", "text/event-stream")
 c.Writer.Header().Set("Cache-Control", "no-cache")
 c.Writer.Header().Set("Connection", "keep-alive")
 c.Writer.WriteHeader(http.StatusOK)

 // 订阅通知
 ch := h.Subscribe(userID)
 defer h.Unsubscribe(userID, ch)

 ctx := c.Request.Context()
 flusher, _ := c.Writer.(http.Flusher)

 for {
 select {
 case <-ctx.Done(): // 客户端断开
 return
 case n, ok := <-ch: // 收到通知
 if !ok {
 return
 }
 b, _ := json.Marshal(n)
 fmt.Fprintf(c.Writer, "data: %s\n\n", b) // SSE格式
 if flusher != nil {
 flusher.Flush() // 立刻发送给客户端
 }
 case <-time.After(30 * time.Second): // 心跳
 fmt.Fprintf(c.Writer, ": keepalive\n\n")
 if flusher != nil {
 flusher.Flush()
 }
 }
 }
}

Push 为什么用 RLock 不用 Lock

什么是读写锁（RWMutex）

普通锁（Mutex）：同一时刻只能一个人进去，不管是读还是写。

读写锁（RWMutex）：

多个人可以同时读（RLock）
写的时候只能一个人进去，其他人不能读也不能写（Lock）

对比

操作	做什么	用什么锁
Push	读 map，往 channel 塞消息	RLock（读锁）
Subscribe	往 map 里加一个 channel	Lock（写锁）
Unsubscribe	从 map 里删一个 channel	Lock（写锁）

为什么 Push 能用 RLock

Push 只做两件事：

从 map 里找到用户的 channel（读）
往 channel 里塞消息（不改 map）

map 结构没变，所以多个 Push 可以同时进行。

一句话：读用 RLock（可以并发），写用 Lock（必须独占）。

场景对比

场景：100个用户同时收到通知

用普通锁（Mutex）：
 Push1加锁 → 推送 → 解锁
 Push2加锁 → 推送 → 解锁
 ... 一个一个来，慢

用读写锁（RWMutex）：
 Push1加RLock → 推送
 Push2加RLock → 推送
 Push3加RLock → 推送
 ... 100个同时推，快

心跳机制

什么是心跳

SSE 连接可能因为网络问题断开，客户端不知道。

解决方案：每 30 秒发一次空消息（keepalive），告诉客户端"我还活着"。

case <-time.After(30 * time.Second):
 fmt.Fprintf(c.Writer, ": keepalive\n\n")
 flusher.Flush()

为什么需要心跳

没有心跳：
 客户端连接服务器 → 网络抖动 → 连接断了
 客户端不知道断了 → 一直等 → 漏掉通知

有心跳：
 客户端连接服务器 → 每30秒收到keepalive
 30秒没收到 → 知道断了 → 重新连接

select 里的 default 防阻塞

for _, ch := range chs {
 select {
 case ch <- n: // 往channel里塞消息
 default: // 塞不进去就跳过
 }
}

channel 缓冲区满了（20条），塞不进去怎么办？

没有 default：阻塞等着，Push 卡住，其他用户的推送也卡住
有 default：直接跳过，不等，保证其他用户能正常收到推送

这是防阻塞设计：一个用户的消息堆积不影响其他用户。

NotificationWorker 处理流程

func (w *NotificationWorker) process(ctx context.Context, d amqp.Delivery) error {
 routingKey := d.RoutingKey

 var notif *Notification

 switch {
 case routingKey == "like.like":
 // 解析点赞事件
 // 查询视频作者ID
 // 如果是自己给自己点赞，不通知
 notif = &Notification{RecipientID: authorID, SenderID: evt.UserID, Type: "like", Content: "点赞了你的视频"}

 case routingKey == "comment.publish":
 // 解析评论事件
 // 查询视频作者ID
 // 如果是自己评论自己，不通知
 notif = &Notification{RecipientID: authorID, SenderID: evt.AuthorID, Type: "comment", Content: "评论了你的视频"}

 case routingKey == "social.follow":
 // 解析关注事件
 notif = &Notification{RecipientID: evt.VloggerID, SenderID: evt.FollowerID, Type: "follow", Content: "关注了你"}
 }

 if notif == nil {
 return nil
 }

 // 写入DB
 w.db.Create(notif)

 // 实时推送给用户
 w.hub.Push(notif.RecipientID, notif)

 return nil
}

接口设计

接口	方法	作用
`/stream`	GET	SSE 连接，实时接收通知
`/list`	POST	查询通知列表（最近 50 条）
`/markRead`	POST	标记已读
`/unreadCount`	POST	查询未读数量

阶段7：分片上传

为什么需要分片上传

视频文件可能很大（几十 MB 到 200MB），一次上传的问题：

一次上传100MB：
 网络抖动 → 上传到99%断了 → 重头再来
 用户体验极差

分片上传：

100MB文件，分成5MB一片，共20片
 第1片上传成功 ✓
 第2片上传成功 ✓
 ...
 第17片网络断了 ✗
 重新连接 → 只需要重新上传第17片，1-16不用重传

分片上传流程

整体流程

1. 客户端：计算文件MD5 → 调用Init接口 → 获得upload_id + 已上传分片列表
2. 客户端：逐片上传（跳过已上传的） → 每片带MD5校验
3. 客户端：全部上传完 → 调用Complete接口 → 服务器合并分片 → 返回视频URL

流程图

客户端 服务器
 | |
 |--- Init(文件名, 大小, MD5) ----------->|
 |<-- upload_id + 已上传列表 -------------|
 | |
 |--- UploadChunk(分片0, MD5) ----------->| 保存到临时目录
 |<-- chunk_index: 0 ----------------------|
 | |
 |--- UploadChunk(分片1, MD5) ----------->| 保存到临时目录
 |<-- chunk_index: 1 ----------------------|
 | |
 | ...（中间可能断线重连） |
 | |
 |--- Complete(upload_id) --------------->| 合并所有分片
 |<-- url: 视频地址 -----------------------|

核心数据结构

ChunkUploadSession（上传会话）

const ChunkSize = 5 << 20 // 5 MB

type ChunkUploadSession struct {
 UploadID string // 上传会话ID（随机生成）
 AccountID uint // 上传者ID
 Filename string // 原始文件名
 FileSize int64 // 文件总大小
 ChunkSize int64 // 每片大小（默认5MB）
 TotalChunks int // 总片数
 FileHash string // 整个文件的MD5
 UploadedBits []bool // 每片是否已上传（位图）
}

UploadedBits 是什么

UploadedBits: []bool{true, true, true, false, false}

这个数组表示：

分片 0：已上传 ✓
分片 1：已上传 ✓
分片 2：已上传 ✓
分片 3：未上传
分片 4：未上传

用 bool 数组而不是存已上传的分片列表，好处是：

判断某片是否已上传：O(1)，直接 index
判断是否全部上传完：遍历一次，O(n)

两个辅助方法

// 返回已上传的分片索引列表
func (s *ChunkUploadSession) UploadedChunks() []int {
 var indices []int
 for i, uploaded := range s.UploadedBits {
 if uploaded {
 indices = append(indices, i)
 }
 }
 return indices
}

// 判断是否全部上传完
func (s *ChunkUploadSession) IsComplete() bool {
 for _, b := range s.UploadedBits {
 if !b {
 return false
 }
 }
 return true
}

会话存在哪：Redis

上传会话存在 Redis，不是 MySQL，原因是：

存储	读写速度	持久化	适合存什么
Redis	微秒级	可配置过期	临时状态（上传进度）
MySQL	毫秒级	永久	持久数据（用户信息、视频记录）

上传会话是临时的（24 小时过期），用 Redis 更合适。

Redis Key 设计

// 上传会话
func (h *ChunkUploadHandler) sessionKey(uploadID string) string {
 return h.cache.Key("chunk_upload:%s", uploadID)
}

// 文件哈希 → upload_id 的映射（用于断点续传）
func (h *ChunkUploadHandler) hashKey(accountID uint, fileHash string) string {
 return h.cache.Key("chunk_upload_hash:%d:%s", accountID, fileHash)
}

两个 Key 的作用：

chunk_upload:<upload_id>：存完整的上传会话
chunk_upload_hash:<account_id>:<file_hash>：文件哈希到 upload_id 的映射，用于断点续传

四个接口详解

接口 1：InitChunkUpload（初始化上传）

func (h *ChunkUploadHandler) InitChunkUpload(c *gin.Context)

做了什么：

校验请求参数（文件名、大小、哈希、总片数）
检查文件大小是否超过 200MB 限制
断点续传检查：用文件哈希查 Redis，如果找到之前的会话，直接返回
创建新会话，存入 Redis
返回 upload_id + 已上传列表（新上传为空）

断点续传的实现：

// 检查是否有同文件的旧会话
hashKey := h.hashKey(accountID, req.FileHash)
existingID, err := h.cache.GetBytes(c.Request.Context(), hashKey)
if err == nil && len(existingID) > 0 {
 session, sessErr := h.getSession(c, string(existingID))
 if sessErr == nil {
 // 找到了！返回旧的upload_id和已上传列表
 c.JSON(http.StatusOK, gin.H{
 "upload_id": session.UploadID,
 "uploaded_chunks": session.UploadedChunks(),
 })
 return
 }
}

为什么用文件哈希做断点续传？

用户上传 video.mp4（100MB，MD5: abc123）
 → Init，upload_id: xxx，开始上传
 → 上传了15片，浏览器关闭

用户重新选择同一个 video.mp4
 → Init，参数里带同样的 file_hash: abc123
 → 服务器查Redis：chunk_upload_hash:<uid>:abc123 → xxx
 → 找到旧会话！返回已上传的15片
 → 客户端跳过这15片，只上传剩下的5片

接口 2：UploadChunk（上传单片）

func (h *ChunkUploadHandler) UploadChunk(c *gin.Context)

做了什么：

从表单获取 upload_id、chunk_index、chunk_hash
查 Redis 获取会话
校验：会话存在、是本人上传、分片索引合法
幂等检查：如果这片已经上传过，直接返回成功（不重复处理）
读取上传的文件内容，计算 MD5
哈希校验：对比客户端传的 chunk_hash 和实际计算的 MD5
保存分片到临时目录：.run/uploads/tmp/<upload_id>/<chunk_index>
更新 Redis 中的会话状态

幂等设计：

if session.UploadedBits[req.ChunkIndex] {
 c.JSON(http.StatusOK, gin.H{"chunk_index": req.ChunkIndex})
 return
}

如果分片已上传过，直接返回成功，不重复处理。这保证了重试的安全性。

哈希校验：

hash := md5.New()
io.Copy(hash, chunkFile)
actualHash := fmt.Sprintf("%x", hash.Sum(nil))

if actualHash != req.ChunkHash {
 c.JSON(http.StatusBadRequest, gin.H{"error": "chunk hash mismatch"})
 return
}

每个分片都有 MD5 校验，防止传输过程中数据损坏。

分片存储位置：

.run/uploads/tmp/
 └── <upload_id>/
 ├── 0 ← 第0片
 ├── 1 ← 第1片
 ├── 2 ← 第2片
 └── ...

接口 3：ChunkStatus（查询上传状态）

func (h *ChunkUploadHandler) ChunkStatus(c *gin.Context)

返回：upload_id + 已上传分片列表 + 总片数。

用于客户端轮询或断线后查询进度。

接口 4：CompleteChunkUpload（完成上传）

func (h *ChunkUploadHandler) CompleteChunkUpload(c *gin.Context)

做了什么：

校验会话、校验是否本人
检查是否所有分片都已上传（IsComplete()）
如果有未上传的分片，返回错误和缺失信息
合并分片：按顺序读取所有分片，写入最终文件
清理临时文件和 Redis 会话
返回视频 URL

合并过程：

tmpDir := filepath.Join(".run", "uploads", "tmp", req.UploadID)
for i := 0; i < session.TotalChunks; i++ {
 chunkPath := filepath.Join(tmpDir, fmt.Sprintf("%d", i))
 cf, _ := os.Open(chunkPath)
 io.Copy(finalFile, cf) // 按顺序拼接
 cf.Close()
}

最终文件位置：

.run/uploads/
 └── videos/
 └── <account_id>/
 └── <date>/
 └── <random>.mp4

清理：

// 删除临时分片
os.RemoveAll(tmpDir)

// 删除Redis会话
h.cache.Del(ctx, sessionKey)
h.cache.Del(ctx, hashKey)

安全设计

文件大小限制

const maxSize = 200 << 20 // 200MB
if req.FileSize > maxSize {
 c.JSON(http.StatusBadRequest, gin.H{"error": "file size exceeds 200MB limit"})
 return
}

权限校验

每个接口都检查：会话存在 + 是本人操作。

accountID, _ := jwt.GetAccountID(c)
if session.AccountID != accountID {
 c.JSON(http.StatusForbidden, gin.H{"error": "forbidden"})
 return
}

分片哈希校验

每个分片上传时都验证 MD5，防止数据损坏。

接口总结

接口	方法	作用
`/chunk/init`	POST	初始化上传，返回 upload_id
`/chunk/upload`	POST	上传单个分片
`/chunk/status`	POST	查询上传状态
`/chunk/complete`	POST	完成上传，合并分片

面试要点总结

Q: SSE 是什么？

A: Server-Sent Events，服务器主动推送消息给客户端，单向，基于 HTTP。场景：通知、状态更新、新闻推送。

Q: SSE 和 WebSocket 怎么选？

A: 只要服务器推用 SSE（简单），需要双向通信用 WebSocket（复杂）。这个项目用 SSE 推送通知，因为只需要服务器→客户端。

Q: 为什么用 SSE 不用轮询？

A: 轮询客户端每隔几秒问一次，浪费资源、实时性差。SSE 服务器有消息就推，省资源、实时性高。

Q: 心跳机制是什么？

A: 每 30 秒发一次空消息（keepalive），告诉客户端"我还活着"。客户端 30 秒没收到，知道连接断了，重新连接。

Q: Push 为什么用 RLock？

A: Push 只读 map 不改 map，用读锁可以多个 Push 并发。Subscribe/Unsubscribe 要改 map，用写锁必须独占。

Q: select 里的 default 是干什么的？

A: 防阻塞。channel 满了塞不进去就跳过，保证一个用户的消息堆积不影响其他用户。

Q: 为什么要分片上传？

A: 大文件一次上传，网络断了要重头来。分片后断点续传，只需重传失败的分片。

Q: 断点续传怎么实现？

A: 用文件 MD5 做唯一标识，Init 时查 Redis 是否有同文件的旧会话。有就返回已上传列表，客户端跳过这些分片。

Q: 上传会话存在哪？为什么？

A: 存 Redis，因为是临时状态（24 小时过期），读写快。MySQL 存持久数据。

Q: 怎么保证分片数据没损坏？

A: 每片上传时计算 MD5，和客户端传的 chunk_hash 对比，不匹配就拒绝。

Q: 分片重复上传怎么办？

A: 幂等设计——检查 UploadedBits，已上传的分片直接返回成功，不重复处理。

Q: 会话里 UploadedBits 是什么？

A: bool 数组，每个元素对应一个分片是否已上传。长度等于总片数，直接用下标访问，O(1) 判断某片是否已上传。

Feed 流 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 流系统实战——SSE 实时推送与分片上传

阶段6：SSE实时推送

SSE 是什么

SSE vs WebSocket

为什么用 SSE 不用轮询

项目里 SSE 用在哪

SSEHub 数据结构

代码实现

相关文件

Notification 表结构

SSEHub 核心方法

SSEHandler - 处理 SSE 连接

Push 为什么用 RLock 不用 Lock

什么是读写锁（RWMutex）

对比

为什么 Push 能用 RLock

一句话：读用 RLock（可以并发），写用 Lock（必须独占）。

场景对比

心跳机制

什么是心跳

为什么需要心跳

select 里的 default 防阻塞

NotificationWorker 处理流程

接口设计

阶段7：分片上传

为什么需要分片上传

分片上传流程

整体流程

流程图