案例：用户将存储内容粘贴到站点，站点给用户返回一个短地址，用户通过短地址，可以访问之前粘贴的内容或者跳转之前的原始站点
功能
对于用户来说操作要简单，生成的短地址要简单，而且要唯一，不同用户即使内容一样也要生成唯一的短地址
时间有效性，从存储角度来说，不可能一直帮用户存储所有生成的短地址，不然存储会越来越大，所以通过设置短地址有效的访问时间，可以减少存储成本
技术
- 可用性(high Availability)， 保障用户功能可用
- 低延时(low latency)，用户拿到短地址或者通过短地址跳转其他网站时，重定向时间不宜过长
- 安全性（non guessable），不能被猜出来，用户在生成一定短地址时如果携带一些个人信息，不应体现在短地址中，否则会造成用户信息泄露
- 对于ins/微博/小红书之类的社交功能还要保障一致性，博主发的照片，follower看到的内容应该是一样的
容量负载能力假设
对一个用户来说，可以抽象出两个主要请求
- 请求生成短url，我们要把请求参数或者原始信息存储起来 inbound
- 请求访问url，把生成的url返回给用户使用，进行重定向 outbound
假设一个短地址按500byte大小存储
容量
假设一个月会有100万个新短地址生成，
那么5年会产生
100万5年12个月 ==> 约等于60亿个短地址
60亿*500byte ==> 3TB 会有需要3TB大小的容量存储
负载能力
假设一个月有100个用户，每个用户会进行100万次访问短地址进行重定向的操作
那么每秒钟会有
（100 100万）/（30D 24H * 3600s） ==> 约等于4000个短url 要给到用户
同时会有
4000/ 100 ==> 大概40个短url 需要被生成
那么服务所需要的带宽就可以计算出来
inbound : 40 500 byte 约等于 20kb/s
outbound: 4000 500 byte 约等于 20MB/s
API 数据库设计
api
假设会用到简单的增删
生成短url createURL(api-key, originUrl, expired-Date, userId)
删除url deleteURL(api-key,shortUrl)
DataBase
对于shortUrl
pk: hash
originUrl,
expired-date,
userId
…
对于user
pk: userId
name
…
生成shortUrl
假如计划生成一个6个字符的短url，使用base64的加密算法的话可以生成64 ^ 6 大约640个短url,
满足之前5年会产生60个亿的唯一性需求
整体逻辑
用户 —>request shortUrl generation —> app
app —> base64 encoding + 从key generation DB中拿一个nonUse 的key —> 得到shortUrl —>DB
DB —> app –>用户
其他
Cache
2-8原则
用存储的20% 的url做cache内容，可以满足80% 的访问需求
load balance
均衡流量
过期后的url处理，key的处理
分布式存储，分片
对于社交功能的newFeed的推送
pull / push / pull + push hybrid