一、使用场景(Scenario)
微博和Twitter都有140字数的限制，如果分享一个长网址，很容易就超出限制，同时长链接也占用了太多的字符空间，无法编辑更多的内容。另外，如国内微信、淘宝等等很多平台都是无法互通，平台之间都或多或少存在相互屏蔽的行为。同时，还有一个比较重要的因素，在我们日常网络营销中，当营销活动推出后，却很难去追踪用户与效果，基于这些种种的因素，才最终导致了如今的盛行。
二、短链接多短才合适
短链接既然这么重要，那么，究竟多短才合适呢？目前全球拥有70亿人口，假设每人拥有一个网页的基数，那么已有70亿个网页链接。目前，如果按照2进制32的字符来算的话，2^{32}=4294967296232，这个数据对于70亿是远远不够，但远远小于64位的上限值，那么用一个64位就足够了。微博的短网址服务用长度为7的字符串，这个字符串可以看做是62进制的数，那么最大能表示{62}^7=3521614606208627=3521614606208个网址，远远大于70亿的上限，7位字符串是目前短链接比较通用的标准。
三、如何转换成字符串
一个64位整数如何转化为字符串，假设我们只用大小写字母加数字，那么可以看作是62进制数，log_{62{(2^{64}-1)=10.7log62(264−1)=10.7，即字符串最长11就足够了。但实际，还可以再短一点，比如新浪微博采用的长度就是7，因为 62^7=3521614606208627=3521614606208，这个量级远远超过互联网上的URL总数了，有足够的冗余空间。如今的web服务器（例如Apache, Nginx）大部分都区分URL里的大小写，所以用大小写字母来区分不同的URL是完全没问题的。因此，长度不超过7的字符串，由大小写字母加数字共62个字母组成。
四、核心算法与原理介绍
核心算法是10进制转62进制：
原理：以0ut为例： 先以我的文章链接为例！
在经过0ut短链压缩后，生成短链接： https://m1.fit/1p4b5
这是如何实现的呢？下面为大家讲解下短链接生成原理：
请求短链接，跳转到原链接的流程图：
五、如何存储
如果存储短网址和长网址的对应关系？以短网址为 primary key, 长网址为value, 可以用传统的关系数据库存起来，例如MySQL,PostgreSQL，也可以用任意一个分布式KV数据库，例如Redis, LevelDB。
如果你手痒想要手工设计这个存储，那就是另一个话题了，你需要完整地造一个KV存储引擎轮子。当前流行的KV存储引擎有LevelDB何RockDB，可以去了解它们的源码。
六、短链接重定向
这是个有趣的问题，主要看你对301和302的理解，以及浏览器缓存机制的理解程度，301是永久重定向，302是临时重定向。短链接一经生成就不会变化，所以用301是符合http语义的。但是如果用了301， Google、百度这些搜索引擎，搜索的时候会直接展示真实地址，那我们就无法统计到短地址被点击的次数了，也无法收集用户的cookie、User Agent等信息，这些信息可以用来做很多有意义的大数据分析，也是短网址服务商的主要盈利来源，所以，应该选择302重定向。
在这里，有兴趣的朋友可以去看看https://m1.fit/这个短链接平台是怎么做的，大家可以看看新浪微博的短链接，通过抓包看看返回的结果，就可以知道新浪微博用的就是302临时重定向。
七、如何预防攻击
如果一些别有用心的黑客，短时间内向TinyURL服务器发送大量的请求，会迅速耗光ID，怎么办呢？
首先，限制IP的单日请求总数，超过阈值则直接拒绝服务。当然，光限制IP的请求数量肯定不够，因为黑客一般手里有上百万台肉鸡的，拥有海量的IP地址池，所以光限制IP作用不大。
我们可以用一台Redis作为缓存服务器，存储的不是 ID->长网址，而是 长网址->ID，仅存储一天以内的数据，用LRU机制进行淘汰。这样，如果黑客大量发同一个长网址过来，直接从缓存服务器里返回短网址即可，他就无法耗光我们的ID了。当然，我们还可以设置更多的安全机制来预防被攻击，这都是可以灵活运用的。