uuid

1，当前日期和时间时间戳
2，时钟序列。计数器
3，全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。

优点：

代码简单，性能好（本地生成，没有网络消耗）
保证唯一（相对而言，重复概率极低可以忽略）

缺点：
每次生成的ID都是无序的，而且不是全数字，且无法保证趋势递增。
UUID生成的是字符串，字符串存储性能差，查询效率慢，写的时候由于不能产生顺序的append操作，需要进行insert操作，导致频繁的页分裂，这种操作在记录占用空间比较大的情况下，性能下降比较大，还会增加读取磁盘次数。
UUID长度过长，不适于存储，耗费数据库性能
ID无一定业务含义，可读性差。
有信息安全问题，有可能泄露mac地址。

数据库自增序列

单机模式
优点：
实现简单，依赖数据库即可，成本小。
ID数字化，单调自增，满足数据库存储和查询性能。
具有一定的业务可读性。（结合业务code）
缺点：
强依赖DB，存在单点问题，如果数据库宕机，则业务不可用
DB生成id性能有限，单点数据库压力大，无法抗住高并发场景。
信息安全问题，比如暴露订单量，url查询改一下id查别人的订单。

leaf-segment

采用每次获取一个Id区间段的方式来解决，区间段用完之后再去数据库获取新的号段，这样一来可以大大减轻数据库的压力。

核心字段：biz_tag，max_id，step
biz_tag用来区分业务，max_id表示该biz_tag目前所分配的ID号段的最大值，step表示每次分配的号段长度，原来每次获取id都要访问数据库，现在只需要把Step设置的足够合理如1000，那么在1000个ID用完之后再去访问数据库。

优点：
扩张灵活，性能强足够撑起大部分场景
ID号码是趋势递增的，满足数据库存储和查询性能的要求。
可用性高，即使ID生成服务器不可用，也能够使得业务在短时间内可用
缺点：
可能存在多个节点同时请求ID区间的情况，依赖DB

双buffer

将获取一个号段的方式优化成获取两个号段，在一个号段用完之后不用立马去更新号段，还有一个缓存号段备用，这样能够有效解决这种冲突问题，而且采用双buffer的方式，在当前号段消耗了10%的时候就去检查下一个号段有没有准备好，如果没有准备好就去更新下一个号段，当当前号段用完之后就切换到下一个已经准备好的号段去使用，同时在下一个号段消耗到10%的时候，又去检查下一个号段有没有准备好，如此往复。

优点：
基于jvm存储双buffer的号段，减少了数据库查询，减少网络依赖，效率更高

缺点：
segment号段的长度是固定的，业务量大时可能会频繁更新号段，因为原本分配的号段会一下用完。
如果号段长度设置的过长，但凡缓存中有号段没有消耗完，其他节点重新获取的号段与之前相比可能会跨度很大。动态调整Step。

基于redis、mongodb、zk等中间件生成

雪花算法

生成一个64bit的整数数字
第一位符号固定为0,41位时间戳，10位workId，12位系列号
位数可以有不同实现。

优点：
每个毫秒值包含的ID值很多，不够可以变动位数来增加，性能佳（依赖workId的实现）
时间戳值在高位，中间是固定的机器码，自增的序列在低位，整个ID是趋势递增的。
能够根据业务场景数据库节点布置灵活挑战bit位划分，灵活度高。
缺点：
强依赖机器时钟，如果时钟回拨，会导致重复的id生成，所以一般基于此的算法发现时钟回拨，都会抛异常处理，阻止id生成，这可能会导致服务不可用。