搜索结果： "分布式ID" (17)
分片友好的主键：ID 里埋下路由基因
分库之后，全表共享的自增主键第一个阵亡——每个分片各自从 1 数起，撞车只是时间问题。全局唯一、趋势递增、还能算出路由，分片主键的三重身份缺一不可；基因法把分片键的哈希直接埋进 ID，让订单号自己会走路。
收官复盘：一张作战地图串起整个系列
十六篇走完，从订单号撞车讲到踩坑清单。症状速查表、三条铁律、十项上线检查——把分布式 ID 的全部家当收进一张作战地图，下次再遇到发号问题，先翻这张图。
踩坑实录：前十四篇没写透的七个坑
前端拿到的 ID 尾号集体变 0，秒级时间戳八年后到期，多活机房发号撞车——这些坑不在架构图里，在生产事故清单里。七个高频翻车点逐个复盘：现象、根因、解法，一次清算。
高可用与降级：发号服务挂了怎么办
发号服务是单点中的单点：它一挂，全公司下单链路跟着挂。三道缓冲加一级降级阶梯——DB 挂了本地号段顶上，发号服务挂了雪花兜底，兜底 ID 打上标记可追溯。预案写在文档里没用，演练进了排期表才算数。
分片基因：把路由信息写进 ID
订单表分了二百五十六张，拿到订单号却不知道它在哪张表。路由表多一次查询，广播全库杀鸡取卵，基因法一步到位——把 user_id 的路由基因嵌进 ID 里，ID 自己会认路。代价也明码标价：分片规则从此焊死在号上。
ID 的安全账：别让 ID 泄了底
订单号连号被爬虫一晚扫穿，这是趋势递增的另一面。ID 会泄露规模、增速、机器数，还会招来遍历攻击。归属校验是根，外部 ID 加密映射是墙，跳号混淆是烟幕——三层防线各管一段。
趋势递增的艺术：B+ 树偏爱什么样的主键
同样是趋势递增，有的 ID 插表丝滑，有的把 B+ 树搅得稀碎。页分裂、碎片率、缓存命中三个指标看懂主键的代价，再分清严格单调与趋势递增的边界——递增是索引的蜜糖，也是安全的砒霜。
开源选型：从 Leaf 到 UidGenerator
原理都懂了，落地别手搓。美团 Leaf 的双模式、百度 UidGenerator 的 RingBuffer、滴滴 Tinyid 的 HTTP+SDK，三大开源发号器横评：发号模式、依赖、吞吐、时钟依赖一张表看穿，再送一棵选型决策树。
Redis 发号器：简单背后的两本账
短链、券码这类小场景犯不着养发号服务，Redis INCR 一行搞定。单线程原子自增是真省心，但两本账要算清：持久化回档号会跳，主从切换号会回——号有洞能忍，号有重不能忍。