golang如何设计短链接系统_golang短链接系统设计方案-Golang-PHP中文网

短链接系统需避免哈希碰撞、保障跳转性能、防御刷量并优化统计：用带盐的sha256+重试生成7位短码；跳转走sync.map+redis双层缓存，5ms内完成；限流前置至nginx和go服务；统计异步聚合写入kafka/clickhouse。

golang如何设计短链接系统_golang短链接系统设计方案

短链接生成必须避开重复和冲突

用 hash 直接截取字符串（比如 MD5 前 6 位）看似简单，但实际线上一跑就撞——哪怕 100 万条链接，碰撞概率也超 1%。根本原因是哈希空间被人为压缩得太狠，又没做兜底重试。

正确做法是：先基于原始 URL + 时间戳 + 随机盐生成完整 sha256，取前 7 位作为候选码；插入数据库时用 INSERT ... ON CONFLICT DO NOTHING（PostgreSQL）或 INSERT IGNORE（MySQL），失败就加个计数器重试，最多 3 次。不依赖数据库自增 ID 做短码，否则暴露业务量、易被遍历。

别用 base62(自增ID)：ID 可预测，爬虫一扫全出
盐值要每次请求都变，比如 rand.Int63()，不能固定
7 位 base62 理论容量约 3.5 万亿，够用；6 位只剩 56 亿，高并发下撑不住

跳转路由必须绕过中间件和重定向链

用户访问 /abc123，如果走常规 Gin/echo 路由再查 DB、再 Redirect，延迟至少 10–20ms，还吃连接池。真实场景里，短链跳转得在 5ms 内完成，否则用户感觉“卡”。

方案是把短码和目标 URL 的映射预热进内存——用 sync.Map 存热点（比如最近 1 小时访问 Top 1000），冷数据查 Redis（TTL 设 7 天）。HTTP 处理函数里只做两件事：查 sync.Map → 命中则 http.Redirect；不命中则查 Redis，查到就回写 sync.Map 并跳转，查不到直接返回 404。

Golang Uber Dig

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

下载

别在跳转逻辑里加日志埋点或权限校验：那是长链服务的事，短链只负责快准稳
Redis 查不到时不要 fallback 到 MySQL：DB 延迟高，会拖垮整个跳转链
sync.Map 不适合存全部数据（GC 压力大），只放高频 key，大小限制在 2000 条以内

防刷和限流得在接入层就掐住

短链系统最容易被刷的是生成接口——攻击者用脚本批量提交垃圾 URL，占满数据库、打爆 Redis。等你发现时，可能已写入 50 万条无效记录。

必须在反向代理（如 Nginx）或网关层做第一道限流：limit_req zone=shorten burst=5 nodelay，单 IP 每秒最多 5 次生成请求。Go 服务内再用 golang.org/x/time/rate.Limiter 做二级控制，按用户 token 或 IP 维度限制。

生成接口返回的短码，不能立刻用于跳转：加个 status 字段，初始为 "pending"，异步校验 URL 可访问性后再置为 "active"
别对跳转请求限流：合法用户点击就是正常行为，限流反而伤体验
Redis 记录的限流状态 TTL 要设短（比如 60 秒），避免 IP 池复用导致误杀

统计和扩展要考虑写放大问题

每跳一次就记一条 PV？那 10 万 QPS 的短链，每秒写 10 万行日志或 DB 记录，磁盘和网络马上告急。真实做法是：跳转时不落库，只往本地内存环形缓冲区（ring buffer）里塞一条轻量结构体（短码、时间戳秒级、UA 前 8 字节）；后台 goroutine 每 5 秒 flush 一次，聚合后批量写 Kafka 或 ClickHouse。