短链接URL设计

• 前言
• 一、需求分析
  • • 基本流程
    • 功能分析
    • 性能分析
    • 非功能需求
• 二、概要设计
  • • 短URL如何生成
    • 整体架构图
    • 调用流程图
      • 未命中
• 三、详细设计
  • • 重定向响应码详细设计
    • 短URL预生成文件加载及读取详细设计
    • 用户自定义短URL详细设计

前言

长URL分享冗长用户体验很差，期望一个更短的URL，点击短URL映射跳转到实际地址。

产品命名：”Fuxi（伏羲）“

一、需求分析

基本流程

功能分析

性能分析

1. 总存储量

   预计每月生成5亿条，有效期2年，因此总URL数量120亿

   短URL存储空间：按照每个URL1KB则一共12TB=1KB*120亿

2. 吞吐量

   1. QPS

      每个短URL平均读100次

      5亿 * 100 / (30 * 24 * 60 * 60) ≈ 2万

      一般系统高峰期访问量是平均的2倍，因此需要支持4万

   2. TPS

      写相比读来说预计量级很小，按照10:1来算，TPS 2千

3. 网络带宽

   1. 根据返回长URL的平均长度来估算

      平均每个长度URL500B，HTTP响应头500B，所以每个响应1KB。

      因此需要的带宽为320Mb=4万 * 1KB * 8bit = 40MB * 8bit

非功能需求

1. 高可用。不能因为某台服务器、数据库宕机导致的服务不可用
2. 高性能。TP80请求小于5ms，TP99小于20ms
3. 短URL生成是随机的，用户不可猜测

二、概要设计

短URL如何生成

1. MD5后base64编码后，截取前6位。（前6位可能冲突，还得需要反查，性能不符合要求）
1. 自增URL。（不满足用户不可猜测的需求）
1. 预生成。（离线预生成，每次读取到内存1W，性能满足要求，且离线生成是随机的，满足用户不可猜测的需求）

整体架构图

调用流程图

未命中

三、详细设计

重定向响应码详细设计

301：重定向一次后浏览器缓存，下次浏览器直接访问原URL

302：每次都访问短链URL服务器

因为QPS服务器能承受住，且301则后续的访问服务器完全无感知、无记录，为了统计因此选择302

短URL预生成文件加载及读取详细设计

预加载服务器集群，每次读1W存与内存中，短链服务器访问则直接返回，当个数小于2000时，单机加锁再去取1W个

过期则将过期的随机编码追加进HDFS中以供后续使用

用户自定义短URL详细设计

不能用6位长度的，防止与后续要使用的冲突