一般国内短链接服务使用数据表中的自增id来完成：每次查询数据表中自增id的最大值，对应的长URL的自增id值被插入是max+1，将max+1转换成16进制得到短码。

但是短码id是从一位长度递增的，短码的长度不固定，但是可以用id

从指定的数字开始增加，以确保所有短代码具有相同的长度。同时生成的短码是有序的，可能存在安全问题。生成的短码id可以和长网址等其他关键字进行md5操作，生成最终的短码。

总结算法

摘要算法也称为哈希算法，即任意长度的输入数据和固定长度的输出数据。相同的输入数据总是得到相同的输出，不同的输入数据试图得到不同的输出。

算法过程：

长网址md5会生成一个32位的签名串，分为4段，每段8字节；

对于这四个循环，取8个字节，把它当作16进制字符串和0x3fffffff（30位1)和操作，即忽略30位以上的处理；

30位数字分为6段，每个5位数字作为字母表的索引，得到特定字符，依次得到6位字符串；

总共md5字符串可以得到4个6位字符串；其中任何一个都可以作为这个长url的短url地址；

虽然这个算法会产生4个，但还是有重复的机会。

虽然这种国内短链接服务概率小，但是这种方法还是有冲突的可能，解决冲突会比较麻烦。但是这种方法生成的短码数量是固定的，连续生成的短码没有先后顺序。

普通随机数

这种方法是从62个字符串中随机选择一个6位短码的组合，然后到数据库中检查该短码是否已经存在。如果已经存在，则继续循环该方法再次获取短码，否则直接返回。

这个方法最容易实现，但是由于 Math.round()

该方法生成的随机数是伪随机数，碰撞的可能性不小。在数据量大的情况下，可能会重复多次生成不冲突的短码。

算法分析

我们将一一分析上述算法的优缺点。

如果你使用自增 id 算法，就会出现不法分子可以穷举你的短链地址的问题。原理是将十进制数转换为62，这样别人就可以用同样的方法遍历你的短链，得到对应的原始链接。

这两个短链网站，分别从a3300 - a3399，可以多次尝试并返回正确的url。因此，这种方式生成的短链实际上对用户来说并不安全。

摘要算法实际上是一种哈希算法。说到散列，大家可能觉得很低，但实际上散列可能是最优解。

发现不断生成的url没有规律的国内短链接服务，很有可能是用hash算法来实现的。

普通的随机数算法，这个算法生成的东西和摘要算法一样，但是碰撞的概率会更高。因为摘要算法毕竟是对URL进行hash，而随机数算法就是简单的随机生成，一旦数字上来，难免会导致重复。

结合以上，我选择最低的算法：摘要算法。

实施数据库存储方案

短网址的基本数据以域名和后缀的形式分开存储。另外，域名需要区分HTTP和

HTTPS，哈希方案对整个链接进行哈希处理，而不是对除域名以外的链接进行哈希处理。域名单独保存，可用于分析当前域名下的链接使用情况。

添加当前链接有效性字段。一般来说，短链需求可能是相关活动或热点事件。这条短链会在一段时间内非常活跃，一段时间后景气度会继续下降。所以没有必要永久保留这种链接，增加每次查询的负担。

对于过期数据的处理，可以在添加新短链时判断当前短链的过期日期，在HBase中为每天到达过期日期的数据单独建表，判断过期日期添加新的时。对应的HBase表就够了，每天只处理当天HBase表中的无效数据。

数据库的基本表如下：

字段定义：

base_url：域名

suffix_url：链接除域名外的后缀

full_url：完整链接

shot_code：当前 suffix_url 链接的简码

expiration_date：到期日期

total_click_count：当前链接点击总数

expiration_date：当前链接到期日期

缓存方案

我个人认为在缓存中存储数百个G数据是不合适的，所以有一个折中的解决方案：将最近3个月的查询或新的URL放入缓存，使用LRU算法进行热更新。这样发送最近使用的概率会命中缓存，所以不用去库了。找不到的时候去图书馆更新缓存。

对于新添加的链接，先检查缓存是否存在，如果缓存不存在再检查数据库。数据库已经分表了，查询效率不会很低。

查询要求是用户持有短链查询对应的真实地址，那么缓存的key只能是短链，可以以KV的形式存储。

额外

其实也可以考虑其他的存储方案，比如HBase，作为NOSQL数据库，HBase在性能上仅次于redis，但是存储成本比redis低很多数量级。存储基于HDFS，写入数据时会先写入内存。 ，只有当内存已满时，才会将数据刷新到 HFile 中。读取数据也更快，因为它使用 LSM 树结构而不是 B 或 B+ 树。 HBase 会使用 LRU 算法将最近读取的数据放入缓存中。如果想增强读取能力，可以增加blockCache。

其次，也可以使用ElasticSearch，适当的索引规则的效果并不逊色于缓存方案。

是否需要分库分表？

单条数据小于10b，1亿条数据的总容量约为

953G，单米肯定支持不了这么大的体积，所以需要分米。如果您有信心在2年内服务可以达到这个规模，那么您可以从一开始就考虑分米的计划。 .

那么如何定义子表的规则呢？

如果单表500万条记录，一共可以分成20张表，那么单表的容量是47G，还是蛮大的，所以考虑分表的key

而单表的容量，如果分成100个表，那么单表的容量是10G干货内容:腾讯面试题：如何实现类似于新浪微博的短链接服务！，通过数字后缀路由到表更容易。可用于short_code

编码生成数值类型，然后进行路由。

如何跳跃

当我们在浏览器中输入时

DNS首先解析IP地址

当DNS获取到一个IP地址（例如：12.34.5.32）时，会向该地址发送HTTPGET请求，查询短代码a3300

p>

服务器会通过短码a3300获取对应的长URL

以上就是关于《如何实现类似于新浪的国内短链接服务》的全部内容了，感兴趣的话可以点击右侧直接使用哦！》》在线短链接生成器