分布式ID的特性
- 全局唯一
不能出现重复的ID，这是最基本的要求。
- 递增
有利于关系数据库索引性能。
- 高可用
既然是服务于分布式系统，为多个服务提供ID服务，访问压力一定很大，所以需要保证高可用。
- 信息安全
如果ID是有规律的，就容易被恶意操作，在一些场景下需要ID无规则。
生成方案
UUID
核心思想是结合机器的网卡、当地时间、一个随机数来生成。
优点：
- 性能非常高，本地生成，没有网络消耗。
- 生成简单，没有高可用风险。
- 有利于信息安全，因为可读性差，无规律。
缺点：
- 太长，不易于存储。
- 有利于信息安全的同时，也有不安全性，因为基于MAC地址生成的算法可能会泄露MAC地址。
- 无序，对MySQL索引不利，在 InnoDB 中，无序性会导致数据位置频繁变动，性能低下。
数据库
利用数据库自增ID的特性来生成，如 MySQL 的 auto_increment。
优点：
- 简单，利用数据库自有功能实现。
- 绝对有序。
缺点：
- 有重复发号的风险，例如数据库主从切换的场景。
- 需要特别保障其高可用。
- 发号性能限制于数据库性能，如需提高发号能力，需要扩充数据库，成本高。
Redis
Redis 提供了自增的原子命令，可以保证唯一、有序。
优点：
- 简单，自有能力。
- 高并发环境下性能好，优于数据库。
- 维护成本低于数据库。
缺点：
- 主从切换时也可能会重复发号。
- 需要特别保障其高可用。
雪花算法
给每台机器分配一个唯一标识，然后通过下面的结构实现全局唯一ID：
时间戳 + 机器标识 + 自增序列号
毫秒在高位，自增序列在低位，一定是递增的。
优点：
- 生成性能高。
- 灵活，可以根据自身业务特点分配bit位。
缺点：
- 强依赖机器时钟，如果时钟回拨，就会导致服务异常。
小结
不同的方案有不同的特点，需要根据自己的需求场景来选择适合的。
例如在美团早期，ID方案就是多种形式的：
- 有的业务通过 DB 自增的方式生成
- 有的业务通过 Redis 缓存来生成
- 有的业务直接用 UUID 生成
后来推出了一个类雪花算法的分布式ID服务：Leaf，QPS压测结果近5w/s。
项目地址：
https://github.com/Meituan-Dianping/Leaf
再推荐2个参考项目：
- 基于 Redis 的生成器
https://github.com/hengyunabc/redis-id-generator
- 百度基于雪花算法的生成器
https://github.com/baidu/uid-generator
