系统设计.短链系统设计

目录

啥是短链

为啥需要短链

短链原理

301 和 302 的区别

短链系统

方案演进

直接记录 长链和短链映射表，直接查询

存储映射关系，用HashCode优化查询效率

 Redis替代DB存储映射关系

长短1:1场景改进方案

 百万高性能短链系统

---

啥是短链

短一点的链接

为啥需要短链

发送短信应该短一点，美观，节省空间 

短链生成的二维码密集度更低，更容易被识别。如图示：

链接太长无法发送

长链接在QQ微信或钉钉上中间断开了，很不友好

短链原理

访问短链 按照长链 给响应请求

访问短链，重定向到长链

一般使用，重定向302

301 和 302 的区别

301永久重定向，即浏览器只需要第一次请求拿到长链接后，下次再去访问这个短链就不会向短网址服务器请求了，而是直接从浏览器的缓存里拿。这样可以提高浏览器的访问速度，但是也有一个问题，就是如果我们想统计活动链接的访问数据的话就无从下手了。或者是这个活动结束了我想删除访问入口，但由于浏览器缓存可能还会导致有用户访问到。所以我们一般不使用301。

302 临时重定向，即每次访问短链都会去请求短网址服务器（除非响应中用 Cache-Control 或 Expired 暗示浏览器缓存），这样就便于 server 数据监控，所以虽然用 302 会给 server 增加一点压力，但明显是利大于弊的。

短链系统

基本能力：

1. 生成短链：根据长链 获取 短链，并记录
2. 找到长链：根据短链 映射 长链
3. 查询是否已生成：根据长链 查短链
4. 超时过期：短链 超时清理机制

调用流程： 

方案演进

直接记录 长链和短链映射表，直接查询

方案分析：

1. 短链 生成 跟 长链 关系不大，使用二维表记录映射关系
2. 长链，短链 是字符串，创建索引性价比不高
3. 并发有数据库查询效率为瓶颈
4. 过期时间需要额外实现

解决痛点：

1. 路径1：存储映射关系，将短链和长链 做Hash计算，而后简历索引。查询的时候，先根据HashCode查询，然后再根据文本查询
2. 路径2：存储映射关系，可以使用redis实现
3. 路径3：让长短链 有逻辑关系，可以使用短链直接还原出长链

存储映射关系，用HashCode优化查询效率

根据短链获取长链 或者 根据长链获取短链：使用类似HashMap的get算法，先根据HashCode查询，然后再根据短链文本查询

逻辑：

1. 根据长找短场景：
   1. 长链 计算 得到HashCode值
   2. 根据HashCode值查询，然后在查询的列表，再根据 文本查询
2. 根据短找长场景：
   1. 短链 计算 得到HashCode值
   2. 根据HashCode值查询，然后在查询的列表，再根据 文本查询

分析：

1. 数据库性能瓶颈依然存在
2. 过期时间需要额外逻辑保证

解决：使用redis能解决这两个问题

扩展：当然也可以使用MD5替代HashCode，也可以。

 Redis替代DB存储映射关系

无论使用啥样的Hash算法，都可能会冲突。

为了这种冲突就需要解决，一个Code对应多文本场景。

根据长链找短链场景：

1. 长链 计算Hash值
2. 根据Hash值获取value，value应该是一个列表，且需要存储长短链
3. 数据结构：

{     “HashCode”:[        {唯一ID,LongUrl,ShortUrl},        {唯一ID,LongUrl,ShortUrl}     ]， }

1. 1:M场景 超时机制稍微借助逻辑实现
   1. 唯一ID作为key设置expire过期时间
   2. 查询到“唯一ID”需要判断是否过期

优点是查询性能高，可以抗量，且自带过期机制

缺点是需要维护结构关系稍显繁琐复杂

如果能保障 URL和Hash值 1:1关系，数据结构稍微简单点，也需要维护多个kv关系

估计大部分会选择这种方法。

长短1:1场景改进方案

前提：

1. URL和Hash值 1:1关系
2. 只对长链做Hash值，短链比较短就直接查询吧
3. 使用redis实现

分析：

1. URL根据Hash算法直接计算
2. 冲突解决：短链需要判重，如果重复则长链添加固定字符串后继续计算短链判重
3. 判重优化：可以使用布隆过滤器判断短链是否已经有了
4. hash算法可以是：MD5,SHA加密算法；非加密型MurmurHash 算法

存储kv对：

1. 长 Code 》 短
2. 短 》长

 百万高性能短链系统

1. Web是局限

    

 2. OpenResty直接请求Redis

---

END