做后台开发这些年，我越来越觉得，越是看起来人畜无害的小功能，越藏着整个系统最扎心的设计。你随手在注册页输入一个用户名，点击确认，啪，一行红字：“用户名已被占用”。用户骂一句，走了。但这行红字背后，是分布式系统里最经典、最刁钻的一道题：在十亿级用户规模下，如何快速、准确、并发安全地判断一个字符串是否被占用。
我参与过一个用户量过十亿的海外社交产品，注册流程里就有这个模块。当时我们花了整整三个迭代去打磨“用户名唯一性校验”，从最开始数据库直接查，到后来引入分片、缓存、Bloom Filter、预占用状态机，中间踩了不知道多少坑。这篇文章我就把整个设计思路、关键代码、压测数据、以及那些文档里永远不会写的问题排查经验，一次性讲清楚。如果你正好在做账号体系、注册登录、或者任何涉及全局唯一约束的后端系统，这篇内容应该能帮你少走不少弯路。
1. 业务画像与隐藏难点：为什么“一个用户名”能逼疯架构师
1.1 需求听起来很简单
产品经理提的需求永远只有一句话：用户注册时填写的用户名在全平台内不能重复。老用户改名时，新用户名同样不能重复，而且老用户名要被释放，允许其他人使用。
这句话翻译成技术指标，其实就是两个点：第一，写入时保证全局唯一；第二，查询时快速返回“是否可用”。听起来不就是给字段加个唯一索引的事吗？任何一个刚工作两年的开发都能写出这条SQL：
CREATE TABLE users ( id BIGINT PRIMARY KEY, username VARCHAR(32) NOT NULL UNIQUE, ... );单机数据库里，这个唯一索引确实能解决一切。但问题是，我们的用户量不是一万，不是一百万，而是十亿。日注册峰值可以冲到五十万，平时每秒也有几百个新用户，这还没算改名请求和各类脚本刷量。这个量级下，你不可能把所有数据放在一台数据库上，必然要分库分表、上分布式存储。而一旦数据分布到成百上千个节点上，“全局唯一约束”就再也不是数据库自带的能力了，它成了应用层必须亲自下场解决的分布式一致性问题。
1.2 数据规模先算一笔账
十亿用户不意味着十亿个用户名。因为用户名一旦释放，可以被别人重新占用，所以用户名记录要远比用户账号多。我当时粗略估算了一下：
- 平台累计注册用户数：约12亿
- 历史用户名占用记录（含释放过的）：约15亿条上下
- 活跃用户名（当前被占用的）：约7亿
- 注册接口峰值QPS：约5000
- 用户名查重/预占用请求峰值QPS：约20000（因为前端会在用户输入过程中实时查重）
单条记录按50字节算，15亿条就是75GB以上的原始数据。这个体量，任何单库都撑不住，必须拆分。而且注意，查重请求的QPS是注册接口的4倍，因为用户边输入边查。存储层要承受的读压力远大于写压力，如果每次都穿透到数据库，数据库早就被打挂了。
1.3 三个真正的技术难点
难点一：唯一性校验必须“读后写”原子化。如果先查一遍数据库，发现名字空闲，然后插入记录，这中间存在时间窗口。两个请求同时查到“空闲”，同时插入，必然冲突。解决思路只有一条：依赖存储层的唯一索引或等价机制来做最终裁决，而不是靠应用层查重。
难点二：热点数据集中。虽然用户名理论上可以千奇百怪，但总有一些“爆款”名字，比如“jack”、“lucy”、“2024”之类，会在一瞬间被大量用户同时争夺。这些就是典型的热key问题。如果架构里没有热点隔离设计，某几个分片会被打穿，其他分片闲着，整个集群的吞吐被拖垮。
难点三：释放与重占的时序。用户改名后，老用户名不能立刻开放注册，得有一个保护期，否则别人马上注册与你几乎相同的名字，会产生大量仿冒账号问题。这就意味着“用户名被占用”不只是布尔值，而是带状态的：占用中、保护期、可释放。状态流转一旦涉及延迟和幂等，复杂度立刻上一个台阶。
2. 整体架构选型：从单索引到“三层防线”
2.1 存储分片：按用户名哈希还是按用户ID哈希
先说结论：用户名记录表必须以用户名为分片键。原因非常简单，我们所有核心操作都是通过用户名来寻址的，比如“用户名是否被占用”“插入一条用户名记录”“释放一条用户名记录”。如果把分片键设成用户ID，那么一次查重请求就得广播到所有分片，这才是真正的灾难。
实际方案是把这个表拆成1024个分片，分片规则用用户名做CRC32后再取模。为了方便后续扩容，我没有直接用user_name % 1024，而是引入了一层虚拟分片：
def pick_shard(user_name: str) -> int: # 虚拟分片：先算物理分片，再映射到真实节点 hash_val = zlib.crc32(user_name.encode("utf-8")) % 1024 return hash_val为什么要加虚拟分片？因为如果直接按机器数量取模，以后扩机器整个映射关系全乱，数据大迁移非常痛苦。引入固定1024个虚拟分片后，扩容时只需要把某些虚拟分片从旧机器迁到新机器，路由表局部更新即可。
2.2 唯一约束：存储层必须承担最终裁决
不管前面加了几层缓存，最后一道防线一定是存储层的唯一索引。我们的分片数据库使用MySQL，每张分片表结构如下：
CREATE TABLE user_name_record ( id BIGINT PRIMARY KEY AUTO_INCREMENT, user_name VARCHAR(32) NOT NULL, user_id BIGINT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT '0:预占用 1:激活占用 2:保护期 3:已释放', created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, expire_at DATETIME NOT NULL COMMENT '预占用或保护期的过期时间', UNIQUE KEY uk_user_name (user_name) ) ENGINE=InnoDB;这里最关键的是UNIQUE KEY uk_user_name。所有并发请求最终都会落到这一条唯一索引上，只有一条能插入成功，其他全部报DuplicateKey错误。这就保证了即使在缓存全部失效、分布式锁全部失效的最坏情况下，数据库依然能挡住重复数据。我见过不少团队把唯一性寄托在Redis的SETNX上，结果Redis一抖动，线上全是重复用户名，这属于设计事故。
2.3 缓存层：布隆过滤器挡掉99%的穿透
唯一索引虽然可靠，但扛不住每秒几万次的数据库写入。以我们为例，大多数查重请求最终会“占用已有名字”，也就是说这些请求杀到数据库唯一索引，得到的是一个错误码。如果所有查重都打到存储层，分片数据库压力直接爆炸。所以必须在存储层前面加一道高密度、低成本的预判机制。
这里就要请出布隆过滤器了。布隆过滤器的特点是：判断一个元素“一定不存在”是准确的，判断“可能存在”则可能误判。这正好契合我们的场景——大部分用户名查重，在布隆过滤器这一层就会被判定为“肯定存在”，直接返回不可用，根本不需要触碰数据库。只有布隆过滤器说“可能存在”（实际上可能刚好没占用），才会继续走后面的缓存和数据库。
我们的布隆过滤器配置：
- 预估元素数量：10亿
- 误判率：0.1%
- 计算得到位数组大小：约18亿bit，约2.2GB
- 需要哈希函数个数：7个
2.2GB内存完全放得下，而且为了降低单点风险，按虚拟分片拆成1024个小布隆过滤器，每个分片负责自己那部分的用户名集合。
不过要注意，布隆过滤器不支持删除。用户释放用户名后，布隆过滤器里这个位置不会被清掉，这就导致已释放的名字可能被误判为“可能存在”。没关系，处理方案是让它继续走缓存和数据库做精确判定，最多就是多一次查询，不会出错。牺牲一点点误判率，换来的是极高的空间效率和查询性能。
2.4 预占用机制：把唯一性校验和注册事务解耦
注册流程不是只写一条用户名记录就完事的，还要创建用户资料、初始化关系链、写入推荐索引等等。如果等整个注册事务提交后才占用用户名，那么在事务期间，这个名字实际上没有任何保护，会被别人抢先注册。
我们设计的方案是引入“预占用”。注册请求一到，立刻插入一条status=0的用户名记录，这个状态表示该用户名已被当前请求预留。如果后续的用户创建流程失败，则释放这条预占用；如果成功，则更新状态为激活占用。
预占用记录不是永久的，有一个过期时间，一般设置为15分钟。如果用户填写信息到一半关掉了浏览器，15分钟后系统后台任务会自动把这些孤儿预占用记录清理掉，名字重新释放出来。这样设计后，用户名唯一性的校验就不需要和用户创建事务绑定在一起了，数据库唯一索引承担了“防重”职责，服务端流程编排承担了“保活”职责，两个关注点彻底分离。
3. 核心流程实操：注册、改名、并发冲突破解
3.1 注册查重的完整流程
我把一次用户名校验的完整调用链画在脑子里，大致是四级：
- 前端实时查重请求到API网关，带上
user_name参数 - 应用层先查本地Caffeine缓存，再查分布式Redis缓存
- 如果缓存都没有，查询对应的布隆过滤器分片，判断是否“肯定不存在”
- 如果布隆过滤器认为可能存在，再路由到具体MySQL分片发起精确查询
四个层级依次挡住请求，只有最后一层才允许访问数据库。我统计过线上数据，缓存加布隆过滤器可以拦截掉约90%的查重流量，真正打到数据库的每分钟只有几千次，数据库负载完全在可控范围内。
核心的预占用接口伪代码如下：
def reserve_username(user_name: str, user_id: int) -> bool: shard = pick_shard(user_name) try: with db_client(shard).transaction(): now = datetime.utcnow() expire_at = now + timedelta(minutes=15) db_client(shard).execute( """ INSERT INTO user_name_record (user_name, user_id, status, expire_at) VALUES (:user_name, :user_id, 0, :expire_at) """, {"user_name": user_name, "user_id": user_id, "expire_at": expire_at} ) return True except IntegrityError as e: if "DuplicateKey" in str(e): return False raise这里一定要记住：不能先SELECT再INSERT，必须直接INSERT，依赖数据库唯一索引去重。先查再插的模式在并发场景下必然产生竞态条件。我们曾经把“预占用”改成先查后插，压测的时候到了每秒2000并发，立刻出现3%的重复占用，后来老老实实改回了直接插。
3.2 老用户改名与释放策略
改名逻辑比注册复杂得多，因为它涉及两条记录：新用户名要被占用，老用户名要进入释放流程。这两步不能简单地在一个数据库事务里完成，因为新老用户名可能路由到不同的分片。跨分片事务太重，通常不推荐。
我们的处理方案是“两阶段提交”的简化版：
- 第一阶段：把老用户名标记为
status=2（保护期），并设置过期时间，比如90天。 - 第二阶段：为新用户名执行预占用操作，插入状态为
1的激活记录。 - 如果新用户名预占用失败，说明新名字被别人抢走了，事务回滚，老用户名恢复为激活占用状态。
新用户名预占用成功后才真正更新用户资料里的主用户名。看起来有点繁琐，但好处是每一步都是单分片操作，没有跨库事务，任何一步失败都能单独补偿。
这里有个容易踩的坑：老用户名进入保护期后，是“不可用”状态，任何查重接口都不能返回空闲。只有到了90天保护期结束，后台任务才会把它改成已释放，名字才能被重新注册。为什么必须留保护期？我见过有人为了省事，用户名释放后立刻可注册，结果大V改个名，马上被人注册了山寨账号去骗粉丝。这已经不是技术问题了，这是安全事故。
3.3 并发冲突与自动重试
即使有了唯一索引，高并发下依然会遇到大量插入冲突。尤其是热门用户名，同时在抢的人非常多。这些请求如果不做任何处理直接失败，体验非常差。
我们的策略是让预占用失败方自动退避重试。比如A用户正在预占用“jack”的过程中，B用户也来抢。B的插入失败后，不会立刻返回“已被占用”，而是等待几十毫秒后再试一次，因为A的整个注册流程可能马上因为创建资料失败而释放预占用。这个重试机制有效降低了热门名字的抢注失败率。
但重试必须设置上限，我们最多重试3次，每次退避时间是10ms、50ms、100ms。超过上限就返回“已被占用”，引导用户换个名字。另外，重试本身要带幂等键，否则B用户在网络超时后重试，可能上一次请求其实已经插入成功了，再次插入会误判为失败。我们用request_id作为用户维度的幂等标识，同一请求的多次重试，插入时先检查是否为同一request_id，保证不二次扣减用户的可注册次数。
4. 一致性与异常设计：缓存、锁、幂等怎么配合
4.1 为什么Redis里的状态不能当最终依据
很多团队会把用户名存在Redis里，用SETNX来判重，再用DEL来释放。这个方案在小规模没问题，但到了十亿级，有几个致命隐患：Redis不是强一致的多副本，主从切换时可能丢数据；Redis数据无法全量保存，必然要定期淘汰，一旦key被淘汰，查重就会放行。所以我们从来没把Redis当作“最终裁决者”，Redis只是“加速层”。
具体做法是：查询时先走Redis，若命中则返回，若未命中，则查数据库并将结果回填Redis。写入时，预占用成功后同步更新Redis，同时让布隆过滤器保持原样。Redis里的key设置过期时间为24小时，避免冷门用户名长期占据内存。
4.2 分布式锁的粒度：只需要锁“同一分片内同名”
用户名唯一性既然最终由数据库唯一索引保证，理论上可以不要锁。但为了减少数据库无谓的写冲突，我们仍然加入了分布式锁，只是粒度控制得很小心：锁的粒度是用户名本身，而不是用户或全局锁。
Redis的Redisson实现的RLock，锁的key就是lock_<user_name>，锁的持有时间默认2秒。在预占用前先尝试获取锁，获得锁后才发起数据库插入。由于锁只针对同一用户名，不同用户名的注册完全并行，不会形成全局瓶颈。
不过要特别注意，分布式锁不能成为正确性依赖，只能作为性能优化。因为锁可能因为网络分区失效，如果某个进程获取锁后GC暂停超过锁超时时间，另一个进程也会拿到锁。所以我们始终把唯一索引当作兜底，锁只是降低冲突概率，保证常规流量下数据库写压力平稳。
4.3 幂等设计与请求重放防护
注册防重还有一个容易忽略的问题：用户在客户端点了一次注册按钮，但请求超时了，前端自动重试，可能会提交两次同样的注册请求。如果后端不做幂等，同一个用户会出现两条不同用户名的预占用记录，名字全被占住。
解决方案是引入注册请求幂等表：
CREATE TABLE register_request ( request_id VARCHAR(64) PRIMARY KEY, user_name VARCHAR(32) NOT NULL, user_id BIGINT NOT NULL, status TINYINT NOT NULL, created_at DATETIME NOT NULL )同一request_id的重复请求，后端只处理第一次，后续请求直接返回第一次的处理结果。这张幂等表的数据量不大，按天分表，保留30天即可。加了幂等表之后，注册接口的“重复扣减用户名”问题就彻底没了。
5. 常见问题与排查实录：那些压测和线上才会暴露的坑
5.1 缓存与数据库不一致导致“明明没有却提示占用”
这是我们上线初期遇到过最多的问题。场景是这样的：用户注册时预占用成功，但后续用户资料创建失败，释放流程把数据库记录删了，却忘了删除Redis里的key。之后其他用户来查这个名字，Redis返回“占用”，数据库明明是空闲的。
排查思路很简单：对比Redis命中结果和数据库精确结果。我们写了个离线对账脚本，每天随机抽一定比例的热门用户名，比对Redis与数据库状态，发现不一致就触发缓存删除。但更根本的解法是：释放操作只更新数据库，等到缓存过期后自然回源，不支持主动删除。这个方案牺牲了一点时效性，但彻底避免了对账不及时的问题。后来又改为释放时先删Redis，再更新数据库，用最后一致性兜底，线上不一致率基本消失。
5.2 热点用户名秒杀某个分片
某天我们突然收到监控报警，某个MySQL分片的CPU持续90%以上，其他分片却很闲。原因是当天有某个热点事件，大量用户同时尝试注册 “支持者” 相关风格的热门昵称。因为分片规则是用户名CRC32取模，所有类似拼写的用户名大概率落在少数几个分片上，导致热点分片被打爆。
常规限流只能保护数据库不挂，但会让正常请求也失败。我们的解法分两层。第一层，在应用层对热点用户名做本地限流，每100ms最多允许一定数量的预占用请求打到同一个分片。第二层，对“已占用”且是超热门的名词，直接复制一份“只读拒绝名单”到本地内存，查重时无需网络请求即可拒绝。比如某明星的名字一旦被占用，把它加入本地拒绝名单，任何对该名字的查重请求直接返回“占用”，流量根本到不了存储层。
5.3 扩容与Rehash：虚拟分片的威力
用户量继续增长后，原来单分片能承载的容量不够了，必须扩容。如果分片规则是物理机取模，扩容等于重写所有数据。但因为我们用了1024个虚拟分片，迁移就变成了路由表的局部更新：把一些虚拟分片从旧集群搬到新集群，搬完只修改配置中心的映射关系。
具体操作时要注意，迁移过程必须遵循“先复制，再切换，后删除”的原则。先把虚拟分片的数据全量复制到目标节点，然后持续同步增量，等到两边数据一致后，把路由表中该虚拟分片的映射切换到新节点，最后删除旧节点的数据。这套流程我们跑了多次，单次迁移的最大停机时间控制在秒级，对用户完全无感。
有个细节特别提醒：扩容前先梳理一次布隆过滤器的分片范围，因为虚拟分片迁移后，布隆过滤器也必须跟着迁移，否则新节点上查不到对应的过滤器，流量会全部穿透到数据库。我们第一扩容就漏了这个，迁移完成后数据库负载瞬间翻了三倍，吓得我冷汗直流。
5.4 孤儿预占用与保护期释放的调度
预占用记录15分钟会过期，保护期记录90天会过期，这些都需要后台定时任务清理。最开始的实现是每分钟全表扫描一次，到后期数据量上来，一次全表扫描要跑20分钟，严重拖垮数据库。
后来改成分段扫描：每次只扫描一个虚拟分片上的过期记录，用expire_at < now作为过滤条件，加上LIMIT 2000，完成一轮再取下一轮。更高效的做法是为过期时间建二级索引，扫描只读索引覆盖的字段，避免全表扫描。实测之后，单分片的清理任务从20分钟降到了1分钟以内。
还有一个容易忽略的问题：清理任务和预占用请求并发时，可能“刚清理了预占记录，新用户立刻占了这个名字”，而旧用户正好在提交注册资料。这时旧用户再次确认注册就会失败。策略是在用户提交注册资料的接口里，判断预占用记录如果已经不存在，就自动重新发起一次预占用，仍然成功则继续后续流程，失败则返回“名字被抢”。这个自动补偿逻辑也算是给用户多了一重保障。
写在最后：关于唯一性校验的几条经验总结
这套架构从设计到上线，再到后来支撑十亿级用户量，我个人最强烈的感受是：在分布式环境下，永远不要把“唯一性”寄托在应用层的业务检查上。幂等、缓存、布隆过滤器、分布式锁，这些都是优化手段，唯一能让系统在极端并发下不出错的，只有存储层那把静态的唯一索引。
另一个经验是关于“快”和“准”的平衡。布隆过滤器说“不存在”可以100%信，说“可能存在”则必须继续查库；缓存说“没有被占用”也要小心，因为缓存过期后可能已经有人占用了。我们最终的信条是：一切缓存和加速层都可以出错，但数据库的结果必须是准的，所有读路径上的不确定态，最终都要收口到数据库做确认。
如果你现在也在设计类似的全局唯一关系系统，我的建议很简单：先想清楚存储层怎么兜底，再去谈缓存优化和性能指标。先写一个基于唯一索引的最小可用版本，再逐层叠加布隆过滤器、缓存、锁。不要一上来就上一个花里胡哨的分布式锁方案，底子没打牢，多花的功能全都会变成日后的维护负担。
用户名占用只是业务里一个极小的功能点，但把它做扎实了，你就能触类旁通地理解分布式系统里“唯一性”这个永恒命题。希望这篇记录能给你带来一些实操层面的启发。
