지금 로그인 电商大促当晚，短链点击量突然翻了几十倍，系统直接躺平——经历过这种事故的团队不在少数。事后复盘，很多人的第一反应是服务器不够强、带宽不够大，于是加机器、升配置。可到了下次大促，该挂还是挂。说到底，问题不在硬件，而是架构从一开始就设计错了。
短链系统听起来很简单：把长链接变短，用户点一下再跳回去，好像没什么技术含量。真正的难点在并发上。从实际业务里磨出来的这套打法——服务拆分、分布式ID、Redis分层缓存——也不只适用于短链，秒杀、抢购、投票这类读多写少、流量瞬间暴涨的场景，底层逻辑几乎是一样的。
先聊服务拆分。很多团队图省事，把短链生成和跳转写在同一个服务里，部署一套完事。业务量小的时候确实相安无事，流量一上来，一个致命矛盾就暴露了：写操作在拖累读操作。生成短链是写操作，要入库、要生成全局唯一ID、要记录时间戳，耗时天然就长；用户点短链则是纯读操作，要求毫秒级返回。两类请求挤在一个服务里，大促时生成端的压力会直接拖垮跳转速度，整个系统跟着陪葬。
所以第一步就是拆：生成服务和跳转服务各自独立部署。生成服务流量小，几台实例就够；跳转服务承接全部点击流量，按峰值配足机器。拆开之后的好处是一连串的——资源可以按真实的读写比例分配，扩容时哪里不够加哪里，不用整体膨胀；两个服务能配各自的监控和告警策略，哪边出问题一眼定位；更关键的是故障隔离，就算跳转服务被突发流量打满，短链生成功能还活着，反过来也一样，不至于全线瘫痪。毕竟短链的生成频率和访问频率根本不在一个数量级上，一次生成对应的往往是成千上万次点击，这种业务天生适合读写分离。
拆完服务，下一个问题是ID。每条短链都需要一个全局唯一标识，主流方案有两个。一个是Snowflake算法，ID由时间戳、机器ID、序列号三段拼成，天然递增有序，对数据库索引友好，单机每秒轻松生成400万个ID，性能完全够用；软肋是依赖系统时钟，碰上时钟回拨得额外处理。另一个是号段模式：提前从数据库批量取一段ID放进内存，递增着分配，用完再取下一段，彻底绕开了时钟依赖，美团的Leaf和滴滴的Tinyid走的都是这条路。两种方案没有绝对优劣，主要看团队对时钟环境和运维成本的接受程度。
拿到数字ID之后还有一步：编码。直接把十几位数字塞进URL，既长又难看，通用做法是Base62编码——用0-9、a-z、A-Z这62个字符来表示数字。一个64位的Snowflake ID转完大约11个字符，如果还嫌长，可以做截取或哈希压缩，在能接受的冲突率内进一步缩短。
服务拆好了，ID也能发了，真正的重头戏才开始：跳转链路怎么扛住百万级QPS。跳转的核心逻辑确实简单，根据短链码查出原始URL，然后302重定向，一步搞定。但这个"简单查询"要是直接打到数据库上，就是一场灾难。所以必须上Redis，而且不是随便用用，得有章法。
短链访问有个非常典型的二八分布：80%的流量集中在20%的热点短链上，大促期间这个比例还会更极端，头部商家的活动链接可能独占大半流量。对热点数据，正确的做法是提前全量加载进Redis，给一个较长的过期时间，让这部分流量压根不碰数据库。非热点短链则走懒加载：第一次被访问时查一次库，顺手写进缓存，之后就直接命中。
缓存层还有几个经典坑要防。一是缓存穿透：有人拿不存在的短链码恶意刷请求，每次都会穿过缓存打到数据库。解法是在缓存前面加一道布隆过滤器，先判断短链码是否存在，不存在的请求直接拦掉。二是缓存雪崩：大量短链如果在同一时刻集中过期，数据库会被瞬间打爆。给每条短链的TTL加上随机偏移量，让过期时间均匀散开，就能避开这个雷。布隆过滤器挡恶意流量、Redis扛住正常读请求、数据库做最终兜底，三层防护各司其职，缺一层都不踏实。
单点Redis的容量和性能都有上限，数据量大了就得上Redis Cluster，通过哈希槽机制把数据分散到多个主节点，每个主节点配一到两个从节点保证高可用，主库挂了能自动切换。数据库这边同样要分片，常见做法是按短链ID哈希取模，拆成64张表，写入走主库、查询走从库，做读写分离。这里还有个容易被忽略的细节：主从延迟。用户刚生成短链马上就点，这时数据可能还没同步到从库，一查就是空。解决办法很直接——生成成功的同时往Redis写一份临时缓存，新链接的首次访问直接命中缓存，等主从同步追上来，这点延迟就无感了。
当然，不是每个团队都有精力从零搭这套系统。架构设计、压测调优、运维保障，每一步都得投入人力。如果业务急着上线，完全可以先用现成的短链服务把功能跑起来，比如快缩短网址（suo.run）这类工具，免登录就能生成短链，支持批量导入、自定义短码和访问数据统计，也针对微信、淘宝、抖音等平台做了防封适配，中小团队拿来就能用。等业务流量真起来了，再回头自建系统也不迟。
这套"服务拆分+分布式ID+Redis分层缓存"的思路，价值远不止短链本身。凡是读多写少、流量瞬时暴涨的场景，都能套用这个模式：读写分离拆开流量，缓存扛住读压力，热点数据提前预热。落地时建议从最小可用版本做起，先把核心链路跑通，再跟着业务增长逐步迭代——架构从来不是一步到位设计出来的，而是被业务推着长出来的。