تسجيل الدخول الآن 在不少业务里，短链接都像个不起眼的“小零件”，却常常出现在海报、群消息、短信、广告里。原本一条又长又乱的链接，放上去不仅不好看，还容易被截断。换成 https://xxx/Ab3xYz 这样的形式，用户扫一眼就能看懂，后台也能知道谁点过、从哪里点、效果如何。真要把这个服务做稳定，并保证三秒内生成，难点并不只在写一个接口，而是在编码、存储、缓存、部署、监控和安全之间做取舍。
短码怎么来的？一个常见做法是先给原始 URL 做一次哈希，比如 MD5 或 SHA-1，把长短不一的网址变成较短摘要，再转成 Base62 编码。Base62 只用 26 个大写字母、26 个小写字母和 10 个数字，字符集紧凑，生成结果看起来也更干净。实际生成时，可以截一段固定长度，也可以靠取模把短码控制在六位左右。六位 Base62 能承载约 568 亿种组合，对大多数业务来说，这个空间已经够用。
当然，不能太相信“不会撞”。哈希再稳定，截取之后也可能重复，尤其是同一个链接反复生成，或者不同链接刚好撞上。所以生成逻辑一定要想清楚：短码已经存在，是重新生成，是直接返回已有映射，还是换一套编码策略。否则用户点了“生成”，最后拿不到可用链接，体验一下就掉下来了。
表结构可以尽量简单，但要方便后面查询。一张基础表通常至少存短码、原始 URL、创建时间、过期时间、点击次数。短码作为主键或唯一索引，是为了访问时快速找到原始地址；创建时间方便排查；过期时间决定什么时候失效；点击次数则给统计留下基础数据。业务复杂后，还可以加来源、目标端、访问密码、是否禁用、是否登录创建等字段。不过一开始没必要把所有功能都塞进去，先把“生成短码、访问短码、跳回原链接”这条主流程跑顺更实在。
对外提供生成入口时，可以用 Flask、Django、Spring Boot 这类常见框架。请求方式一般用 POST：客户端把长链接传上来，服务端先校验格式，再生成短码、写入数据库，最后返回完整短链。流程看起来简单，真正上线时前后都要加保护。原始 URL 得是可访问格式，空值、非法字符、超长链接要拦下来；短码生成要有重试；数据库写入也不能每次新建连接，不然并发一高，连接创建和释放就会拖慢整体。
有些示例会在短码冲突时用 DO NOTHING 快速兜底，但这样只能避免报错，不能保证用户拿到新短码。更稳的方式是发现冲突后继续生成，或者在数据库层面设计合理的唯一约束和重试策略。生产服务要承诺三秒内生成，不能只盯着算法快不快，还得保证异常路径也能在可接受时间内给出明确结果。
想让响应时间真的降下来，缓存、异步处理和 CDN 都很关键。高频访问的短码和原始链接可以放进 Redis，减少数据库查询；数据库连接池让并发请求复用连接，不用反复排队；点击日志、访问来源、审计信息这类不影响主流程的工作，可以交给 Celery、消息队列或后台任务异步完成。用户访问短链时，服务返回 302 跳转，同时记录一次点击。如果重定向服务部署在 CDN 或靠近用户的边缘节点，跳转响应也能离用户更近。整体链路可以大致走：客户端到 CDN，再到负载均衡、Web 服务器，最后访问 PostgreSQL 主从集群和 Redis 集群。
常见压力测试结果通常有这样的表现：100 并发时平均响应约 120 毫秒，成功率可到 100%；1000 并发时平均约 450 毫秒，成功率约 99.98%；5000 并发时平均约 1.8 秒，成功率约 99.5%。这组数字至少说明，三秒目标不是只靠嘴上承诺。只要链路设计合理，数据库不成为单点，缓存和异步处理跟得上，短链接生成是可以稳定做到秒级甚至更低。真遇到大流量活动，还可以进一步拆分服务，或借助云函数、DynamoDB、边缘计算这类低延迟组合，减少冷启动和跨地域访问带来的波动。
容灾和监控不能省。短链接服务功能看起来简单，可一旦支撑短信、广告、社群推广或二维码物料，出问题就会直接影响投放效果。数据库最好做多可用区部署，并实时同步到备用节点，故障时能自动切换。监控方面，可以用 Prometheus 采集响应时间、错误率、数据库连接数、缓存命中率等指标，再用 Grafana 做可视化；日志可以接入 ELK 或类似系统，方便快速定位异常。告警阈值要实用，比如响应时间持续超过一秒就报警，不要等用户反馈“链接打不开”才被动发现。
安全也很现实。开放生成接口后，如果没有速率限制，很容易被机器脚本短时间内刷爆。限制单个 IP 每分钟请求次数，是最基础的防护之一。对目标网址做安全检测也很重要，接入 Google Safe Browsing API 只是常见方案，核心思路是尽量拦截钓鱼、恶意下载、违规跳转等风险链接。Referer 检查能防盗链，但不能太死，有些客户端并不会严格携带 Referer，容易误伤正常渠道。对运营场景，还可以加入访问密码、有效期、禁用链接、审核机制，让服务不只是能用，更敢放心用。
如果面向实际营销和私域运营，功能还可以更顺手一些。免登录生成适合普通用户，粘贴长链、点击生成、复制结果，三步就能完成；自定义短码适合品牌活动，让链接后缀更像自己的标识；批量生成适合电商上新、短信群发、广告投放，一次导入大量链接，比人工粘贴高效很多；多端跳转可以让 iOS、Android、PC 用户看到不同落地页；访问统计能看点击量、来源、设备、地域，帮助判断哪个渠道有效。还有一种常见情况：二维码已经印刷出去，广告也已经投放，如果临时需要更换目标网址，只要服务支持后台替换原始地址，已有物料就能继续发挥作用，这种灵活性在实际业务里很实用。
比如自定义短码接口，服务端接收原始 URL 和用户指定的短码，先校验长度、字符规则和唯一性，再写入数据库。如果短码已被占用，应该返回明确错误，而不是覆盖原数据或静默失败。统计接口也类似：用户访问短码时，先更新点击次数，再查询原始链接并执行 302 跳转。链接不存在时返回友好错误页；链接已过期或被禁用时，也要给出清晰提示。表面看只是几条 SQL 和几行跳转逻辑，背后牵着的却是整个服务的可用性和数据准确性。
说到底，三秒内生成短链接并不神秘。编码方案决定短码是否短、稳定、可管理；数据库和缓存决定高频访问时能不能扛住；异步处理和 CDN 决定高峰期是否从容；监控、容灾和安全决定长期运行是否可靠。把这些环节串起来，短链接服务才能真正进入短信、社群、电商、广告、二维码、小程序和外链投放等实际场景，而不只是生成一串字符的 demo。