ByteByteGo学习笔记：URL短链服务设计

引言

在互联网技术日新月异的今天，URL短链服务已经成为日常网络生活中不可或缺的一部分。每当想要分享一个冗长的网页链接，或者需要在对字符数量敏感的平台（如社交媒体、短信等）发布链接时，URL短链服务都能将长长的URL地址精简成短小、易于传播的链接。例如，将冗长的 https://www.systeminterview.com/q=chatsystem&c=loggedin&v=3&i=long 缩短为 https://tinyurl.com/y7keocwj，这不仅提升了用户体验，也方便了链接的分享和管理。

需求分析

对于URL短链服务而言，其核心需求看似简单，即将长URL转换为短URL，并将短URL重定向回原始的长URL。然而，在实际设计过程中，需要考虑更多细节和约束条件。

1. 功能性需求

首先，需要明确URL短链服务的基本功能。

• URL缩短功能: 接收一个长URL，生成并返回一个短URL。例如，用户输入 https://www.example.com/very/long/path/to/resource?param1=value1&param2=value2，系统应返回 https://tinyurl.com/shortCode 这样的短链接。
• URL重定向功能: 当用户访问短URL时，服务能够将其重定向到原始的长URL。例如，用户访问 https://tinyurl.com/shortCode，浏览器应自动跳转到 https://www.example.com/very/long/path/to/resource?param1=value1&param2=value2。

2. 非功能性需求

除了基本功能，非功能性需求同样重要，它们直接关系到系统的性能、可靠性和可扩展性。

• 流量预估: 每日产生1亿个URL缩短请求。这是一个相当大的量级，意味着系统需要具备高吞吐量和低延迟的处理能力。

  • 写入QPS (Queries Per Second): 1亿 / (24小时 * 3600秒) ≈ 1160 QPS。这意味着系统平均每秒需要处理约1160个URL缩短请求。
  • 读取QPS: 假设读操作（短URL重定向）与写操作的比例为10:1，则读取QPS约为 1160 * 10 = 11600 QPS。实际应用中，读取操作可能会远高于写入操作，因为一个短URL可能会被多次点击访问。
• 短URL长度: 尽可能短。 用户期望短URL足够简洁，易于记忆和分享。
• 短URL字符集: 允许使用数字 (0-9) 和字符 (a-z, A-Z) 的组合。 这定义了构成短URL的字符范围，共计 10 + 26 + 26 = 62 个字符。
• 短URL更新与删除: 为了简化设计，假设短URL一旦生成，不可删除或更新。 这是一个重要的简化假设，实际系统中可能需要考虑URL失效、更新等机制。

• 持久性存储: URL短链服务需要长期运行，假设为10年。 这意味着需要考虑数据存储的容量和持久性。

  • 总记录数: 1亿 URL/天 365 天/年 10 年 = 3650亿条记录。
  • 存储容量估算: 假设平均URL长度为100字节（包括短URL和长URL），则10年总存储需求为 3650亿 * 100 字节 = 36.5 TB。 这是一个相当可观的数据量，需要选择合适的存储方案。
• 高可用性、可扩展性、容错性: 作为一项基础服务，URL短链服务必须具备高可用性（7x24小时稳定运行）、可扩展性（能够应对未来流量增长）和容错性（在部分组件故障时仍能正常服务）。

3. 封底估算

在系统设计初期进行封底估算（Back-of-the-Envelope Estimation）非常关键。它帮助我们快速评估系统规模，识别潜在瓶颈，并指导后续的设计方向。上述的流量和存储容量估算就是典型的封底估算。

高层设计：架构蓝图

在明确了需求和范围之后，进入高层设计阶段，勾勒出系统的整体架构蓝图。

1. API 端点设计

API (Application Programming Interface) 是客户端与服务器交互的桥梁。对于URL短链服务，需要设计简洁、易用的API端点。采用 RESTful API 设计风格是一个不错的选择。RESTful API 以资源为中心，使用标准的HTTP方法（GET, POST, PUT, DELETE 等）进行操作。

• URL缩短 API (POST /api/v1/data/shorten):

  • 请求方法: POST
  • 请求路径: /api/v1/data/shorten
  • 请求参数: longURLString (长URL字符串)，通常放在请求体 (Request Body) 中。
  • 响应: 返回生成的短URL。

