短链中心业务流程
2023-12-14 16:52:43 1 举报
为你推荐
查看更多
短链中心
作者其他创作
大纲/内容
数据结构
需求:同一个长url经过计算必须定位到同一个id,也就是防止地址歧义
urlId
生成id
urlID
解决
返回长地址 302重定向,301会缓存在用户浏览器中,虽然可以减轻短链服务的压力,但是也不便于进行后端的请求计数或者其他业务功能的实现。
查询
依赖数据源法
获取短链path(62)
问题:hash必然发生碰撞,不能防止地址歧义
请求
加锁
批量发号
不存在
加速方案
二义性检查
2.2 分布式、高性能的中间件生成ID
3.1UUID、GUID
储存器
方案2:为避免碰撞,使用自增ID作为ID
发号器
3.2snowflake算法
hex10
集群发号ID冲突问题
id = hex10 映射查找
Mysql
短url
原始长链接服务
去重
高并发性能瓶颈
返回长链
短链服务
查mysql
存在
从发号性能、整体有序(B+树索引结构更加友好)的角度出发,最终选择的snowflake算法
发号器的作用是将长url计算出一个id值,id的作用是对应数据库中的长url
往往只用单体mysql进行此方案
用户
雪花算法也是本地计算的一种方法,但是根据雪花算法的逻辑,生成的id是按时间总体有序的
snowflake算法的吞吐量在 100W ops +
存储方案
解决时钟回拨的问题,可以参考 推特官方的 代码、 百度ID的代码、Shardingjdbc ID的源码,综合存储方案设计解决。
发号方案
优点:整体吞吐量比数据库要高。缺点:Redis实例或集群宕机后,找回最新的ID值有点困难。适用场景:比较适合计数场景,如用户访问量,订单流水号(日期+流水号)等。
使用了缓存,二级缓存、三级缓存,加快id 到 surl的转换。
2.1最直观是mysql的自增ID
结构化存储
优点:不依赖任何数据源,自行计算,没有网络ID,速度超快,并且全球唯一。缺点:没有顺序性,并且比较长(128bit),作为数据库主键、索引会导致索引效率下降,空间占用较多,如果不生成索引,则加重映射查找过程的时间损耗。
长url
长地址URL
解析器
短链
优点:高性能、低延迟、去中心化、按时间总体有序缺点:要求机器时钟同步(到秒级即可),需要解决 时钟回拨问题如果某台机器的系统时钟回拨,有可能造成 ID 冲突,或者 ID 乱序。
302长链
最直观的方案1:计算出地址的hash编码作为ID
并发瓶颈过于明显
储存
if (短链)
font color=\"#000000\
布隆过滤器
分库分表架构
Nginx
方案3:为应对超高并发情况,尽量探询本地生成ID的方法,而避免远程请求ID
Redis、MongoDB 的自增主键,或者其他 分布式存储的自增主键
映射查询器
编码器
DB
短链转换62To10
0 条评论
回复 删除
下一页