1. 十亿用户名的账数据量级决定方案边界用户名被占用就返回一个提示嘛一条SQL的事为什么这么复杂——这是我见过很多技术评审里都有人提的问题。今天拿Instagram或者说所有亿级用户社交产品的用户名已被占用检查作为引子来聊聊是因为它把看起来很简单和做起来很难之间的距离暴露得最典型。先把账算清楚。假设平台有10亿注册用户每个用户名平均10~15个字节。光用户名本身的数据量就是10~15GB这还没有算上索引。要做用户名是否被占用的唯一性校验存储层必须有唯一索引索引在B树里存的除了用户名本身还有索引页、主键引用、页内空闲结构等开销实际占用的空间通常是原始数据的2~3倍。也就是说光是支撑这个唯一性判断的索引30~50GB是很正常的。容量本身没有压力但问题在于一次索引查询要读多少页、索引层级有多深会直接反映到延迟上。更关键的是访问模式。用户注册的时候产品普遍会在输入框右侧实时显示可用/已被占用这意味着用户每敲一个字符就有一次可用性检查请求打到后端。一个要输入10个字符的用户名可能产生10次以上的查询再加上同名的并发尝试、注册失败后的重试、修改用户名场景的重复检查后端实际看到的请求量是注册用户数的几十倍。换句话说为十亿注册用户服务不等于只需要处理十亿次查询而是要在高峰期扛住远比注册QPS高的、以用户名可用性为核心的读流量。如果只是量大倒也不至于上升到架构设计的高度。真正变难的是三件事叠加量大、要求快、必须对。量大是存储和带宽问题要求快是延迟问题必须对是一致性问题。用户名已被占用这个提示如果报错了用户以为注册成功结果下一步发现用户名没绑定到自己身上这种错误比慢还致命。Instagram这种量级的产品在分布式环境下同时满足这三点才是标题里架构设计四个字的真正含义。所以先立一个结论放在前面用户名可用性检查本质上是在分布式海量数据集里对单条记录做低延迟、高并发、强一致的成员查询。后面所有架构手段都是围绕这个本质展开的。2. 先查后写的天真方案死在这三个隐性问题很多新项目一开始都是这么写的用户输入用户名后端查数据库比如select count(*) from users where username ?返回0就放行注册。这个方案在小规模下没有任何问题数据量到一定程度后藏着三个很阴的隐性坑。2.1 空档期查询与写入不是原子操作第一个坑是竞态。假设用户A和用户B同时提交了同一个还没人用的用户名两个请求分别落在两个应用实例上。查询的时候数据库里都没有这条记录于是两个请求都认为可用接着都执行插入。如果没有唯一性兜底两个人的账号都会创建成功用户名就重复了。这个问题的本质是检查和写入之间存在一个时间窗口任何在应用层做的先判断再写入都不是原子操作。只要系统并发稍微上来一点这个竞态就会从理论变成现实。解决这个问题不能靠我们检查得很快窗口很小因为注册是集中式入口哪怕窗口只有1毫秒QPS高的时候照样能撞上。2.2 读放大一条提示背后是一连串查询第二个坑是读放大。实时可用性检查意味着每次键盘输入都触发查询。假设一个注册接口的QPS是1万用户平均输入10个字符才完成一个用户名那用户名检查这个读接口的QPS可能就被放大到5万到10万。这些请求绝大多数是重复查询同一个热门用户名——比如某个出现在推广素材里的用户名一瞬间会有几万个人同时查它是否可用。如果这些查询全部打到数据库主库数据库的CPU、IO、连接数都会被拖垮。更麻烦的是这类读请求还不是纯粹的点查——为了对齐账户状态还要join用户表、绑定状态表逻辑上的简单查询落到数据库里可能是一串SQL。这些逻辑如果都靠主库硬扛到了注册高峰期系统其他核心写入路径发帖、关注、私信状态变更都会被连累。这也是我为什么一直说用户名已被占用这种听着最简单的功能最需要从业务数据库里拆出去。2.3 延迟慢查询滚雪球第三个坑是延迟。数据量到十亿唯一索引的B树深度正常会在3~4层如果索引页没有全部驻留内存一次查询还要读磁盘。再加上读放大数据库连接池很快打满后面的查询全部排队。此时可用性检查的延迟从5毫秒飙升到50毫秒甚至几百毫秒用户输入一个用户名要等半秒才看到已被占用产品体验直接崩掉。这三个坑叠加起来结论很明确不能把用户名可用性检查简单理解成一条SQL。它需要被当作一个独立、可缓存、可水平扩展的服务来设计并且在最底层用一个绝对可靠的东西兜底一致性。这个兜底就是唯一索引下面把话挑明。3. 唯一索引才是唯一裁判存储层怎么扛住全局唯一不管应用层做了什么缓存、预判、优化最终拍板这个用户名到底能不能用的一定还是存储层的唯一约束。这是整个架构里不能妥协的一条底线。Instagram早年用的是PostgreSQL分片后来陆续引入了大量自定义服务层但不管怎么演进都绕不开一件事唯一性必须落在存储层。3.1 一张表扛全局唯一问题不在于容量有些人觉得一张user_names表单独存用户名再加个唯一索引不就行了单表在十亿数据量下依然能工作MySQL/PostgreSQL单表单表几十亿行的案例并不少。真正的问题是写入放大和维护成本每次注册插入一行每次用户名变更要更新所有请求都集中在同一张表的同一个索引上热点非常明显。数据量继续增长或者遇到大促类流量峰值单表的锁竞争会卡住注册链路。更现实的是单表往往和业务库耦合在一起容易互相拖累。3.2 分片之后全局唯一性怎么保持Instagram这种规模用户主表必须分片。问题来了如果用户主表按用户ID哈希分片那么同一个用户名可能落在任意一个分片里。用户名唯一需要的是全局约束但分片内只能保证分片本地唯一。这时候常见做法是把用户名→用户ID这个映射单独拿出来做成一张全局映射表或者一个独立的用户名注册服务这张表承担唯一的职责记录哪些用户名被占用。以按用户名哈希分片的映射表为例哈希之后同一个用户名永远落在同一个分片分片内的唯一索引就能保证该用户名在全局只出现一次。但要注意新的查询问题注册时按用户名取分片没问题但如果用户数据主表按用户ID分片登录、资料展示还要再按用户ID路由一次。所以做得好的系统会把用户名当作另一个分片维度让它和用户主数据分片解耦用户名检查走用户名维度用户数据访问走用户ID维度。Instagram的公开架构资料里也明确体现出了多个分片集群服务于不同访问模式的思路。3.3 分区键选错就是给热点送弹药设计这张映射表或服务时分区键不要用别的就要用用户名本身——这样才能保证同一个用户名的所有操作落在同一个分片。但要小心用户名分布是不均匀的热门名和垃圾名都会形成热点分片。解决方式是对用户名做FNV或者CRC的二次哈希再取模让天然的热点均匀打散到多个分片。代价是这个分片不能优雅地做range扫描但对于用户名可用性检查这种纯粹的点查场景这个代价完全可以接受。这一层存储设计做完唯一性有了物理保证。但架构问题还没结束高并发下不可能每个输入框的每个字符都去怼数据库缓存层要上场了。4. 把占用信息塞进内存负缓存与概率过滤的取舍真正到了十亿量级哪怕存储层做得再好也不能把所有可用性检查请求都放到数据库。原因还是读放大实时检查是高频读数据库再强也架不住每敲一个字符就一次点查。这时候要看清一个信息侧的规律检查请求里存在非常明显的倾斜——热门用户名被问得最多冷门用户名几乎没人问。4.1 负缓存只记已被占用不记可用一个常见误区是把所有用户名是否可用都缓存起来。这是不现实的十亿用户名的可用状态如果全量缓存内存开销和更新成本都不可控。真正实用的思路是负缓存只缓存已被占用的用户名键是用户名值是这个用户存在。冷门用户名查缓存大概率没有命中此时再回源到数据库确认。这样数据库压力只和未被缓存的实际查询成正比热门用户名几万次重复查询会在缓存层被挡掉一次都不漏到DB。负缓存一定要注意数据不能只在应用实例本地否则两个实例各自缓存同样的内容等于没缓存。所以缓存要落在一个共享的Redis/Memcached集群按用户名哈希做分片。TTL也很讲究——定太短起不到挡流量的作用定太长会让释放用户名后无法立即注册。有真实业务量的平台会把删除用户名的操作改成不物理删除而只做标记失效配合短TTL缓存条目和手动失效把两难问题变成可接受的工程权衡。4.2 布隆过滤器1%误判率换百倍内存负缓存解决热点但冷门用户名的回源查询量依旧巨大。这里布隆过滤器就有用了。布隆过滤器是一个概率型数据结构把集合成员信息压缩到一个位数组里查询时永远不会有假阴性——判定不存在的一定不存在但会有假阳性——判定存在的可能其实不存在。对于用户名判断来说这个特性很对口我们允许一个还没被占用的用户名偶尔被误判成已被占用吗如果用户体验要求很高就不允许但如果只是用来做预过滤——布隆过滤器说可用就大胆放行说占用再精确查数据库——那么误判只会增加少量精确查询不会产生真实错误。具体账是这样算的在1%误判率下每个已占用用户名在布隆过滤器里大约占9.6 bit。十亿个已占用用户名就是约1.2GB分散在多台机器上完全可接受相比之下把十亿用户名的精确字符串全部放内存里十几个GB起步还只是原始数据。一个1.2GB的布隆过滤器再加上负缓存基本能把可用性检查里90%以上的回源请求挡住。Instagram这种体量的产品在ID路由、去重、缓存层用概率型结构做预判是公开技术分享里的常见话题具体到某个表某个接口是否用了布隆过滤器不同时期不同团队方案各异但把成员爆炸问题改成位数组的思路是通用且正确的。4.3 布隆过滤器不能删单条怎么办布隆过滤器有个固有问题不支持删除单条元素。如果产品允许一个账号删除后把用户名释放给别人布隆过滤器会持续误判那个已释放的用户名。处理方式有三种不做单人删除用户名释放直接走标记不可用策略这个用户名不会再给别人。很多社交产品其实默认就是这个策略防止有人冒充历史账号。用Counting Bloom Filter给每个位加计数删除时计数减一代价是内存翻好几倍。定期重建布隆过滤器重建窗口期内出现可用性误判就靠数据库兜底。从工程上看多数产品会选第一种或第三种简单、可维护。如果选第三种重建过程要设计成异步批量推进避免一次性把全部用户名塞进过滤器导致CPU瞬间打满。5. 并发注册同一用户名抵达数据库之前和之后并发注册同一用户名是整条链路里最尖锐的测试。注册高峰期一个刚被推荐出去的用户名几万个请求会同时尝试注册。缓存没有命中布隆过滤器判定没有占用然后几万个请求一起往数据库撞。这个时候架构能不能正确落地就看数据库唯一索引怎么接招。5.1 唯一索引兜住并发应用层只处理正常冲突前面反复提到数据库唯一索引现在说并发时它的行为。当多个请求同时对同一个用户名执行插入存储引擎会做唯一性检查保证最终只有一条插入成功其余的拿到duplicate key错误。中间不需要应用层排队也不需要分布式锁存储引擎的行级锁和索引结构天然完成了仲裁。应用层要做的是把duplicate key错误翻译成错误码比如USERNAME_TAKEN然后通过响应返回给客户端。重点来了不要把冲突当成系统错误。它不是5xx它就是一个正常的业务应答——这个用户名刚刚被别人抢走了你再想想。这个语义区分如果做不好监控会天天告警排障的人每天要花大量时间区分是并发冲突还是真故障。5.2 分布式锁不必需但在体验上有价值如果只是插入时用唯一索引仲裁用户体验有个小缺陷用户提交注册结果发现用户名被抢要重新输入。为了降低这种挫败感可以在注册流程开始时对用户名加一个短的分布式锁把检查可用→创建账号→绑定用户名这段流程串行化。注意锁并不解决正确性问题唯一索引才是正确性的保证但锁能让第二个人在获取锁的阶段就知道这个用户名正在被占用而不是等到插入时才失败。对Instagram这类产品语义更丰富的失败原因是很重要的体验。分布式锁也有不少坑锁超时设多长、锁粒度是按用户名还是按用户名哈希桶、锁释放时怎么防止误删别人的锁、锁服务挂了怎么降级。我的建议是不要为了加锁而加锁。先把唯一索引、负缓存、冲突错误码这套链路跑通并发冲突在架构上已经处理完了分布式锁只作为体验优化手段在明确有多人抢热门用户名的产品场景里按需引入。5.3 预占与释放注册没完成时用户名算不算占用最后一个细节很多人忽略用户开始注册但没提交这个用户名要不要立刻显示已被占用从产品角度应该显示。否则用户看到一个可用用户名走完整套注册流程提交时被别人抢走体验非常差。但技术上这意味用户名占用是一个带状态的对象不只是存在/不存在两态。常见方案是注册初始化时插入一条username_status记录状态为PENDING缓存和布隆过滤器都纳入这个状态注册成功或超时后更新为TAKEN或直接删除。这套方案增加了缓存一致性的复杂度但体验收益是实打实的。实现时要给每条预占记录加过期时间否则僵尸预占会污染整个用户名池。过期时间通常取5~10分钟和用户填写注册表单的典型时长对齐。把这几层串起来存储层的唯一索引做裁判缓存层做拦截预占记录管理状态分布式锁做体验优化。一条用户名已被占用的提示背后是一条完整、可降级、可水平扩展的链路。6. 从这套设计里真正能拿去抄的作业最后聊点能直接迁移的。Instagram的公开技术分享里更多提到的是PostgreSQL分片、数据路由层、服务化改造具体的用户名检查接口没有完整公开过——但架构的骨架是清楚的。数据量到千万级以后任何面向C端的产品都值得做一次唯一性检查专项设计而不是继续在业务代码里写SQL。6.1 先看决策阶梯不同规模方案完全不同不要跳级规模方案关键点百万以内单库单表 唯一索引加一层基础缓存挡热点就够了千万级独立用户名→用户ID映射服务加负缓存数据库唯一索引继续兜底亿级以上引入布隆过滤器/多级缓存把回源率压到个位数百分比唯一索引不可绕过这个阶梯是有先后顺序的不要一上来就上布隆过滤器它带来的一致性和重建成本会淹没收益。6.2 几个可复用的避坑经验第一负缓存的TTL必须和业务状态联动比如用户改了用户名旧用户名到底能不能被注册要有一条明确的业务规则不能由缓存过期时间替你决定。第二布隆过滤器的误判率不要贪心0.1%的内存开销是1%的两倍多但收益在大多数业务里几乎没有差别1%就够了。第三所有缓存层都必须有显式的降级开关缓存挂了就直接走数据库不要为了缓存做复杂的多级回源逻辑那才是真正会在故障时把你拖死的设计。6.3 把思路迁移到不能重复的通用需求这套架构不只适用于用户名。优惠码、手机号、邀请链接、分享短链凡是唯一、且需要被高频检查的字段都可以套同一套模板底层用唯一索引做物理约束中间用服务层做水平扩展再上层用负缓存和概率结构挡流量最后用业务状态管理预占和释放。设计的时候先画清楚三条线——数据归属、并发仲裁、缓存一致性架构就不会偏。我在实际项目里用过同样的思路做过邀请码发放系统高峰期几万个请求同时领取同一个活动码应用层加上负缓存和布隆过滤器后数据库最终落地的只有真正在抢码的那几次插入请求核心表几乎不感知流量波动。唯一索引兜底的那一次冲突也被业务侧正确翻译成了已经被领走的提示。所以说用户名已被占用看起来是Instagram的事其实每一个做C端产品的团队早晚都会遇到同一个问题。把这一层想透等你的用户量真的涨上来的时候就不用再回头补课了。