• URL重定向 API (GET /api/v1/shorten/{shortURL}):

  • 请求方法: GET
  • 请求路径: /api/v1/{shortURL}，其中 {shortURL} 是短URL的路径部分，例如 y7keocwj。
  • 响应: 返回原始的长URL。

2. URL 重定向机制

当用户在浏览器中输入短URL（例如 https://tinyurl.com/y7keocwj）并访问时，浏览器会向URL短链服务发起一个GET请求。服务器接收到请求后，需要将短URL解析，找到其对应的长URL，并进行重定向。

这里，需要选择合适的HTTP重定向状态码：

• 301 永久重定向 (Moved Permanently): 301 重定向表示请求的URL已永久移动到新的URL（即长URL）。浏览器在接收到301响应后，会缓存这个重定向关系。后续对同一短URL的请求，浏览器将直接从缓存中读取长URL，并直接跳转，而不会再次请求URL短链服务。

  • 优点: 减轻服务器压力，提升性能，因为只有首次请求会到达服务器。
  • 适用场景: 当短URL与长URL的映射关系长期稳定不变时，适合使用301重定向。

• 302 临时重定向 (Found): 302 重定向表示请求的URL只是临时移动到新的URL。浏览器不会缓存302重定向响应。每次访问短URL，浏览器都会先请求URL短链服务，服务器再返回302重定向到长URL。

  • 优点: 便于进行点击统计和分析。每次短URL被访问，服务器都能记录到。
  • 缺点: 服务器压力较大，性能相对较低，因为每次请求都需要经过URL短链服务。
  • 适用场景: 当需要追踪点击量、分析用户行为（例如点击来源、时间等）时，可以使用302重定向。

对于 tinyurl.com 这样的URL短链服务，301 重定向通常是更合适的选择。因为其主要目标是提供高效的URL缩短和重定向服务，减少服务器负载，提升用户访问速度。如果需要进行详细的点击分析，可以考虑其他方案，例如在重定向前，先通过消息队列异步记录点击事件。

(展示了用户访问短URL tinyurl.com 时的重定向流程：浏览器发送请求到服务器，服务器查找短URL对应的长URL，并使用301重定向返回给浏览器。)

3. 短URL生成 (URL Shortening) 流程

如何将长URL映射为短URL？一个初步的想法是使用哈希表（Hash Table）。可以将短URL作为键（Key），长URL作为值（Value）存储在哈希表中。当需要重定向时，根据短URL在哈希表中查找对应的长URL。

然而，仅仅使用哈希表作为数据存储方案是不够的，主要有以下几个原因：

• 内存限制: 哈希表通常存储在内存中，而内存容量有限且昂贵。对于需要存储数千亿条URL映射关系的服务来说，内存是无法满足需求的。
• 持久性需求: 内存中的数据是非持久化的，一旦服务重启或宕机，数据就会丢失。URL短链服务需要持久化存储URL映射关系，以便长期稳定运行。

因此，需要更合适的持久化存储方案，例如关系型数据库（如MySQL, PostgreSQL）或NoSQL数据库（如Redis, Cassandra, HBase 等）。在详细设计中，将深入探讨数据模型和短URL生成算法。

核心组件

在高层设计的基础上，进一步深入到核心组件的设计细节，包括数据模型、哈希函数、URL缩短算法和URL重定向的具体实现。

1. 数据模型：关系型数据库设计

考虑到数据持久性、事务支持和成熟的技术生态，关系型数据库是存储URL映射关系的良好选择。可以设计一个简单的数据库表，例如命名为 URL_MAPPING。

(图4 展示了一个简化的数据库表 URL_MAPPING 设计，包含三列：id (主键，自增ID), shortURL (短URL字符串), longURL (原始长URL字符串)。)

• id (BIGINT, Primary Key, Auto Increment): 作为主键，使用自增的BIGINT类型，保证唯一性和高效索引。它不仅是表的主键，也将作为生成短URL的基础。
• shortURL (VARCHAR(255), Unique Index): 存储短URL字符串，例如 "y7keocwj"。设置为唯一索引，确保短URL的唯一性，并加速根据短URL查找长URL的查询。
• longURL (TEXT): 存储原始的长URL，使用TEXT类型可以存储较长的URL字符串。

2. 哈希函数与短URL生成算法

核心问题是如何将长URL高效、唯一地映射为短URL。内容中探讨了两种主要的哈希函数方法：

