北京
为什么一个短链接服务，7位短码就够用了？这是「60天学系统设计」系列第21篇要拆的问题，对象是TinyURL这类产品。整套设计从两个API开始：生成短链、重定向访问。
核心环节是唯一ID的生成与转换。做法是先用分布式方案拿到一个唯一ID，再用Base62把它转成短码。相比哈希方法，这条路避开了碰撞问题，短码长度也会随ID增长自然变长，而不是一开始就固定死。
7位Base62之所以被认为足以支撑海量数据，逻辑就藏在这套编码方式里——每一位的取值空间被充分利用，位数增加带来的容量扩张是数量级的。
技术选型上有几组经典对比。哈希冲突怎么处理，对上Base62的唯一性保证；重定向用301还是302，则直接关系到业务统计能不能拿到数据。这些取舍没有标准答案，取决于你要什么。
读写特征决定了架构重心。短链服务是典型的读多写少，所以缓存热点短链、数据库回源是主要优化路径。存储估算也被纳入讨论范围，属于设计时必须先算清楚的一笔账。
安全层面有一个容易被忽略的漏洞：连续ID会带来枚举攻击风险。对应的思路是加盐或做随机化处理。文章最后留了一道思考题——自定义短码撞车了，冲突该怎么处理。
这套拆解的价值不在于给出唯一解，而在于把每个决策点的代价摆出来。ID怎么生成、状态码怎么选、缓存放在哪一层，每一步都在换别的东西。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
