为什么使用短链接
在互联网应用开发运行过程中，必会使用到URL短链系统。那为什么需要把原始的长URL转换成短链给用户使用呢？
节省发送的内容#
我们平时发微博或者短信是都是有最大字符限制的。如果你的一个URL太长，一个URL占用的字符数就已经超过了最大限制，根本发不出去。如果你细心观察过银行的信用卡中心给你发过来的活动短信的话，你会发现短信中的URL好多都是以短链接形式发送的。
提升用户体验#
还是以上面的URL为列子。这一大串URL非常不美观，给人的感觉就是木马链接，用户可能都不会去点击。相反的，如果转换成http://url.cn/5MMEX3D，就非常易于阅读，看起来整洁干净，提高用户体验和点击率。
便于链接追踪，分析点击来源#
通过短链接可以获知大部分用户的来源，和来源渠道的转化率、广告渠道的质量。通过渠道效果对比数据，更合理的进行广告投放和资源配置。
同一个页面不同的链接#
每个用户需要推送带参数的唯一链接。
一定程度上保护原始网站链接#
我们在玩Facebook，领英等社交时，有些需要分享一些带有我们网站链接的帖子和消息，尤其对于小白来说，如果发的内容次数过多，并且毫无互动可言或者直接被人举报多次，那么你的网址就会被社交平台标记，一旦标记，链接权重就会受影响，后面再投社交广告时就有麻烦了。但是如果我们使用短链接就不会影响原始网站。
长链转短链方式
哈希法生成短链
为了缩短一个长URL，我们需要实现一个哈希函数将长URL哈希成7个字符的字符串。最直接的解决方案是使用那些有名的哈希函数，比如CRC32、MD5或者SHA-1等。下面的表比较了对长URL“https://en.wikipedia.org/wiki/Systems_design”使用不同哈希函数的结果。
即使是最短的哈希值（通过CRC32算法得到）都太长了（超过7个字符）。怎么能让它变得短一些呢？第一个方法是取哈希值的前7个字符，但是这个方法会导致哈希冲突(Hash Collision)。为了解决哈希冲突，我们可以递归地添加一个新的预先设定好的字符串，直到不再发现冲突为止。下图解释了这个过程。
这个方法可以消除哈希冲突，但是对每一个请求都要查询数据库以检查是否存在对应的短URL，这个成本是很高的。一种叫作布隆过滤器的技术可以提升性能。布隆过滤器是一种高效利用空间的概率性技术，可以用来检测一个元素是否属于某个集合。
自增ID生成短链
除了哈希法，我们还可以使用自增ID来生成短链。这种方法相对简单，就是维护一个自增ID，每创建一个短链，ID就增加1。然后，我们可以将ID转换为62进制（使用数字和大小写字母），这样就可以得到一个较短的字符串作为短链。
自增ID法的优点是实现简单，且可以有效避免哈希冲突。但是，它也有一个缺点，那就是ID的分配和回收问题。我们需要确保ID的唯一性，并在链接删除时回收ID，以避免ID的浪费。
比较两种方法
一对一还是一对多映射？
一个长网址，对应一个短网址，还是可以对应多个短网址？ 这也是个重大选择问题
一般而言，一个长网址，在不同的地点，不同的用户等情况下，生成的短网址应该不一样，这样，在后端数据库中，可以更好的进行数据分析。如果一个长网址与一个短网址一一对应，那么在数据库中，仅有一行数据，无法区分不同的来源，就无法做数据分析了。
以这个7位长度的短网址作为唯一ID，这个ID下可以挂各种信息，比如生成该网址的用户名，所在网站，HTTP头部的 User Agent等信息，收集了这些信息，才有可能在后面做大数据分析，挖掘数据的价值。短网址服务商的一大盈利来源就是这些数据
数据存储
数据存储是短链系统的核心部分，它负责存储链接映射关系及相关数据。那么，如何设计一个高效、稳定的数据存储方案呢？
1、选择合适的存储介质：我们可以选择关系型数据库、NoSQL数据库或内存存储等作为存储介质。关系型数据库适合存储结构化数据，NoSQL数据库适合存储非结构化数据，而内存存储则适合存储需要高速访问的数据，比如说设计短链系统，其实redis这类kv存储是很合适的，可以抗高并发，通过集群部署也可以抗海量数据。
2、设计合理的数据表结构：无论选择哪种存储介质，我们都需要设计合理的数据表结构来存储链接映射关系及相关数据。比如，我们可以设计一个“链接表”，其中包含长链接、短链、创建时间、访问次数等字段。
3、考虑数据备份与恢复：为了确保数据的可靠性和稳定性，我们需要考虑数据的备份与恢复策略。比如，我们可以定期备份数据，并在数据丢失或损坏时及时恢复。
重定向：短链系统的“桥梁”如何搭建
重定向服务是短链系统的另一个核心部分，它负责处理短链接的重定向请求。那么，当一个短链请求过来时，系统是如何把它转为长链并重定向到长链地址去的呢？因为用户拿到的短链访问的时候肯定是访问我们的短链系统的，这个时候我们要把短链转为长链让他们访问真实地址。
1、解析短链
当用户访问一个短链时，系统首先需要对短链进行解析。这包括验证短链的有效性、解析出短链中的哈希值或唯一标识符等。
2、查找长链接
通过解析出的哈希值或唯一标识符，在链接存储服务中查找对应的长链接。这通常涉及到数据库的查询操作。
3、生成重定向响应
一旦找到了对应的长链接，系统就会生成一个HTTP重定向响应，将用户的浏览器重定向到原始的长链接地址。这样，用户就能够访问到原始的内容或页面了。在生产重定向响应的时候需要根据场景使用301或者302
301是永久重定向，302是临时重定向。短地址一经生成就不会变化，所以用301是符合http语义的。但是如果用了301， Google，百度等搜索引擎，搜索的时候会直接展示真实地址，那我们就无法统计到短地址被点击的次数了，也无法收集用户的Cookie, User Agent 等信息，这些信息可以用来做很多有意思的大数据分析，也是短网址服务商的主要盈利来源。
4、考虑高并发优化
为了提高重定向服务的性能，我们可以考虑使用Nginx等技术进行高并发优化。比如，我们可以将重定向服务内嵌写入多个Nginx节点上。这样，当用户访问短链时，就可以快速地将请求分发到多个节点上进行处理，从而提高系统的并发处理能力。
5、预防攻击
如果一些别有用心的黑客，短时间内向TinyURL服务器发送大量的请求，会迅速耗光ID，怎么办呢？
首先，限制IP的单日请求总数，超过阈值则直接拒绝服务。
光限制IP的请求数还不够，因为黑客一般手里有上百万台肉鸡的，IP地址大大的有，所以光限制IP作用不大。
可以用一台Redis作为缓存服务器，存储的不是 ID->长网址，而是 长网址->ID，仅存储一天以内的数据，用LRU机制进行淘汰。这样，如果黑客大量发同一个长网址过来，直接从缓存服务器里返回短网址即可，他就无法耗光我们的ID了。
短链系统的架构概览
一般来说，短链系统包括以下几个核心部分：
短链生成器：负责将长链接转换为短链接。这是短链系统的“门面”，也是用户最直观感受到的部分。
链接存储服务：用于存储链接映射关系及相关数据。这是短链系统的“大脑”，负责记忆和管理所有的链接信息。
重定向服务：处理短链接的重定向请求，确保用户能够顺利访问到原始链接。这是短链系统的“桥梁”，连接着用户和原始内容。
监控与统计服务：
收集和统计链接的访问数据，为业务分析和优化提供有力支持。
这是短链系统的“眼睛”，帮助运营者了解系统的运行状况和用户行为。
评论区