uuid
UUID是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。
UUID由以下几部分的组合：
- UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同。
- 时钟序列。
- 全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。
优点：代码简单, 性能好(本地生成，没有网络消耗)，保证唯一(相对而言，重复概率极低可以忽略)
缺点:
- 每次生成的ID都是无序的，而且不是全数字，且无法保证趋势递增。
- UUID生成的是字符串,字符串存储性能差，查询效率慢，写的时候由于不能产生顺序地append操作，需要进行insert操作，导致频繁的页分裂，这样操作在记录占用空间比较大的情况下，性能下降比较大，还会增加读取磁盘次数
- UUID长度过长，不适用于存储，消耗数据库性能
- id无一定业务含义,可读性差。
- 有信息安全问题，有可能泄露mac地址
数据库自增序列
单机模式
优点：
- 实现简单，依靠数据库即可，成本小。
- ID数字化,单调自增,满足数据库存储和查询性能。
- 具有一定的业务可读性。(结合业务code)
缺点:
- 强依赖DB，存在单点问题，如果数据库宕机，则业务不可用。
- DB生成ID性能有限，单点数据库压力大，无法扛高并发场景。
- 信息安全问题，比如暴露订单量，url查询改一下id查到别的订单。
数据库高可用模式(多主模式做负载，基于序列的起始值和步长设置，不同的初始值，相同的步长，步长大于节点数)
优点:
- 解决了ID生成的单点问题，同时平衡了负载。
缺点:
- 系统扩容困难: 系统定义好步长之后，加机器之后调整步长困难。
- 数据库压力大: 每次获取一个ID都必须读写一次数据库。
- 主从同步的时候: 电商下单->支付insert master db select数据,因为数据同步延迟导致查不到这个数据。加cache(不是最好的解决方式)数据要求比较严谨的话查master主库。
Leaf-segment (叶端)
采用每次获取一个ID区间段的方式来解决，区间段用完了之后再去数据库获取新的号段，这个一来可以大大减轻数据库的压力
核心字段: biz_tag, max_id, setp
biz_tag用来区分业务,max_id表示biz_tag目前所被分配的ID号段的最大值，setp表示每次分配的号段长度，原来每次获取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生成，这可能导致服务不可用。
