目录
短一点的链接
发送短信应该短一点,美观,节省空间
短链生成的二维码密集度更低,更容易被识别。如图示:
链接太长无法发送
长链接在QQ微信或钉钉上中间断开了,很不友好
访问短链 按照长链 给响应请求
访问短链,重定向到长链
一般使用,重定向302
301永久重定向,即浏览器只需要第一次请求拿到长链接后,下次再去访问这个短链就不会向短网址服务器请求了,而是直接从浏览器的缓存里拿。这样可以提高浏览器的访问速度,但是也有一个问题,就是如果我们想统计活动链接的访问数据的话就无从下手了。或者是这个活动结束了我想删除访问入口,但由于浏览器缓存可能还会导致有用户访问到。所以我们一般不使用301。
302 临时重定向,即每次访问短链都会去请求短网址服务器(除非响应中用 Cache-Control 或 Expired 暗示浏览器缓存),这样就便于 server 数据监控,所以虽然用 302 会给 server 增加一点压力,但明显是利大于弊的。
基本能力:
调用流程:
方案分析:
解决痛点:
根据短链获取长链 或者 根据长链获取短链:使用类似HashMap的get算法,先根据HashCode查询,然后再根据短链文本查询
逻辑:
分析:
解决:使用redis能解决这两个问题
扩展:当然也可以使用MD5替代HashCode,也可以。
无论使用啥样的Hash算法,都可能会冲突。
为了这种冲突就需要解决,一个Code对应多文本场景。
根据长链找短链场景:
{ “HashCode”:[ {唯一ID,LongUrl,ShortUrl}, {唯一ID,LongUrl,ShortUrl} ], } |
优点是查询性能高,可以抗量,且自带过期机制
缺点是需要维护结构关系稍显繁琐复杂
如果能保障 URL和Hash值 1:1关系,数据结构稍微简单点,也需要维护多个kv关系
估计大部分会选择这种方法。
前提:
分析:
存储kv对:
1. Web是局限
2. OpenResty直接请求Redis
END