长链接生成短链接，访问短链接 302 重定向至原始长链接
| 依赖 | 说明 |
|---|---|
| Spring Boot | MVC 框架 |
| thymeleaf | 模板引擎 |
| MyBatis | ORM 框架 |
| Redis | 缓存 |
| hutool | Hash 算法、布隆过滤器 |
使用 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 临时重定向来处理，和服务器压力相比，数据的价值往往更大。