• 方法一：哈希 + 碰撞解决 (Hash + Collision Resolution)

  • 思路: 使用传统的哈希函数（如 CRC32, MD5, SHA-1）将长URL哈希成一个固定长度的哈希值。然后，截取哈希值的前N个字符作为短URL。

  • 哈希值长度确定: 根据之前估算的10年3650亿条URL记录，需要确定短URL的最小长度。短URL由62个字符 (0-9, a-z, A-Z) 组成。计算不同长度n对应的最大URL数量 (62^n)：

    
    (表展示了短URL长度 n 与其能支持的最大URL数量的对应关系。当 n=7 时，62^7 ≈ 3.5万亿，足以支持3650亿条URL。)

    因此，短URL长度至少需要7位。

  • 碰撞问题与解决: 哈希函数可能产生碰撞（不同的长URL哈希到相同的哈希值）。为了解决碰撞，一种方法是附加前缀字符串重试。
    
    (图描述了哈希碰撞解决的流程：首先尝试使用哈希函数生成短URL，如果短URL已存在（碰撞），则在原始长URL上添加一个前缀字符串，再次进行哈希，重复此过程直到生成一个未被使用的短URL。)

    这种方法虽然可以解决碰撞，但效率较低，每次生成短URL可能需要多次数据库查询以检查碰撞。布隆过滤器 (Bloom Filter) 可以用于优化碰撞检查过程，减少数据库查询次数。布隆过滤器是一种概率型数据结构，可以快速判断一个元素是否可能在一个集合中。虽然布隆过滤器可能存在误判（将不存在的元素判断为存在），但可以大大减少不必要的数据库查询。

• 方法二：基数 62 转换 (Base 62 Conversion)

  • 思路: 使用一个唯一ID生成器生成全局唯一的ID（例如自增ID或分布式ID生成器）。然后，将这个ID看作一个十进制数字，将其转换为 基数 62 表示。基数 62 使用 0-9, a-z, A-Z 这62个字符来表示数字。

  • 基数 62 转换过程示例: 将十进制数 111571 转换为基数 62。

    
    (图展示了将十进制数 111571 转换为基数 62 的过程。通过不断地除以 62 并取余数，得到基数 62 的表示 [2, 7, 55, 59]，对应基数 62 编码 "2TXK" (假设 55 对应 'X', 59 对应 'K')。)

    最终得到的基数 62 编码字符串就是短URL的 Hash Value 部分。例如，ID 2009216747938 转换为基数 62 为 "zn9edcu"。

  • 优点:

    • 保证唯一性: 由于ID生成器生成的是唯一ID，基数 62 转换后的短URL也是唯一的，不会发生碰撞。
    • 容易生成下一个短URL: 如果ID是递增的，可以很容易预测下一个生成的短URL。但这可能带来安全问题（容易被遍历）。

  • 缺点:

    • 短URL长度不固定: 短URL的长度取决于ID的大小。ID越大，短URL越长。但通常情况下，ID增长速度是可控的，短URL长度不会过长。
    • 安全性: 如果ID是顺序递增的，攻击者可能会预测短URL的生成规律，批量生成短URL。可以使用更复杂的ID生成策略，例如 UUID 或 分布式ID生成器（Snowflake 算法等），提高安全性。
  • 基数 62 转换方法是更适合URL短链服务的方案。 它保证了短URL的唯一性，实现简单高效，且易于理解和维护。

3. URL 缩短流程详解 (使用基数 62 转换)

