数据结构
需求：同一个长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
