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