![[iamge]](https://wenzuojing.oss-cn-beijing.aliyuncs.com/screenshot_173...)
(图详细描述了使用基数 62 转换的 URL 缩短流程。)

1. 接收长URL: 客户端发送 POST 请求到 /api/v1/data/shorten，携带 longURLString。

2. 检查长URL是否已存在: 在 URL_MAPPING 表中查询 longURL 列，检查该长URL是否已经被缩短过。

   • 如果已存在: 直接从数据库中获取已存在的 shortURL 并返回给客户端。避免重复生成短URL，提高效率。
   • 如果不存在: 继续下一步。
3. 生成唯一ID: 调用分布式唯一ID生成器获取一个新的唯一ID。
4. 基数 62 转换: 将生成的唯一ID转换为基数 62 编码，得到 hashValue (短URL的后半部分)。
5. 构建短URL: 将域名 (例如 https://tinyurl.com/) 与 hashValue 拼接，生成完整的短URL。
6. 保存到数据库: 在 URL_MAPPING 表中插入一条新记录，包含 id (唯一ID), shortURL, longURL。
7. 返回短URL: 将生成的 shortURL 返回给客户端。

4. URL 重定向流程详解

(图详细描述了 URL 重定向流程，包括缓存的使用。)

1. 用户访问短URL: 用户点击或输入短URL (例如 https://tinyurl.com/zn9edcu)。
2. 负载均衡器 (Load Balancer): 请求首先到达负载均衡器。负载均衡器将请求分发到后端的 Web 服务器集群中的某一台服务器。
3. Web 服务器: Web 服务器接收到请求。

4. 缓存查找 (Cache Lookup): Web 服务器首先在缓存 (Cache) 中查找短URL对应的长URL。

   • 如果缓存命中 (Cache Hit): 直接从缓存中获取长URL，并进行 301 重定向。缓存提升了读取性能，减少数据库压力。
   • 如果缓存未命中 (Cache Miss): 继续下一步。

5. 数据库查询 (Database Query): Web 服务器查询数据库 URL_MAPPING 表，根据 shortURL 查找 longURL。

   • 如果数据库中找到: 将 longURL 从数据库中取出，更新缓存 (Cache Update)，将 <shortURL, longURL> 键值对放入缓存，并进行 301 重定向到 longURL。
   • 如果数据库中未找到: 说明短URL无效或不存在，返回错误响应 (例如 HTTP 404 Not Found)。
6. 返回重定向响应: Web 服务器返回 301 重定向响应，将客户端浏览器重定向到长URL。

5. 分布式唯一ID生成器

在分布式系统中，生成全局唯一ID是一个常见的挑战。对于URL短链服务，需要一个能够生成高并发、低延迟、全局唯一ID的组件。常见的分布式ID生成方案包括：

• UUID (Universally Unique Identifier): UUID 由算法生成，保证全局唯一性，但UUID通常较长，且无序，不适合作为短URL的一部分，但可以作为数据库表 id 列的备选方案。
• 数据库自增ID: 在单数据库场景下可行，但在分布式数据库或高并发场景下，数据库自增ID可能成为瓶颈。
• Snowflake 算法: Twitter 开源的分布式ID生成算法，生成 64 位的ID，包含时间戳、机器ID、数据中心ID、序列号等信息，保证全局唯一性和趋势递增性，性能高，可靠性好。Snowflake 算法是更适合分布式URL短链服务的ID生成方案。
• Redis INCR/原子计数器: 利用 Redis 的原子递增操作生成唯一ID。Redis性能高，但需要考虑Redis的可用性和持久化。

总结与扩展

讨论了API设计、数据模型、哈希函数选择、URL缩短和重定向流程，以及分布式唯一ID生成器等核心组件。

• 需求分析: 明确功能性和非功能性需求，进行流量和存储容量估算。
• 架构设计: 设计API端点，选择合适的重定向策略 (301 或 302)，初步考虑数据存储方案。
• 设计核心组件: 数据库模型设计、哈希函数 (基数 62 转换) 选择、URL缩短和重定向流程、缓存使用、分布式ID生成器。
• 性能、可扩展性、可用性: 缓存提升性能，负载均衡和数据库扩展提高可扩展性，冗余部署和容错设计保证可用性。

扩展 :

• 速率限制 (Rate Limiting): 防止恶意用户或爬虫 Flood 攻击，限制IP地址或用户在单位时间内请求URL缩短的频率。可以使用令牌桶 (Token Bucket) 或 漏桶 (Leaky Bucket) 算法实现速率限制。
• Web 服务器扩展: Web 服务器层是无状态的，容易通过水平扩展 (增加服务器数量) 来提高处理能力。可以使用负载均衡器 (Load Balancer) 将请求分发到多台 Web 服务器。
• 数据库扩展: 数据库是瓶颈点。可以采用数据库复制 (Database Replication) (读写分离，提高读取性能和可用性) 和 数据库分片 (Database Sharding) (将数据分散到多个数据库实例，提高写入性能和存储容量) 等技术进行扩展。
• 分析与监控 (Analytics & Monitoring): 集成分析功能，例如统计短URL的点击量、点击来源、用户地域分布等，为运营决策提供数据支持。完善的监控系统对于及时发现和解决问题至关重要。
• 可用性、一致性、可靠性 (Availability, Consistency, Reliability): 在分布式环境下，需要权衡 CAP 理论 (一致性、可用性、分区容错性)，根据业务需求选择合适的策略。例如，对于URL短链服务，可用性通常比强一致性更重要。

参考资料
ByteByteGo