短链接服务

长链接生成短链接，访问短链接 302 重定向至原始长链接

实现

使用 MurmurHash 算法将原始长链接 hash 为 32 位散列值，将散列值转为 62 进制字符串，即为短链接，将短链接添加入布隆过滤器，并向 Redis 添加指定过期时间的缓存。用户访问短链接，在 Redis 中查找是否存在缓存，存在则延长缓存时间；不存在，查找数据库并添加缓存，302 重定向至原始长链接，并自增短链接访问量。

技术选型

MurmurHash：长链转短链自然需要一个哈希算法，应用的类型决定了我们并不需要解密，而是关心运算速度和冲突概率，MurmurHash 就是一种非加密型哈希算法，与 MD5、SHA 等常见哈希函数相比，性能与随机分布特征都要更佳。MurmurHash 有 32 bit、64 bit、128 bit 的实现，32 bit 已经足够表示近 43 亿个短链接。使用 Java 的话，在 Google 的 guava 或 hutool 中有相应实现，这里使用 hutool。

base62：MurmurHash 生成的哈希值最长有 10 位十进制数，为了进一步缩短短链接长度，可以将哈希值转为 62 进制，最长为 6 个字符。

布隆过滤器：哈希函数不可避免会产生哈希冲突，随着短链接越来越多，冲突概率也会越大。每次生成短链接后，向布隆过滤器中查找是否已经存在此短链接，如果已经存在，则在长链接后添加一个自定义字符串，重新 hash，重复上一步，直到没有哈希冲突，把短链接加入布隆过滤器。这里使用 hutool 工具包中基于 JVM 的布隆过滤器来实现。

Redis：生成短链接后，通常在后续一段时间内此短链接的使用频率较高，则向 Redis 中添加带过期时间的缓存来减轻数据库压力。

302 状态码：301 为永久重定向、302 为临时重定向，通常需要记录短链接访问次数或需要修改、删除短链接时，使用 302 临时重定向来处理，和服务器压力相比，数据的价值往往更大。

声明

本在线网站只用于项目展示，随时可能关闭，并不保证绝对的可用性，切勿用于商业用途或非法传播，因此产生的任何纠纷与本人无关。

被刷数据也快习惯了，几千条也就算了，这次的 80 万条是在帮我做压测吗😅

如果是的话，请把结果在 Issues 里分享一下，否则可能会变得不幸，甚至会变成猫猫🐱