Se Connecter Maintenant 短链接这东西，乍一看简单得很——把长网址压短，用户点一下，跳过去，完事。可真要把它当成一个正经系统来做，尤其是每天要扛住千万级跳转请求的时候，背后的技术栈一点都不轻松。毫秒级的响应要求、海量的映射数据、遍布全球的访问者，每一项都在逼着架构师做取舍。这篇文章就从工程落地的角度，聊聊主流 SaaS 短链平台是怎么搭架构的——从微服务拆分、分布式存储到多级缓存，希望能给准备自建的团队一些参考，也给正在选型的企业一个判断依据。
先看整体架构。目前市面上的主流 SaaS 短链平台，几乎都选择了 SpringCloud 微服务体系，把链接生成、跳转处理、数据统计拆成三个独立服务：生成服务管短码算法和冲突检测，跳转服务一门心思把 302 重定向做到极致，统计服务则负责访问日志的异步分析。这么拆不是为了赶微服务的热闹，而是有实打实的好处——营销活动一上来，跳转量可能瞬间翻好几倍，这时只需要给跳转服务加实例就够了，不用整个系统跟着一起扩容。算下来，资源利用效率能提升 40% 以上。
技术栈的选择也颇有讲究。大部分团队以 Java 生态为主力，JDK 17 配 Spring Boot 3 是常见组合，毕竟链接生成、数据统计这些模块业务逻辑复杂，Java 的框架生态更成熟，写起来顺手。但到了 302 跳转这个环节，不少团队会专门用 Go 重写一遍。原因很直接：Go 的协程模型天生适合处理海量并发连接，同样的机器，QPS 能做到 Java 版本的两到三倍。部署层面，云原生早已是标配——Docker 容器化加 Kubernetes 编排，系统跟着实时流量自动伸缩。凌晨低谷收缩到最小配置，活动高峰再自动拉起实例，光是这份弹性，就能省下大约 60% 的服务器成本。
再看数据存储，这一块最考验分层设计的功夫。短链和长链的映射关系存在 MySQL 里，但单表绝不能放任它涨到千万级以上，所以系统会按哈希算法把短码均匀打散到多个库实例，每个分片各扛各的读写压力。查询时先对短码做一次哈希，直接定位到目标分片，耗时可以稳定在 5 毫秒以内。这里有个容易踩的坑：分片规则要是按时间来定，新数据会扎堆涌进某几个库，负载严重不均；只有按短码哈希分片，数据量和访问量才能摊得匀。这个细节看起来不起眼，却直接决定了系统能不能线性扩展。
缓存是三层设防。第一层 Redis，存热门短链，命中率通常能到 95% 以上。可即便是 Redis，一次查询也有一两毫秒的网络开销，于是又有了第二层——应用内部的本地缓存，比如 Caffeine，把最热的数据直接放进 JVM 内存，响应时间一下压到微秒级。第三层是 CDN 边缘节点：用户点击短链后，请求先落到离他最近的节点上，命中缓存就直接 302 跳走，压根不用回源。靠着这套组合拳，全球各地用户的访问延迟基本都能压在 100 毫秒以内。
还有一个容易被忽视的问题：点击日志。每一次跳转都会产生一条记录，带着 IP、设备、时间这些信息。如果同步写库，跳转性能立刻被拖垮。成熟的解法是把日志先丢进 Kafka 或 RabbitMQ 这类消息队列，跳转服务立刻返回，后台消费者再慢慢落库。至于日志的分析存储，一般会选 ClickHouse 这样的列式数据库——做独立 IP 去重、地域分布这类分析型查询时，它比 MySQL 快 10 倍不止，而且支持实时写入，统计报表的延迟能控制在分钟级。
架构之外，企业级功能也有不少技术门道。拿随机跳转来说，它服务于 A/B 测试场景：一个短链挂多个目标地址，各自配上权重，用户点击时按加权随机算法分配到不同落地页。难点在于，这套算法必须跑在跳转链路里，执行耗时要压到 1 毫秒以内，否则就是在拿用户体验开玩笑。访问权限控制更麻烦一些——IP 白名单、访问密码、有效期这些规则都得在跳转之前校验完，还不能让正常用户感觉到慢。常见的做法是把权限规则也塞进 Redis，让整个校验过程在内存里完成。
最后说说自建还是买 SaaS 这个老问题。答案其实取决于量级和团队。日均跳转 10 万以下，单体应用加个 Redis 缓存就够了，没必要折腾；到了日均百万级，就得认真考虑微服务拆分和分库分表；如果是千万级以上的流量，全套分布式架构跑不掉，技术团队至少得配 5 个人。反过来说，团队不到 5 人，或者业务要求两周内上线，那就别硬撑了——成熟的 SaaS 平台已经把整套技术栈集成好了，还针对抖音巨量广告、百度营销、快手磁力智投这些主流投放平台做过专项优化，踩坑的成本早就有人替你付过了。