方法一：基于数据库生成
A库、B库、C库支持同时写入
A库初始值为1，自增为3，获取的值一次是1、4、7
B库初始值为2，自增为3，获取的值一次是2、5、8
C库初始值为3，自增为3，获取的值一次是6、6、9
获取ID时可从三库轮询获取
优点
此方法使用数据库原有的功能，所以相对简单
能够保证唯一性
能够保证递增性
id 之间的步长是固定且可自定义的
缺点
数据库的写压力依然很大，每次生成ID都要访问数据库
丧失了ID生成的“绝对递增性”：先访问DB 01生成0,3，再访问DB 02生成1，可能导致在非常短的时间内，ID生成不是绝对递增的
方法二：单点批量ID生成服务
数据库使用双master保证可用性，数据库中只存储当前ID的最大值
ID生成服务假设每次从数据库批量拉取5个ID，并将当前ID的最大值修改为5，这样应用访问ID生成服务索要ID，ID生成服务不需要每次访问数据库，就能依次派发1,2,3,4,5这些ID了;当ID生成服务用完了已拉取的ID之后，再去数据库拉取5个ID，然后将数据库中存储的最大值改为10，这样数据库的压力就降低到原来的1/6。
ID生成服务做成集群，从数据库获取来的id可放入缓存（redis），当需要从数据库获取新的ID时，使用分布式锁来控制，只需要其中一台服务去数据库获取
优点：
保证了ID生成的绝对递增有序
大大的降低了数据库的压力，ID生成可以做到每秒生成几万几十万个
缺点：
ID生成服务如果挂了，服务重启起来之后，继续生成ID可能会不连续
虽然每秒可以生成几万几十万个ID，但毕竟还是有性能上限，无法进行水平扩展
方法三：UUID
优点
本地生成ID，不需要进行远程调用，时延低
扩展性好，基本可以认为没有性能上限
缺点
无法保证趋势递增
UUID过长，往往用字符串表示，作为主键建立索引查询效率低，常见优化方案为转化为两个uint64整数存储或者折半存储
方法四：取当前毫秒数
优点
本地生成ID，不需要进行远程调用，时延低
生成的ID趋势递增
生成的ID是整数，建立索引后查询效率高
缺点
如果并发量超过1000，会生成重复的ID
方法五：使用 Redis 来生成 id
当使用数据库来生成ID性能不够要求的时候，我们可以尝试使用Redis来生成ID。这主要依赖于Redis是单线程的，所以也可以用生成全局唯一的ID。可以用Redis的原子操作 INCR 和 INCRBY 来实现。
优点
依赖于数据库，灵活方便，且性能优于数据库。
数字ID天然排序，对分页或者需要排序的结果很有帮助。
缺点
需要编码和配置的工作量比较大。
方法六：Twitter 开源的 Snowflake 算法
snowflake的结构如下(每部分用-分开)
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）
一共加起来刚好64位，为一个Long型。(转换成字符串后长度最多19)
snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。经测试snowflake每秒能够产生26万个ID。
方法七：基于分布式集群协调器生成
以强一致性为目标的：ZooKeeper为代表
以最终一致性为目标的：Consul为代表