短信场景下的短链服务设计

最新推荐文章于 2025-04-18 14:41:36 发布

aDakkke

最新推荐文章于 2025-04-18 14:41:36 发布

阅读量720

点赞数 21

文章标签： java 后端

本文链接：https://blog.csdn.net/qq_37335441/article/details/145888251

版权

文章目录

背景
一、短链是什么？
二、生成短链算法
三、方案选择
- 实现细节
总结

背景

在项目中，某次短信发送时因链接过长导致短信内容被拆分。短信服务商要求一条短信最大只能有70个字符，否则短信会被拆分成两条。这不仅增加了短信成本，还可能导致用户体验下降，甚至链接失效，影响业务转化率。
为了解决这一问题，我们决定引入短链服务，将长URL压缩为更短的链接，确保短信内容完整且用户体验不受影响。

一、短链是什么？

短链是将原始的长URL通过算法或处理转化为更短、更简洁的链接形式。相比于长链，短链具有以下优势：

美观简洁：短链长度大幅缩减，适合字符数受限的场景（如短信）。
便于分享：短链更易于复制和传播，提升用户体验。
隐藏原链接：短链可以隐藏原始URL的内容，防止用户直接修改URL参数。
统计功能：短链服务可以记录点击次数、来源等信息，为业务分析提供数据支持。

二、生成短链算法

常见的短链生成算法包括以下几种：

哈希算法：
- 原理：使用MD5、SHA-1等哈希算法对原始URL生成哈希值，再截取部分字符作为短码。
- 优点：生成速度快，适合高并发场景。
- 缺点：可能存在哈希冲突（不同URL生成相同短码），需要额外处理。比如使用布隆过滤器等方法。
自增ID + Base62编码：
- 原理：使用数据库的自增ID作为唯一标识，将其转换为Base62编码（包含0-9、a-z、A-Z）。
- 优点：短码唯一，长度可控。
- 缺点：依赖数据库自增ID，可能成为性能瓶颈。
自定义规则：
- 原理：根据业务需求自定义生成规则（如时间戳、随机字符串等）。
- 优点：灵活性强，可根据业务场景定制。
- 缺点：实现复杂度较高，需确保短码唯一性。

三、方案选择

经过对比分析，我们选择了自定义前缀 + 时间戳 + Base62编码的方案，具体原因如下：

1、长度可控：Base62编码生成的短链长度固定，适合短信场景。
2、唯一性：时间戳确保了短链的唯一性，避免冲突。
3、灵活性：自定义前缀可以根据业务需求扩展功能（如区分不同业务场景）。

实现细节

生成短链：

使用时间戳（精确到毫秒）作为输入，通过Base62编码生成短码。
使用短码作为Redis的key。
将短链与原始URL的映射关系存储在Redis中，并设置过期时间为一天。

DateTimeFormatter formatter = DateTimeFormatter.ofPattern("HHmmssSSS");
String now = LocalTime.now().format(formatter);
String base62 = Base62Converter.toBase62(now);
String key = "sms:short:" + base62;
//value为真实链接
redisCache.setCacheObject(key, value, 24, TimeUnit.HOURS);
String url = smsUrl + "?k=" + base62;