设计一个短链系统
输入“/”快速插入内容
设计一个短链系统
设计一个短链系统
1.
短链的好处
•
太长的连接容易被限制长度
•
短链接简洁
•
安全，不想暴露参数
•
可以同一链接转化，可实现统计点击次数等操作
2.
短链的原理
短链：通过服务器重定向到原始链接实现
3.
短链生成方式
据统计，目前全球有58亿网页，java中int取值最多是2^32 = 4294967296 < 43亿 < 58亿，long取值是 2 ^ 64 > 58亿。若用数字，int勉强能支持（不是所有网址都会调用短链服务创建短链），使用long就比较保险，但会造成空间浪费
新浪微博使用8位字符串表示原始链接，这种字符串可以理解为数字的62进制表示，62^8 = 3521614606208 > 3521 亿 > 58亿，可以解决目前全球已知的网址，62进制为10个数字（0-9）+26个小写字母（a-z）+26个大写字母（A-Z）所组成的数
3.1
哈希算法
对原始链接取Hash值，使一种较简单的思路，有很多现成的算法可实现，但有个避不开的问题是：Hash碰撞，故选一个碰撞率较低的算法比较重要
推荐MurmurHash算法，该算法是一种非加密型哈希函数，适用于一般的哈希检索操作，目前Redis，Memcached，Cassandra，HBase，Lucene都在用该算法
对于碰撞问题，最简单的思路是：若发生碰撞，给原始URL附加上特殊字符串，直到躲开碰撞为止
3.2
发号器
不管来的是什么，通过集中的统一发号器，分配一个ID，该ID为短链的内容，比如第一个来的是https://tinyurl.com/1，第二个就是https://tinyurl.com/2，以此类推。在一些分布式ID算法上来看就是很长的一个序号了，为了获取更短链路，可以将其转为62进制字符串
1.
Redis 自增：Redis 性能好，单机就能支撑 10W+请求，如果作为发号器，需要考虑 Redis 持久化和灾备
2.
MySQL 自增主键：这种方案和 Redis 的方案类似，是利用数据库自增主键的提醒实现，保证 ID 不重复且连续自动创建
3.
Snowflake：这是一种目前应用比较广的 ID 序列生成算法，美团的 Leaf 是对这种算法的封装升级服务。但是这个算法依赖于服务器时钟，如果有时钟回拨，可能会有 ID 冲突。（有人会较真毫秒中的序列值是这个算法的瓶颈，话说回来了，这个算法只是提供了一种思路，如果觉得序列长度不够，自己加就好，但是每秒百万级的服务真的又这么多吗？）
对于统一发号器的方式，还需要解决的一个问题是：同一个原始链接，应该返回相同的短链还是不同的？
•
根据用户、地点、时间等维度，相同的原始链接，返回不同的短链。若判断维度都相同则返回相同短链
4.
短链存储
数据存储一般就两种：关系型数据库、NoSQL数据库
MySQL的建表存储短链接
代码块
CREATE TABLE IF NOT EXISTS tiny_url
(
sid INT AUTO_INCREMENT PRIMARY KEY,
create_time DATETIME DEFAULT CURRENT_TIMESTAMP NULL,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP NULL ON UPDATE CURRENT_TIMESTAMP,
version INT DEFAULT 0 NULL COMMENT '版本号',
tiny_url VARCHAR(10) NULL COMMENT '短链',
original_url TEXT NOT NULL COMMENT '原始链接',
# 其他附加信息
creator_ip INT DEFAULT 0 NOT NULL,
creator_user_agent TEXT NOT NULL,
# 用户其他信息，用于后续统计，对于这些数据，只要存储影响创建短链的必要字段就行，其他的都可以直接发送到数据服务中
instance_id INT DEFAULT 0 NOT NULL,
# 创建短链服务实例ID
state TINYINT DEFAULT 1 NULL COMMENT '-1无效 1有效'
);