分布式是大型架构核心，下面我详解分布式ID@mikechen
数据库自增ID（集中式自增）
这种方案通过数据库预分配ID号段，例如每次从数据库获取一个号段（如1000-2000），然后在内存中递增分配。
典型实现如美团的Leaf系统，支持号段和Snowflake两种模式。
优点：
- ID有序递增，便于排序和分页。
- 可自定义ID结构，融入业务含义（如时间戳+号段）。
- 高可用，通过数据库集群或双写机制避免单点故障。
- 性能较高，批量获取号段减少数据库访问。
缺点：
- 依赖数据库，数据库故障可能导致ID生成中断（虽可通过缓存缓解）。
- 号段耗尽时需访问数据库，存在一定延迟。
- 系统扩容时需注意号段分配，避免浪费或冲突。
- 实现复杂度较高，需要处理号段边界和并发。
UUID（通用唯一识别码）
UUID（Universal Unique Identifier）UUID是一种标准化的128位唯一标识符。
通常以36位字符串形式表示（如“123e4567-e89b-12d3-a456-426614174000”）。
它基于时间、随机数和节点信息生成，不依赖外部系统。
优点：
- 生成简单且快速，本地生成，无需网络调用，性能极高。
- 全局唯一性强，几乎不可能重复（碰撞概率极低）。
- 无需协调，适用于高度分布式的环境。
缺点：
- ID长度过长（通常36字符），存储和传输消耗空间大，不适合作为数据库主键（索引效率低）。
- 无序，无法体现时间或业务含义，不易排序或调试。
- 字符串格式不友好，查询时可能需要额外处理。
雪花算法（Snowflake）
nowflake是一种64位ID生成算法，由Twitter开源。
将64位分为：41位时间戳、10位机器ID、12位序列号（每毫秒可生成4096个ID）。
优点：
- ID有序递增（按时间粗有序），便于排序和索引。
- 高性能，每秒可生成数百万ID，无需外部依赖。
- 分布式友好，通过机器ID避免冲突，支持数据中心扩展。
- ID较短（长整型），存储效率高。
缺点：
- 强依赖系统时钟，如果时钟回拨可能导致ID重复（需添加时钟检查机制）。
- 时间戳从特定纪元开始（如Twitter的2010年），需注意溢出问题（约69年后）。
- 机器ID需手动配置或动态分配，扩容时需谨慎。
Redis自增ID
利用Redis的原子自增操作（INCR或HINCRBY）生成ID，可结合时间戳或其他前缀实现唯一性。
Redis作为分布式缓存，支持集群模式。优点：
- 简单易实现，原子操作保证唯一性。
- 高性能，Redis支持每秒数万次操作。
- ID有序递增，可读性强。
- 灵活，可结合Lua脚本或Pipeline优化。
缺点：
- 依赖Redis，单点故障时需集群高可用（增加复杂度）。
- 持久化问题，如果Redis重启未持久化，可能丢失ID或重复。
- 网络开销，每次生成需调用Redis，延迟高于本地生成。
- 扩容时需处理数据迁移，避免ID冲突。
作者简介
陈睿|mikechen，10年+大厂架构经验，BAT资深面试官，就职于阿里巴巴、淘宝、百度等一线互联网大厂。
关注作者「mikechen」公众号，获取更多技术干货！
后台回复【架构】，即可获取《阿里架构师进阶专题全部合集》，后台回复【面试】即可获取《史上最全阿里Java面试题总结》