分布式是大型架构核心，下面我详解分布式ID@mikechen
数据库自增ID（集中式自增）
利用单库、或主从库的 auto_increment 作为全局 ID。
优点：
实现 简单，直接利用现有 DB 功能；DBA 易于维护。
ID 单调递增，作为主键索引性能较好。
缺点：
存在数据库 单点 问题，高可用要做主从、集群，架构复杂。
每次获取 ID 都要访问数据库，吞吐有限，对 DB 施加额外压力。
适用：
业务量较小、中小项目或单体应用；
对可用性和扩展性要求不极端的场景。
UUID（通用唯一识别码）
本地随机生成 128 bit 的唯一标识（通常 36 字符串格式）。
优点：
生成 非常简单，纯本地，无网络依赖，性能高。
无中心节点，天然多机分布式，不需要额外基础设施。
缺点：
长度大（128 位，36 字符），作为主键占用空间大且索引效率差。
无序、无业务含义，插入数据库导致页分裂，严重影响写性能。
适用：
更看重解耦和易用性，数据库压力可接受的场景；
只用来做外部追踪、幂等键、日志 Trace ID 等非主键场景。
雪花算法（Snowflake）
Twitter 开源后被广泛使用，国内如美团 Leaf-Snowflake 等实现。
典型结构为：1bit 符号位 + 41bit 时间戳 + 10bit 机器标识 + 12bit 自增序列。
优点：
完全本地生成，无中心服务，高性能、高可用，单机可达数十万甚至上百万 QPS。
按时间趋势递增，长度适中（一般 64 位整数），非常适合作为数据库主键。
缺点：
强依赖机器时钟，时钟回拨会导致 ID 重复或需要停机等待，需额外时钟回拨处理策略。
需要合理分配 机器 ID，并解决自动扩缩容时的重复问题。
适用：
高并发、大规模分布式系统（电商订单、支付流水、日志流水线）；
对 ID 递增性强依赖、又不想依赖中心化服务的场景。
陈睿mikechen
10年+大厂架构经验，资深技术专家，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》