百亿短URL如何做到无冲突？_编程知识分享|编程教程|资源下载|源码下载

一个基本的思路

一般这种场景题，考察的重点有两个：

唯一性：短URL不能重复。
性能：百亿级规模得扛得住。

那么一般程序员应该从以下几方面回答：

唯一性问题怎么解决？可以用数据库加唯一索引，但百亿量级就需要更高效的办法，比如使用分布式系统中的分布式ID生成策略。
短URL怎么“短”起来？这可以用Base62编码（大小写字母加数字，共62个字符），把长URL的ID压缩成短URL。

简单说，短URL生成的流程可能是：

把长URL的原始ID取出来。
用Base62编码压缩成短字符串。
检查是否冲突，如果冲突就得处理，比如重新生成。

基础代码实现

一个基础版本的大致代码可以这样写：

public class URLShortener {
private static final String CHAR_SET = “abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789”;
private static final int BASE = CHAR_SET.length();
private Map<Long, String> urlMap = new HashMap<>();
private Map<String, Long> reverseMap = new HashMap<>();
private long idCounter = 1;

// 长URL -> 短URL
public String shorten(String longUrl) {
long id = idCounter++;
StringBuilder shortUrl = new StringBuilder();
while (id > 0) {
shortUrl.append(CHAR_SET.charAt((int) (id % BASE)));
id /= BASE;
}
String result = shortUrl.reverse().toString();
urlMap.put(idCounter, longUrl);
reverseMap.put(result, idCounter);
return result;
}

// 短URL -> 长URL
public String retrieve(String shortUrl) {
Long id = reverseMap.get(shortUrl);
return id == null ? null : urlMap.get(id);
}
}

这样实现的短URL，每次自增一个ID，然后转成Base62字符串，简单明了。🤓 但问题来了，百亿级别真的能行吗？

百亿级的难点：高并发 + 无冲突

老实说，题目里提到“百亿短URL”，一个HashMap就不够用了，直接崩溃没跑。要做到性能和可靠性兼得，几个思路：

1. 分布式ID生成器

你不能光靠一个服务器生成ID，得分布式上搞起来，像Twitter的Snowflake算法就挺合适：

每个服务器分配唯一的机器ID，生成ID时把时间戳、机器ID和序列号拼起来。
优点是快速且唯一，生成ID后直接Base62编码就能用了。

代码上可以用已有的开源实现，比如Snowflake算法的Java版本。

2. 数据库设计

虽然面试官没明确提数据库，但一个靠谱的程序员应该会提到：百亿URL的数据要存储、查询，还得快。常用的方法有：

用Redis缓存热门的短URL。
用NoSQL（比如MongoDB）存储大量数据，减少传统SQL数据库的瓶颈。
数据库中可以加唯一约束，避免冲突。

3. Hash碰撞的处理

有些更先进的系统会用Hash算法生成短URL，比如MD5或SHA-256。但直接生成可能会冲突，这时就需要“加盐”（Salt），在生成Hash前加个随机字符串，提高唯一性。

这位程序员为啥翻车？

说到这儿，回到主角——这位6年经验的Java程序员。他为啥连个开头都答不上来？说实话，我觉得有几种可能：

没准备场景题：有些人习惯了写CRUD，一问到系统设计就迷糊，觉得“我不是架构师，我只写业务代码”。但场景题是考察工程师是否有全局视野，懂得如何应对复杂业务需求。
对分布式系统不熟：百亿级别的数据量，一般涉及分布式架构、缓存、多机协调等。程序员如果没接触过这些，就很难回答得漂亮。
临场表现差：也许他其实懂，但一紧张脑袋空白了。这种情况也不少见，谁让面试环境就像高压锅呢？