golang如何设计Feed流系统_golang Feed流系统设计实战-Golang-PHP中文网

Feed流系统需分层设计：发布者数据用Tablestore/TiDB分片索引，关注关系用MySQL联合索引，Feed列表用时序KV存储；推拉模式由存储能力决定，避免混合模式。

golang如何设计feed流系统_golang feed流系统设计实战

Feed流系统在 Go 中不是靠堆协程或加缓存就能扛住亿级流量的，核心在于数据分层是否清晰、读写路径是否分离、冷热是否分治。不按这三点设计，后期扩容和排查会非常痛苦。

发布者的数据、关注关系、接收者的 Feed 列表，本质是三种访问模式完全不同的数据，混存在一个数据库里迟早出问题。

发布者的数据：按 user_id 分片 + 时间倒序索引，适合用 Tablestore 或 TiDB，要求强一致性、支持范围扫描；不能用 Redis 缓存全量，否则删帖/编辑无法及时生效
关注表：高频随机读写（关注/取关）、需支持双向查询（查我关注了谁 / 谁关注了我），建议用 MySQL + 唯一联合索引 (follower_id, followee_id)，必要时加 followee_id 单列索引加速“被关注”场景
同步库（Feed 列表）：只存最近 7 天热门内容，TTL 自动过期，必须用支持时间分片的 KV 存储（如 Redis Streams 或自研基于 LSM 的时序 KV），避免用 String 类型拼接 ID 列表——一旦用户关注 5000 人，单次 LRANGE 就可能超时

推模式写放大，拉模式读放大，Go 服务本身不决定选型，而是由下游存储能力反推。别迷信“推拉结合”，混合模式会让一致性校验逻辑爆炸式增长。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

纯推模式适用场景：日均发帖且 <code>人均关注数。发帖时遍历关注列表，向每个粉丝的 <code>feed_timeline_{uid} 写入一条 post_id:timestamp，用 pipeline 批量写 Redis，失败走异步补偿队列（如 Kafka）
纯拉模式适用场景：大 V 集中（Top 1% 用户产出了 80% 内容）。首页 Feed 直接查 followee_ids，再并发请求各发布者的最新 N 条（用 sync.WaitGroup 控制并发上限，防雪崩），结果合并后按时间归并排序——注意别用 sort.Slice 对全量做排序，应改用 heap 包实现多路归并
关键陷阱：Redis ZSET 存 Feed 时，score 不能直接用 Unix timestamp，必须转成 int64 并做毫秒级对齐（如 ts / 1e6），否则浮点 score 在集群模式下分片不一致；同时要预留字段存 post_id 和 score 的复合键，避免 score 冲突时覆盖

Go runtime 很轻量，但写法不当会让 GC 和锁成为隐形杀手。Feed 流请求的 P99 延迟必须压在 200ms 内，否则用户会明显感知卡顿。

禁止在 HTTP handler 里做任何阻塞 IO：数据库查询、Redis LRANGE、HTTP 调用都必须设 context.WithTimeout，超时直接返回兜底 Feed（比如最近热门）
慎用 sync.Mutex 保护共享 map：高并发下争抢严重，改用 sync.Map 或分段锁（shard map），例如按 user_id % 64 分 64 个桶
序列化别碰 json.Marshal：Feed 数据结构固定，用 easyjson 或 go-json 生成静态 marshaler，实测可降低 40% CPU 占用；返回前用 bytes.Buffer 预分配空间，避免多次扩容
分页参数必须校验：offset 超过 1000 就强制跳转到第一页，防止深度翻页触发全表扫描；limit 上限设为 50，前端用游标（cursor）代替 offset