不能直接用数据库自增ID做分布式ID，因为跨库/分表时无法保证全局唯一和趋势递增，导致ID重复、路由失效、数据倾斜；推荐Snowflake变体（如sonyflake）或Redis INCR+时间戳方案。
为什么不能直接用数据库自增ID做分布式ID
微服务拆分后，多个服务可能同时写入不同数据库实例，甚至同一库的分表。数据库自增ID在单实例下是递增的，但跨实例时无法保证全局唯一和趋势递增——比如两个MySQL主库各自生成 1, 2, 3，ID就重复了；分库分表中间件（如ShardingSphere）也依赖ID本身做路由，若ID不带分片信息或无序，会导致路由失效、热点写入。
- 自增ID无法跨节点协调，本质是本地序列
- 某些ORM（如GORM）默认用
SELECT LAST_INSERT_ID()取刚插入的ID，但在读写分离+延迟从库场景下可能读到旧值 - 分库键若依赖ID，而ID无业务含义且无散列特征，容易导致数据倾斜
推荐方案：Snowflake变体 + 时间戳前置的64位整数
Go生态中最成熟、低延迟、无中心依赖的方案是基于Snowflake思想的实现，比如 sony/sonyflake 或更可控的 facebookarchive/snowflake Go移植版（注意后者已归档，建议用社区维护分支）。核心是把64位拆成：1位符号位（固定0）+ 41位毫秒时间戳 + 10位节点ID + 12位序列号。
-
sony/sonyflake默认用MAC地址哈希生成机器ID，启动时自动分配，适合容器化部署；但需确保MAC不重复（K8s Pod默认网络命名空间隔离，一般OK） - 时间戳部分只占41位，理论可用约69年（从2019年基线起），够用；但若系统时钟回拨，
sonyflake.Next()会阻塞直到时钟追上，生产环境建议开启NTP校准并禁用手动改时 - 序列号满（每毫秒4096个）时会等待下一毫秒，所以峰值QPS > 4096时需靠多节点（10位节点ID最多支持1024个实例）分摊
示例：
sf := sonyflake.NewSonyflake(sonyflake.Settings{})
id, _ := sf.NextID()
// 返回 uint64，例如 1234567890123456789
需要更高吞吐或规避时钟回拨？考虑Redis INCR + 时间戳拼接
当单机Snowflake扛不住（比如每毫秒要发几万个ID），或对时钟敏感度高（金融类系统不允许任何等待），可用Redis做轻量协调：
立即学习“go语言免费学习笔记（深入）”；
- 用
INCR命令获取单调递增序列，配合当前毫秒时间戳拼成唯一ID（如timestamp ） - 必须用单个Redis节点（或Redis Cluster中固定hash tag保证落到同slot），避免多节点INCR不一致
- 要加超时重试逻辑：若Redis超时，可降级为本地Snowflake ID（带标记位区分来源），后续通过离线比对补漏
- 注意Redis原子性仅限单命令，
GET + INCR不行，必须用EVAL脚本或INCR本身
常见坑：
- 直接用
time.Now().UnixMilli()拼接而不做位移对齐，会导致ID长度不固定、排序异常 - Redis连接池没设好，高并发下
INCR毛刺明显，反而不如本地Snowflake稳定
别忽略ID的“可读性”和“调试友好性”
线上查问题时，运维常要从日志里的ID反推生成时间、服务实例。纯数字ID（如1234567890123456789）看不出任何上下文。
- 可在Snowflake基础上，把10位节点ID映射为服务名缩写（如
order-srv-01→0x0A），日志打印时解码展示 - 或生成时额外存一份映射：
map[uint64]struct{ ts time.Time; svc string }（仅调试环境启用，不进主链路） - 更务实的做法：所有服务统一打日志字段
trace_id和service_name，ID本身保持紧凑二进制语义，调试时关联查即可
真正难的不是生成一个唯一ID，而是让这个ID在分库分表、消息投递、日志追踪、监控告警多个环节里不掉链子。时间戳精度、节点标识稳定性、降级路径是否闭环，这三处出问题的概率远高于算法本身。
