1. 短链接服务不只是“缩短”那么简单最近在社区里看到不少讨论从“淘宝短链接跳转微信”到“B站短链接生成器”短链接这个看似简单的技术点背后其实藏着不少门道。很多人第一反应是“这不就是生成一个短字符串然后做个映射跳转吗” 这话对但也不全对。作为一个处理过亿级短链接服务的从业者我想说一个真正能扛住生产环境考验的短链接服务其设计复杂度远超一个简单的“键值对”映射。它需要同时兼顾唯一性、高性能、高可用、可扩展以及安全性尤其是在面对像“抖音短视频外部第三方网页”跳转、电商营销链接跨平台分享这类复杂场景时挑战会成倍增加。简单来说短链接服务的核心价值在于将冗长、不友好、可能包含敏感参数的原始URL转换成一个简短、易记、易传播的字符串并通过重定向实现快速访问。这听起来简单但当你需要保证生成的短码全球唯一、服务毫秒级响应、能承受突发流量洪峰、并且防止被恶意利用时每一个环节的设计都需要深思熟虑。今天我就结合自己的实战经验拆解一下如何从零设计一个工业级的短链接服务。我们会从最核心的短码生成算法聊起一步步深入到系统架构、存储选型、高可用保障最后再谈谈那些容易踩坑的细节和进阶优化思路。2. 短码生成算法是系统的基石短链接服务的第一个技术挑战就是如何生成那个“短且独一无二”的字符串我们通常称之为短码Slug。这个短码通常由数字和字母组成长度在6到8位之间。生成方式直接决定了系统的容量、性能和扩展性。2.1 主流生成方案对比与选型目前业界主要有三种主流的短码生成思路哈希算法、自增ID编码、预生成分发。每种方案都有其鲜明的优缺点和适用场景。方案一哈希算法如MD5, SHA-1, Base62/58编码这是最直观的想法。对原始URL进行哈希如MD5得到一个固定长度的哈希值然后截取前N位作为短码。优点实现简单与原始URL强相关同一个长URL多次请求理论上会得到同一个短码需配合查重有利于节省存储。致命缺点哈希冲突。无论MD5还是SHA-1虽然碰撞概率极低但在海量数据面前并非为零。更关键的是截断操作会指数级放大冲突概率。例如只取MD5的前8个字符32位16进制中的8位其理论空间很小冲突是必然的。你需要一个额外的冲突解决机制如追加随机后缀这会让逻辑变得复杂且破坏了“同一长URL生成同一短码”的特性。方案二自增ID编码发号器方案这是目前大型系统最主流、最可靠的方案。核心思想是系统维护一个全局唯一的、持续自增的数字ID例如1, 2, 3...然后将这个十进制数字ID通过“进制转换”编码成由数字和字母组成的短字符串。工作流程用户提交长URL。服务端从一个发号器ID Generator获取一个全局唯一的自增整数ID。将这个十进制ID通过Base62编码字符集0-9, a-z, A-Z共62个字符转换成一个短字符串。将(短码, 长URL)的映射关系持久化到数据库。返回短码给用户。为什么是Base62因为它能最大程度利用数字、大小写字母在有限的位数内表达更大的数值空间。例如一个6位的Base62短码其理论容量是62^6 ≈ 568亿完全足够。优点绝对唯一只要发号器能保证ID全局唯一且趋势递增生成的短码就绝不会重复。长度可控且递增短码长度会随着ID增大而缓慢增长从1位到2位...非常规律。生成效率高编码过程是纯内存计算速度极快。核心挑战如何设计一个高性能、高可用的分布式发号器这是本方案的技术核心。我们稍后会详细展开。方案三预生成随机码在服务初始化时提前在内存或数据库中生成一大批随机的、唯一的短码。当需要创建短链接时直接从池子里取一个未使用的即可。优点生成时几乎没有计算开销速度极快。缺点存储开销大需要预先存储大量短码其中很多可能长期不会被使用。管理复杂需要维护短码池的消耗和补充机制在分布式环境下同步“已使用”状态是个难题。安全性风险如果是纯随机生成短码没有规律可能被恶意遍历猜测虽然概率低但存在风险。我的实战选型建议对于绝大多数中大型应用“自增ID Base62编码”是首选方案。它简单、可靠、可预测并且将复杂度转移到了“发号器”这个相对独立且业界有成熟解决方案的组件上。哈希方案更适合小规模、非核心的场景。预生成方案则在一些对生成速度有极端要求、且短码消耗量可预测的内部系统中有所应用。2.2 分布式发号器设计精讲既然选择了自增ID方案那么一个可靠的分布式发号器就是心脏。它的核心要求是全局唯一、趋势递增不一定严格连续、高可用、高并发。这里介绍几种常见的实现模式。1. 数据库自增ID最朴素的方式利用数据库如MySQL的AUTO_INCREMENT功能。实现单独建立一张sequence表每次插入一条记录获取一个自增ID。优点简单。缺点性能瓶颈所有请求集中到数据库的一张表写入压力大容易成为单点。可用性差数据库故障会导致整个短链接服务不可用。扩展性差难以通过分库分表来扩展因为需要保证全局唯一。优化可以使用号段模式Segment。即每次从数据库申请一个号段范围例如1-1000加载到应用内存中。应用在内存中分配这个范围内的ID用完了再去数据库申请下一个号段。这大大降低了数据库的写入频率。美团Leaf、百度UidGenerator的开源实现都采用了这种思路。2. Redis INCR利用Redis的原子操作INCR或INCRBY来生成ID。实现设置一个全局键如short_url:sequence每次调用INCR命令使其值加1。优点性能极高远超数据库。缺点持久化与数据丢失风险虽然Redis支持持久化RDB/AOF但在极端故障下仍有微小概率丢失数据导致ID重复或回退。对于短链接服务ID重复是致命错误。扩展性Redis Cluster模式下INCR操作的键必须落在同一个slot无法通过分片来分散压力容量和性能有上限。适用场景对性能要求极高且可以容忍极低概率ID问题或通过其他手段如结合号段模式缓冲的内部系统。3. Snowflake算法及其变种Twitter开源的Snowflake算法是分布式ID的经典解决方案。它生成的是一个64位的长整型数字其结构包含时间戳、工作机器ID、序列号。结构典型划分0 | 41位时间戳 | 10位机器ID | 12位序列号优点完全分布式无需中心化存储各机器独立生成性能极高。趋势递增由于高位是时间戳整体ID是随时间趋势递增的这对数据库索引友好InnoDB的B树索引。信息内嵌ID本身包含了生成时间、机器信息便于排查问题。缺点时钟回拨这是Snowflake最大的挑战。如果服务器时钟发生回拨可能导致生成重复ID。解决方案包括等待时钟追回、记录上次生成时间戳、使用更稳定的时钟源如NTP服务器闰秒处理等。机器ID分配需要一套机制来管理和分配唯一的机器ID10位最多1024台机器。变种与改进百度的UidGenerator、美团的Leaf-snowflake模式都是在原生Snowflake上的优化增加了对时钟回拨更健壮的处理。4. 结合号段与Snowflake的混合模式这是目前许多大厂采用的更稳健的方案。例如美团的Leaf它提供了两种模式Leaf-segment数据库号段和Leaf-snowflake。它们可以同时部署根据业务特点选用。对于短链接服务我推荐使用Leaf-segment模式因为它避免了时钟问题且性能完全足够经过号段缓存QPS可达千万级可靠性更高。发号器选型心得对于创业公司或初期项目如果量级不大使用数据库号段模式是最稳妥、最简单的选择。当单数据库成为瓶颈时可以引入分库分表每个库设置不同的初始值和步长。对于大型系统直接采用开源的Leafsegment模式是更专业的选择它解决了高可用、监控、容灾等问题。除非你有极强的运维能力和对极高性能的追求否则不建议在核心服务中直接使用原生Redis INCR或自实现Snowflake。3. 系统架构与核心组件设计有了短码生成方案我们就可以勾勒出整个短链接服务的系统架构。一个典型的、可扩展的系统包含以下核心组件。3.1 服务端核心流程拆解整个服务可以清晰地分为“写流程”生成短链和“读流程”跳转访问。写流程Create接收与校验API网关或负载均衡器接收用户创建短链的请求POST /api/v1/shorten请求体中包含长URL。服务端首先进行基础校验URL格式是否合法、长度是否超限、是否在黑名单内如恶意网址、敏感域名。长URL归一化这是一个容易被忽略但很重要的步骤。对长URL进行标准化处理例如去除#后面的fragment对查询参数进行排序统一协议头http/https等。目的是让https://example.com/path?a1b2和https://example.com/path?b2a1被视为同一个URL从而生成同一个短码节省存储并提高缓存命中率。查重将归一化后的长URL进行哈希如MD5先在缓存如Redis中查询是否已存在映射。如果存在直接返回已有的短码。这一步能有效避免同一长URL产生多个短码浪费空间。获取短码如果未找到现有映射则调用发号器服务获取一个全局唯一的数字ID。编码将数字ID通过Base62编码算法生成短码字符串。存储映射将短码和归一化后的长URL的映射关系持久化到数据库中。同时将长URL哈希和短码的映射也写入缓存供后续查重使用。返回结果将组装好的短链接如https://s.example.com/abc123返回给用户。读流程Redirect解析短码用户访问短链接如https://s.example.com/abc123。DNS将s.example.com解析到服务的集群IP请求到达Web服务器如Nginx。缓存优先Web服务器或应用服务首先查询分布式缓存Redis键为短码abc123值为长URL。这是整个读流程的性能关键99%以上的请求应该在这一层被处理掉。缓存未命中如果缓存中没有缓存失效或首次访问则查询主数据库获取长URL。回种缓存从数据库查到后将短码-长URL写回Redis并设置一个合理的过期时间如30天。对于热点短链可以设置更长的过期时间或永不过期。302重定向服务端返回HTTP302 Found状态码并在响应头Location字段中填入原始的长URL。浏览器接收到302响应后会自动跳转到目标地址。为什么是302而不是301这是关键设计点。301是永久重定向浏览器会缓存这个跳转后续请求可能不再经过短链接服务器这导致我们无法进行访问统计。302是临时重定向每次都会请求短链服务器便于我们记录访问次数、来源、时间等数据用于数据分析或防刷。记录访问日志在返回302之前或同时将这次访问的详细信息短码、访问时间、User-Agent、IP地址、Referer等异步发送到消息队列如Kafka由下游的日志处理服务进行统计和分析。3.2 数据存储选型与设计存储系统需要处理高并发的读写尤其是读操作。1. 缓存层必须选型Redis是不二之选。它提供亚毫秒级的读写速度支持丰富的数据结构。数据结构使用简单的String类型即可键为短码值为长URL。过期策略为每个键设置TTL生存时间例如30天。这能自动清理不再使用的短链映射节省内存。对于需要永久有效的短链如企业官网短链可以设置特殊的业务标识并不设置TTL或设置极长的TTL。高可用必须部署Redis哨兵Sentinel或集群Cluster模式防止单点故障。2. 持久化存储层选型MySQL或PostgreSQL这类关系型数据库是主流选择。虽然短链接的映射关系很简单id, short_code, long_url, created_at等但关系型数据库的事务、强一致性、复杂查询用于管理后台等特性很有用。表结构设计CREATE TABLE short_urls ( id bigint(20) unsigned NOT NULL COMMENT 发号器生成的全局ID, short_code varchar(16) NOT NULL COMMENT 短码Base62编码后字符串需要加唯一索引, long_url_hash char(32) NOT NULL COMMENT 长URL的MD5用于查重普通索引, long_url text NOT NULL COMMENT 原始长URL, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, expires_at datetime DEFAULT NULL COMMENT 过期时间, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1-有效0-无效, creator varchar(64) DEFAULT NULL COMMENT 创建者标识, PRIMARY KEY (id), UNIQUE KEY uk_short_code (short_code), KEY idx_long_url_hash (long_url_hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT短链接映射表;索引策略id是主键也是发号器生成的数字作为聚簇索引非常高效。short_code必须建立唯一索引这是读请求的主要查询条件。long_url_hash建立普通索引用于创建时的“查重”操作。分库分表当数据量达到亿级单表性能下降时需要考虑分库分表。一个自然的分片键就是short_code本身或者使用id的哈希值。分片后查询路由需要根据短码计算其所在的分片。关于NoSQL的思考像MongoDB这样的文档数据库也适用其Schema灵活易于水平扩展。但对于短链接这种结构极其固定、且需要强一致性和事务如创建时的查重插入的场景关系型数据库的成熟生态和稳定性更具优势。如果读压力极大可以辅以读写分离。4. 高可用、高性能与安全考量一个健壮的服务必须考虑异常情况和恶意行为。4.1 高可用与容灾设计服务无状态化短链接生成和跳转服务本身应设计为无状态的。这样任何一台服务器宕机流量都可以被负载均衡器自动导向其他健康的实例。多级缓存与降级客户端缓存合理利用HTTP缓存头但要注意302跳转本身就不应被客户端长时间缓存。CDN缓存对于极热门的短链接如明星绯闻、爆款商品可以将302响应本身缓存在CDN边缘节点。但需要设置很短的CDN缓存时间如几分钟并确保CDN支持动态回源。应用层缓存Redis如前所述是核心缓存层。数据库缓存使用MySQL查询缓存或InnoDB Buffer Pool。降级策略当Redis完全不可用时系统应能自动降级直接查询数据库。虽然速度变慢但保证了核心跳转功能可用。数据库高可用采用主从复制Master-Slave Replication读写分离。写操作走主库读操作缓存未命中时走从库。同时做好主库故障时的自动切换Failover方案。发号器高可用这是系统的“单点”。如果采用数据库号段模式需要对数据库做主从。如果采用Leaf这类服务它本身内置了高可用机制如多节点部署、基于ZooKeeper的选主。4.2 应对突发流量与性能优化短链接服务经常面临“热点事件”的冲击一个突然爆火的短视频链接可能带来每秒数十万甚至上百万的跳转请求。Redis热点Key问题某个超级热门的短码会成为Redis的单个Key所有流量打向Redis集群的同一个节点可能造成该节点CPU过载。解决方案对热点Key进行本地缓存Local Cache。在应用服务器内存中使用Guava Cache或Caffeine缓存这些顶级热点短码的映射。设置一个较短的本地过期时间如1秒并监听消息队列当短码状态变化如失效时广播消息让所有服务器失效本地缓存。这样99.9%的请求在应用层就被处理不会打到Redis。数据库抗压读压力已被缓存层化解。写压力创建短链相对较低但也要防止恶意刷接口。主要压力在于访问日志的写入。每次跳转都同步写数据库是不可行的。解决方案引入消息队列如Kafka。跳转服务在返回302前将访问日志作为一条消息异步发送到Kafka。后置的日志消费服务再批量写入到数据库或数据仓库如ClickHouse中。这样实现了读写分离和流量削峰。短码长度与容量规划使用6位Base62短码容量约568亿。假设每天创建1千万个短链也需要500多年才能用完。通常6-8位足够。但设计时要考虑发号器的ID范围确保不会溢出。4.3 安全与风控策略短链接可以被滥用成为网络钓鱼、恶意软件传播的帮凶。内容安全检测在创建短链时应对原始长URL进行安全检查。域名黑名单维护一个已知的恶意域名、钓鱼域名列表直接拦截。实时URL检测调用第三方安全API如腾讯云、阿里云的网址安全检测对URL内容进行智能识别。这一步可以是异步的先创建短链再异步检测发现问题后将短码置为无效状态。访问限制频率限制Rate Limiting对创建短链的API接口按IP或用户进行限流防止恶意刷接口耗尽ID资源。短码失效与封禁提供管理功能允许手动或自动根据安全检测结果将某个短码设置为失效返回404或自定义警告页。防止短码枚举使用足够长的随机短码如8位Base62使得枚举所有可能性的成本极高。避免使用连续的、有规律的短码。隐私考虑原始URL可能包含用户敏感信息如token、身份证号。在存储和日志记录时应对URL中的敏感查询参数进行脱敏处理。5. 进阶功能与踩坑实录基础功能跑通后我们可以考虑一些增强功能这也是体现服务差异化的地方。5.1 自定义短码与过期时间自定义短码允许用户指定自己喜欢的短码字符如s.example.com/double11。这带来了新的挑战冲突处理需要检查自定义短码是否已被占用。这需要一次额外的数据库查询。安全性需要防止用户使用敏感词、攻击性词汇作为短码。需要引入关键词过滤。与自动生成短码的隔离最好使用不同的命名空间或前缀避免与系统自动生成的短码冲突。例如自动生成的用/s/abc123自定义的用/c/double11。过期时间在数据库表中增加expires_at字段。跳转时先判断短码是否已过期。对于过期短码可以回收并重新放入可用池如果采用预生成策略或者简单返回410 Gone状态码。5.2 访问数据统计与分析这是短链接服务的核心价值延伸。通过分析跳转数据可以了解营销活动的效果、用户的地理分布、设备类型等。数据采集如前所述通过消息队列异步收集每次跳转的日志。日志应包含短码、访问时间戳、客户端IP、User-Agent、HTTP Referer。数据存储原始日志数据量巨大不适合直接存MySQL。通常写入时序数据库如InfluxDB或大数据分析平台如Hive, ClickHouse。ClickHouse特别适合这类实时OLAP场景能快速进行多维度聚合查询。统计维度总量每个短码的总点击量、独立访客数UV。趋势点击量随时间小时、天的变化曲线。来源分析根据Referer分析流量来自哪个网站或社交平台。地域分布根据IP地址解析出访问者的国家、省份、城市。设备分析从User-Agent中解析出操作系统、浏览器、设备类型移动端/PC端。5.3 实战中踩过的“坑”与应对缓存穿透恶意请求大量不存在的短码导致请求绕过缓存直接打到数据库。解决方案使用布隆过滤器Bloom Filter。将所有已存在的短码哈希后存入布隆过滤器。收到跳转请求时先查布隆过滤器。如果判断为“不存在”则直接返回404无需查询缓存和数据库。对于“可能存在”的请求才继续后续流程。注意布隆过滤器有误判率假阳性但不会漏判假阴性因此是安全的。缓存雪崩大量缓存在同一时刻失效导致所有请求涌向数据库。解决方案为缓存Key设置随机过期时间。例如基础过期时间是30天可以在其基础上增加一个随机数如±1天让缓存失效时间点分散开。数据库慢查询随着数据量增长like查询或不当的索引使用可能导致慢查询。解决方案定期进行慢查询日志分析。确保核心查询where short_code ?使用了索引。对于管理后台需要按长URL模糊查询的需求可以引入Elasticsearch等搜索引擎而不是在MySQL上使用like ‘%xxx%’。短码冲突的“幽灵”即使在测试中概率极低一旦发生就是P0级故障。我们曾因发号器一个早期自研版本在极端并发下的边界条件处理不当导致生成了两个相同的ID。教训不要自己重复造轮子尤其是发号器这种核心基础组件。优先使用经过大规模生产验证的开源方案如Leaf并在上线前进行严格的压力测试和故障注入测试。302跳转与SEO搜索引擎对302跳转的处理与301不同通常不会将权重传递给目标页。如果你的短链接用于需要SEO的页面这是一个需要考虑的问题。但在大多数营销和分享场景下302的统计优势更重要。设计一个短链接服务从概念到生产是一个典型的“麻雀虽小五脏俱全”的系统设计课题。它涵盖了分布式ID生成、高并发缓存设计、数据库优化、高可用架构、安全风控等多个后端核心领域。希望这篇来自实战的拆解能为你提供一个清晰、可落地的设计蓝图。在实际构建时记住先跑通核心流程再逐步迭代增强。优先保证发号器的可靠性和跳转的性能之后再逐步加入风控、统计等高级功能。
短链接服务架构设计：从发号器到高可用，实战解析亿级系统核心
1. 短链接服务不只是“缩短”那么简单最近在社区里看到不少讨论从“淘宝短链接跳转微信”到“B站短链接生成器”短链接这个看似简单的技术点背后其实藏着不少门道。很多人第一反应是“这不就是生成一个短字符串然后做个映射跳转吗” 这话对但也不全对。作为一个处理过亿级短链接服务的从业者我想说一个真正能扛住生产环境考验的短链接服务其设计复杂度远超一个简单的“键值对”映射。它需要同时兼顾唯一性、高性能、高可用、可扩展以及安全性尤其是在面对像“抖音短视频外部第三方网页”跳转、电商营销链接跨平台分享这类复杂场景时挑战会成倍增加。简单来说短链接服务的核心价值在于将冗长、不友好、可能包含敏感参数的原始URL转换成一个简短、易记、易传播的字符串并通过重定向实现快速访问。这听起来简单但当你需要保证生成的短码全球唯一、服务毫秒级响应、能承受突发流量洪峰、并且防止被恶意利用时每一个环节的设计都需要深思熟虑。今天我就结合自己的实战经验拆解一下如何从零设计一个工业级的短链接服务。我们会从最核心的短码生成算法聊起一步步深入到系统架构、存储选型、高可用保障最后再谈谈那些容易踩坑的细节和进阶优化思路。2. 短码生成算法是系统的基石短链接服务的第一个技术挑战就是如何生成那个“短且独一无二”的字符串我们通常称之为短码Slug。这个短码通常由数字和字母组成长度在6到8位之间。生成方式直接决定了系统的容量、性能和扩展性。2.1 主流生成方案对比与选型目前业界主要有三种主流的短码生成思路哈希算法、自增ID编码、预生成分发。每种方案都有其鲜明的优缺点和适用场景。方案一哈希算法如MD5, SHA-1, Base62/58编码这是最直观的想法。对原始URL进行哈希如MD5得到一个固定长度的哈希值然后截取前N位作为短码。优点实现简单与原始URL强相关同一个长URL多次请求理论上会得到同一个短码需配合查重有利于节省存储。致命缺点哈希冲突。无论MD5还是SHA-1虽然碰撞概率极低但在海量数据面前并非为零。更关键的是截断操作会指数级放大冲突概率。例如只取MD5的前8个字符32位16进制中的8位其理论空间很小冲突是必然的。你需要一个额外的冲突解决机制如追加随机后缀这会让逻辑变得复杂且破坏了“同一长URL生成同一短码”的特性。方案二自增ID编码发号器方案这是目前大型系统最主流、最可靠的方案。核心思想是系统维护一个全局唯一的、持续自增的数字ID例如1, 2, 3...然后将这个十进制数字ID通过“进制转换”编码成由数字和字母组成的短字符串。工作流程用户提交长URL。服务端从一个发号器ID Generator获取一个全局唯一的自增整数ID。将这个十进制ID通过Base62编码字符集0-9, a-z, A-Z共62个字符转换成一个短字符串。将(短码, 长URL)的映射关系持久化到数据库。返回短码给用户。为什么是Base62因为它能最大程度利用数字、大小写字母在有限的位数内表达更大的数值空间。例如一个6位的Base62短码其理论容量是62^6 ≈ 568亿完全足够。优点绝对唯一只要发号器能保证ID全局唯一且趋势递增生成的短码就绝不会重复。长度可控且递增短码长度会随着ID增大而缓慢增长从1位到2位...非常规律。生成效率高编码过程是纯内存计算速度极快。核心挑战如何设计一个高性能、高可用的分布式发号器这是本方案的技术核心。我们稍后会详细展开。方案三预生成随机码在服务初始化时提前在内存或数据库中生成一大批随机的、唯一的短码。当需要创建短链接时直接从池子里取一个未使用的即可。优点生成时几乎没有计算开销速度极快。缺点存储开销大需要预先存储大量短码其中很多可能长期不会被使用。管理复杂需要维护短码池的消耗和补充机制在分布式环境下同步“已使用”状态是个难题。安全性风险如果是纯随机生成短码没有规律可能被恶意遍历猜测虽然概率低但存在风险。我的实战选型建议对于绝大多数中大型应用“自增ID Base62编码”是首选方案。它简单、可靠、可预测并且将复杂度转移到了“发号器”这个相对独立且业界有成熟解决方案的组件上。哈希方案更适合小规模、非核心的场景。预生成方案则在一些对生成速度有极端要求、且短码消耗量可预测的内部系统中有所应用。2.2 分布式发号器设计精讲既然选择了自增ID方案那么一个可靠的分布式发号器就是心脏。它的核心要求是全局唯一、趋势递增不一定严格连续、高可用、高并发。这里介绍几种常见的实现模式。1. 数据库自增ID最朴素的方式利用数据库如MySQL的AUTO_INCREMENT功能。实现单独建立一张sequence表每次插入一条记录获取一个自增ID。优点简单。缺点性能瓶颈所有请求集中到数据库的一张表写入压力大容易成为单点。可用性差数据库故障会导致整个短链接服务不可用。扩展性差难以通过分库分表来扩展因为需要保证全局唯一。优化可以使用号段模式Segment。即每次从数据库申请一个号段范围例如1-1000加载到应用内存中。应用在内存中分配这个范围内的ID用完了再去数据库申请下一个号段。这大大降低了数据库的写入频率。美团Leaf、百度UidGenerator的开源实现都采用了这种思路。2. Redis INCR利用Redis的原子操作INCR或INCRBY来生成ID。实现设置一个全局键如short_url:sequence每次调用INCR命令使其值加1。优点性能极高远超数据库。缺点持久化与数据丢失风险虽然Redis支持持久化RDB/AOF但在极端故障下仍有微小概率丢失数据导致ID重复或回退。对于短链接服务ID重复是致命错误。扩展性Redis Cluster模式下INCR操作的键必须落在同一个slot无法通过分片来分散压力容量和性能有上限。适用场景对性能要求极高且可以容忍极低概率ID问题或通过其他手段如结合号段模式缓冲的内部系统。3. Snowflake算法及其变种Twitter开源的Snowflake算法是分布式ID的经典解决方案。它生成的是一个64位的长整型数字其结构包含时间戳、工作机器ID、序列号。结构典型划分0 | 41位时间戳 | 10位机器ID | 12位序列号优点完全分布式无需中心化存储各机器独立生成性能极高。趋势递增由于高位是时间戳整体ID是随时间趋势递增的这对数据库索引友好InnoDB的B树索引。信息内嵌ID本身包含了生成时间、机器信息便于排查问题。缺点时钟回拨这是Snowflake最大的挑战。如果服务器时钟发生回拨可能导致生成重复ID。解决方案包括等待时钟追回、记录上次生成时间戳、使用更稳定的时钟源如NTP服务器闰秒处理等。机器ID分配需要一套机制来管理和分配唯一的机器ID10位最多1024台机器。变种与改进百度的UidGenerator、美团的Leaf-snowflake模式都是在原生Snowflake上的优化增加了对时钟回拨更健壮的处理。4. 结合号段与Snowflake的混合模式这是目前许多大厂采用的更稳健的方案。例如美团的Leaf它提供了两种模式Leaf-segment数据库号段和Leaf-snowflake。它们可以同时部署根据业务特点选用。对于短链接服务我推荐使用Leaf-segment模式因为它避免了时钟问题且性能完全足够经过号段缓存QPS可达千万级可靠性更高。发号器选型心得对于创业公司或初期项目如果量级不大使用数据库号段模式是最稳妥、最简单的选择。当单数据库成为瓶颈时可以引入分库分表每个库设置不同的初始值和步长。对于大型系统直接采用开源的Leafsegment模式是更专业的选择它解决了高可用、监控、容灾等问题。除非你有极强的运维能力和对极高性能的追求否则不建议在核心服务中直接使用原生Redis INCR或自实现Snowflake。3. 系统架构与核心组件设计有了短码生成方案我们就可以勾勒出整个短链接服务的系统架构。一个典型的、可扩展的系统包含以下核心组件。3.1 服务端核心流程拆解整个服务可以清晰地分为“写流程”生成短链和“读流程”跳转访问。写流程Create接收与校验API网关或负载均衡器接收用户创建短链的请求POST /api/v1/shorten请求体中包含长URL。服务端首先进行基础校验URL格式是否合法、长度是否超限、是否在黑名单内如恶意网址、敏感域名。长URL归一化这是一个容易被忽略但很重要的步骤。对长URL进行标准化处理例如去除#后面的fragment对查询参数进行排序统一协议头http/https等。目的是让https://example.com/path?a1b2和https://example.com/path?b2a1被视为同一个URL从而生成同一个短码节省存储并提高缓存命中率。查重将归一化后的长URL进行哈希如MD5先在缓存如Redis中查询是否已存在映射。如果存在直接返回已有的短码。这一步能有效避免同一长URL产生多个短码浪费空间。获取短码如果未找到现有映射则调用发号器服务获取一个全局唯一的数字ID。编码将数字ID通过Base62编码算法生成短码字符串。存储映射将短码和归一化后的长URL的映射关系持久化到数据库中。同时将长URL哈希和短码的映射也写入缓存供后续查重使用。返回结果将组装好的短链接如https://s.example.com/abc123返回给用户。读流程Redirect解析短码用户访问短链接如https://s.example.com/abc123。DNS将s.example.com解析到服务的集群IP请求到达Web服务器如Nginx。缓存优先Web服务器或应用服务首先查询分布式缓存Redis键为短码abc123值为长URL。这是整个读流程的性能关键99%以上的请求应该在这一层被处理掉。缓存未命中如果缓存中没有缓存失效或首次访问则查询主数据库获取长URL。回种缓存从数据库查到后将短码-长URL写回Redis并设置一个合理的过期时间如30天。对于热点短链可以设置更长的过期时间或永不过期。302重定向服务端返回HTTP302 Found状态码并在响应头Location字段中填入原始的长URL。浏览器接收到302响应后会自动跳转到目标地址。为什么是302而不是301这是关键设计点。301是永久重定向浏览器会缓存这个跳转后续请求可能不再经过短链接服务器这导致我们无法进行访问统计。302是临时重定向每次都会请求短链服务器便于我们记录访问次数、来源、时间等数据用于数据分析或防刷。记录访问日志在返回302之前或同时将这次访问的详细信息短码、访问时间、User-Agent、IP地址、Referer等异步发送到消息队列如Kafka由下游的日志处理服务进行统计和分析。3.2 数据存储选型与设计存储系统需要处理高并发的读写尤其是读操作。1. 缓存层必须选型Redis是不二之选。它提供亚毫秒级的读写速度支持丰富的数据结构。数据结构使用简单的String类型即可键为短码值为长URL。过期策略为每个键设置TTL生存时间例如30天。这能自动清理不再使用的短链映射节省内存。对于需要永久有效的短链如企业官网短链可以设置特殊的业务标识并不设置TTL或设置极长的TTL。高可用必须部署Redis哨兵Sentinel或集群Cluster模式防止单点故障。2. 持久化存储层选型MySQL或PostgreSQL这类关系型数据库是主流选择。虽然短链接的映射关系很简单id, short_code, long_url, created_at等但关系型数据库的事务、强一致性、复杂查询用于管理后台等特性很有用。表结构设计CREATE TABLE short_urls ( id bigint(20) unsigned NOT NULL COMMENT 发号器生成的全局ID, short_code varchar(16) NOT NULL COMMENT 短码Base62编码后字符串需要加唯一索引, long_url_hash char(32) NOT NULL COMMENT 长URL的MD5用于查重普通索引, long_url text NOT NULL COMMENT 原始长URL, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, expires_at datetime DEFAULT NULL COMMENT 过期时间, status tinyint(4) NOT NULL DEFAULT 1 COMMENT 状态1-有效0-无效, creator varchar(64) DEFAULT NULL COMMENT 创建者标识, PRIMARY KEY (id), UNIQUE KEY uk_short_code (short_code), KEY idx_long_url_hash (long_url_hash) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT短链接映射表;索引策略id是主键也是发号器生成的数字作为聚簇索引非常高效。short_code必须建立唯一索引这是读请求的主要查询条件。long_url_hash建立普通索引用于创建时的“查重”操作。分库分表当数据量达到亿级单表性能下降时需要考虑分库分表。一个自然的分片键就是short_code本身或者使用id的哈希值。分片后查询路由需要根据短码计算其所在的分片。关于NoSQL的思考像MongoDB这样的文档数据库也适用其Schema灵活易于水平扩展。但对于短链接这种结构极其固定、且需要强一致性和事务如创建时的查重插入的场景关系型数据库的成熟生态和稳定性更具优势。如果读压力极大可以辅以读写分离。4. 高可用、高性能与安全考量一个健壮的服务必须考虑异常情况和恶意行为。4.1 高可用与容灾设计服务无状态化短链接生成和跳转服务本身应设计为无状态的。这样任何一台服务器宕机流量都可以被负载均衡器自动导向其他健康的实例。多级缓存与降级客户端缓存合理利用HTTP缓存头但要注意302跳转本身就不应被客户端长时间缓存。CDN缓存对于极热门的短链接如明星绯闻、爆款商品可以将302响应本身缓存在CDN边缘节点。但需要设置很短的CDN缓存时间如几分钟并确保CDN支持动态回源。应用层缓存Redis如前所述是核心缓存层。数据库缓存使用MySQL查询缓存或InnoDB Buffer Pool。降级策略当Redis完全不可用时系统应能自动降级直接查询数据库。虽然速度变慢但保证了核心跳转功能可用。数据库高可用采用主从复制Master-Slave Replication读写分离。写操作走主库读操作缓存未命中时走从库。同时做好主库故障时的自动切换Failover方案。发号器高可用这是系统的“单点”。如果采用数据库号段模式需要对数据库做主从。如果采用Leaf这类服务它本身内置了高可用机制如多节点部署、基于ZooKeeper的选主。4.2 应对突发流量与性能优化短链接服务经常面临“热点事件”的冲击一个突然爆火的短视频链接可能带来每秒数十万甚至上百万的跳转请求。Redis热点Key问题某个超级热门的短码会成为Redis的单个Key所有流量打向Redis集群的同一个节点可能造成该节点CPU过载。解决方案对热点Key进行本地缓存Local Cache。在应用服务器内存中使用Guava Cache或Caffeine缓存这些顶级热点短码的映射。设置一个较短的本地过期时间如1秒并监听消息队列当短码状态变化如失效时广播消息让所有服务器失效本地缓存。这样99.9%的请求在应用层就被处理不会打到Redis。数据库抗压读压力已被缓存层化解。写压力创建短链相对较低但也要防止恶意刷接口。主要压力在于访问日志的写入。每次跳转都同步写数据库是不可行的。解决方案引入消息队列如Kafka。跳转服务在返回302前将访问日志作为一条消息异步发送到Kafka。后置的日志消费服务再批量写入到数据库或数据仓库如ClickHouse中。这样实现了读写分离和流量削峰。短码长度与容量规划使用6位Base62短码容量约568亿。假设每天创建1千万个短链也需要500多年才能用完。通常6-8位足够。但设计时要考虑发号器的ID范围确保不会溢出。4.3 安全与风控策略短链接可以被滥用成为网络钓鱼、恶意软件传播的帮凶。内容安全检测在创建短链时应对原始长URL进行安全检查。域名黑名单维护一个已知的恶意域名、钓鱼域名列表直接拦截。实时URL检测调用第三方安全API如腾讯云、阿里云的网址安全检测对URL内容进行智能识别。这一步可以是异步的先创建短链再异步检测发现问题后将短码置为无效状态。访问限制频率限制Rate Limiting对创建短链的API接口按IP或用户进行限流防止恶意刷接口耗尽ID资源。短码失效与封禁提供管理功能允许手动或自动根据安全检测结果将某个短码设置为失效返回404或自定义警告页。防止短码枚举使用足够长的随机短码如8位Base62使得枚举所有可能性的成本极高。避免使用连续的、有规律的短码。隐私考虑原始URL可能包含用户敏感信息如token、身份证号。在存储和日志记录时应对URL中的敏感查询参数进行脱敏处理。5. 进阶功能与踩坑实录基础功能跑通后我们可以考虑一些增强功能这也是体现服务差异化的地方。5.1 自定义短码与过期时间自定义短码允许用户指定自己喜欢的短码字符如s.example.com/double11。这带来了新的挑战冲突处理需要检查自定义短码是否已被占用。这需要一次额外的数据库查询。安全性需要防止用户使用敏感词、攻击性词汇作为短码。需要引入关键词过滤。与自动生成短码的隔离最好使用不同的命名空间或前缀避免与系统自动生成的短码冲突。例如自动生成的用/s/abc123自定义的用/c/double11。过期时间在数据库表中增加expires_at字段。跳转时先判断短码是否已过期。对于过期短码可以回收并重新放入可用池如果采用预生成策略或者简单返回410 Gone状态码。5.2 访问数据统计与分析这是短链接服务的核心价值延伸。通过分析跳转数据可以了解营销活动的效果、用户的地理分布、设备类型等。数据采集如前所述通过消息队列异步收集每次跳转的日志。日志应包含短码、访问时间戳、客户端IP、User-Agent、HTTP Referer。数据存储原始日志数据量巨大不适合直接存MySQL。通常写入时序数据库如InfluxDB或大数据分析平台如Hive, ClickHouse。ClickHouse特别适合这类实时OLAP场景能快速进行多维度聚合查询。统计维度总量每个短码的总点击量、独立访客数UV。趋势点击量随时间小时、天的变化曲线。来源分析根据Referer分析流量来自哪个网站或社交平台。地域分布根据IP地址解析出访问者的国家、省份、城市。设备分析从User-Agent中解析出操作系统、浏览器、设备类型移动端/PC端。5.3 实战中踩过的“坑”与应对缓存穿透恶意请求大量不存在的短码导致请求绕过缓存直接打到数据库。解决方案使用布隆过滤器Bloom Filter。将所有已存在的短码哈希后存入布隆过滤器。收到跳转请求时先查布隆过滤器。如果判断为“不存在”则直接返回404无需查询缓存和数据库。对于“可能存在”的请求才继续后续流程。注意布隆过滤器有误判率假阳性但不会漏判假阴性因此是安全的。缓存雪崩大量缓存在同一时刻失效导致所有请求涌向数据库。解决方案为缓存Key设置随机过期时间。例如基础过期时间是30天可以在其基础上增加一个随机数如±1天让缓存失效时间点分散开。数据库慢查询随着数据量增长like查询或不当的索引使用可能导致慢查询。解决方案定期进行慢查询日志分析。确保核心查询where short_code ?使用了索引。对于管理后台需要按长URL模糊查询的需求可以引入Elasticsearch等搜索引擎而不是在MySQL上使用like ‘%xxx%’。短码冲突的“幽灵”即使在测试中概率极低一旦发生就是P0级故障。我们曾因发号器一个早期自研版本在极端并发下的边界条件处理不当导致生成了两个相同的ID。教训不要自己重复造轮子尤其是发号器这种核心基础组件。优先使用经过大规模生产验证的开源方案如Leaf并在上线前进行严格的压力测试和故障注入测试。302跳转与SEO搜索引擎对302跳转的处理与301不同通常不会将权重传递给目标页。如果你的短链接用于需要SEO的页面这是一个需要考虑的问题。但在大多数营销和分享场景下302的统计优势更重要。设计一个短链接服务从概念到生产是一个典型的“麻雀虽小五脏俱全”的系统设计课题。它涵盖了分布式ID生成、高并发缓存设计、数据库优化、高可用架构、安全风控等多个后端核心领域。希望这篇来自实战的拆解能为你提供一个清晰、可落地的设计蓝图。在实际构建时记住先跑通核心流程再逐步迭代增强。优先保证发号器的可靠性和跳转的性能之后再逐步加入风控、统计等高级功能。