关于URL缩短器以及互联网上其他地方的stackoverflow，这里有很多问题，例如。
How do URL shortener calculate the URL key? How do they work?
http://www.codinghorror.com/blog/2007/08/url-shortening-hashes-in-practice.html
然而，有一件事我不明白。例如，http://goo.gl目前使用四个字符。但是，他们声称他们的短网址不会过期。正如关于编码恐怖的文章中所提到的，如果他们无法回收URL，唯一可能的解决方案是在某一点上添加一个额外的角色。
好的，到目前为止一切顺利。 4个字符表示大约1500万个唯一地址。对于像谷歌地图这样的东西，我认为这不是很多，如果你不能回收，我猜他们很快就用完了可用的地址。
现在对于我没有得到的部分。在分发地址时，它们开始耗尽未使用的地址。他们必须检查是否尚未发布新生成的地址。这种情况发生的可能性和地址已经在使用中增加了。当然，直接的解决方案是一遍又一遍地生成一个新的URL，直到他们找到一个免费的URL，或直到他们生成了所有150万个替代品。然而，这肯定不是他们实际上如何做到这一点，因为这将是非常耗时的。那么他们如何管理呢？
此外，可能有多个访问者同时要求提供一个简短的URL，因此他们也必须进行一些同步。但是，当需要添加第五个字符时，应如何管理这种情况呢？
最后，在对http://goo.gl的网址工作进行一些研究时，我当然多次在Google地图上为地图申请了一个简短的网址。它们都不会被使用。但是，当Google严格执行一旦发布的URL未到期的策略时，这意味着系统中存在大量的休眠URL。我再次假设谷歌（以及其他服务）也提出了解决这个问题的方法。我可以设想一个清理服务，它可以回收创建后48小时内未访问过的URL，或者在第一周内回收不到10次的URL。我希望有人也能对这个问题有所了解。
简而言之，我得到了URL缩短器的一般原则，但是当这些URL无法过期时，我发现了几个问题。有谁知道上面提到的问题是如何解决的，还有其他问题吗？
修改
好的，所以this博客文章揭示了一些事情。这些服务不会随机生成任何内容。它们依赖于底层数据库的自动增量功能，并对结果id应用简单转换。这消除了检查id是否已经存在（它没有）并且数据库处理同步的需要。这仍然使我的三个问题中的一个没有答案。这些服务如何“知道”链接是否在创建后实际使用？
答案 0 :(得分：31)
<强> Why URL shorteners don't delete entries
我确实写过TinyURL（十年前），以回馈我不需要的条目。他们的回答让我意识到我是多么荒谬：他们告诉我“只需创建你需要的所有网址”。这些数字说明了一切：
A - 26个小写+ 26个大写字母+10个数字（选择合理的网站），使用一个字符可以给你62个位置（即62个缩短的URL），然后每个 char 将位置编号乘以 62：
B - 实际上，需求和用途低于人们的预期。很少有人创建短网址，每个人创建的网址很少。在大多数情况下，原始URL就足够了。结果是，经过多年的努力，最受欢迎的缩短产品仍然只需4或5个字符即可满足今天的需求，而在需要时添加另一个产品将几乎为零。显然goo.gl和goo.gl/maps每个都使用5个字符，youtube使用11个字符（使用上面的62个字符，加上短划线以及其他一些字符）。
C - 托管（存储+运营）URL的成本，例如，1Tyrabyte每年1000美元，每个TB可以包含50亿个URL，因此1个URL的成本为0.2微美元/年。然而，Shortener的好处也很薄，因此业务不是很强劲。对于用户来说，URL的好处很难评估，但错过的链接的成本远远高于托管。
D - 如果用户有可能在未来几年内失效，那么用户就没有必要创建一个短网址，因此持久性是Shortener的主要吸引力，严重的Shortener可能永远不会停止为他们服务，除非他们被迫停业;然而这种情况已经发生了，无论如何，短网址都有其缺点和好处，在Wikipedia "URL shortening"（各种黑客攻击，针对用户，目标网站或Shortener的风险）中都有解释;例如人们可以通过机器人请求giga数量的URL来攻击Shortener，大多数Shorteners肯定会阻止这种威胁。
Versailles，2013年3月12日星期二20:48:00 +0100，编辑21:01:25