1.使用场景微博和推特都有140字的限制。如果分享的网址很长，很容易超过限制，而且长链接也太占空间了。更多字符空间，无法编辑更多内容。另外，国内微信、淘宝等很多平台之间无法互通，平台之间或多或少存在相互屏蔽行为。同时，还有一个重要的因素。在我们日常的网络营销中，营销活动发起后，很难跟踪用户和效果。基于这些种种因素，最终导致了今天短链接的盛行。2、短链接有多短？既然短链接这么重要，那么短链接生成器应该多短呢？目前世界上有70亿人，假设每个人都有一个网页的基础，那么就已经有70亿个网页链接了。目前如果按照二进制32位的字符来计算，2^{32}=4294967296232，这个数据70亿是远远不够的，但是也远小于64位的上限，所以一个64位就够了.微博的短网址服务使用了一个长度为7的字符串，这个字符串可以看作是一个62进制数，所以最多可以表示{62}^7=3521614606208627=3521614606208个网址，远远大于上限70亿，7位字符串是目前短链接比较通用的标准。3.如何将64位整数转换成字符串如何将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个字母组成。4.核心算法及原理介绍核心算法是十进制转62：$结果='';做{$result=$dict[$dec%62]。$结果；$dec=intval($dec/62);}while($dec!=0);返回$结果；}原理：以0ut为例：0ut短链接压缩后生成长链接，短链接是如何工作的？下面是短链接生成原理的解释：请求一个短链接，跳转到原链接的流程图：5、如何存储短URL和长URL的对应关系？以短URL为主键，长URL为值，可以存储在传统的关系型数据库，如MySQL、PostgreSQL，或任何分布式KV数据库，如Redis、LevelDB。如果你心痒痒想手动设计这个存储，那就是另外一个话题了。你需要完全构建一个KV存储引擎轮子。目前比较流行的KV存储引擎有LevelDB和RockDB，可以了解一下它们的源码。6.短链接重定向这是一个有趣的问题。主要看你对301和302的理解，以及你对浏览器缓存机制的理解。301是永久重定向，302是临时重定向。短链接一旦生成就不会改变，所以使用301是符合http语义的。但是，如果你使用301、谷歌、百度等搜索引擎，搜索时会直接显示真实地址，那么我们将无法统计短地址被点击的次数，也就无法收集用户的Cookie、UserAgent等信息，可以用来做很多有意义的大数据分析，也是短网址服务商的主要盈利来源，所以应该选择302重定向。这里有兴趣的朋友可以去看看m1.fit短链接平台是怎么做的。你可以看看新浪微博的短链接，通过抓包查看返回的结果，就可以知道新浪微博是用什么的了。这是一个302临时重定向。七、如何防范攻击如果一些别有用心的黑客在短时间内向TinyURL服务器发送大量请求，ID会很快耗尽，怎么办？首先，限制单日IP请求总数，超过阈值直接拒绝服务。当然，限制IP请求数量肯定是不够的，因为黑客手中一般都有数以百万计的bot，拥有庞大的IP地址池，单靠限制IP是不行的。我们可以用一个Redis作为缓存服务器，存储的不是ID->longURL，而是longURL->ID，只存储一天以内的数据，使用LRU机制淘汰。这样，如果黑客发送大量相同的长URL，他可以直接从缓存服务器返回短URL，就用不完我们的ID。当然，我们也可以设置更多的安全机制来防止攻击，可以灵活运用。根据上面的简单描述，相信大家应该对短链接生成器这样的短链接平台有了一定的了解。其实只要了解原理，我们都可以制作自己的短链接生成器和短网址平台，如果大家有什么好的补充或者建议，可以在下方留言，谢谢！
