分布式ID生成策略

UUID
优点：方便快捷。
缺点：MySQL官方不推荐使用，字符太长、非自增主键（没有一定规律）。
数据库自增
优点：方便快捷。
缺点：只能应用于单体数据库架构。
多主模式数据库自增
优点：方便快捷、高可用。
缺点：分布式下ID会重复（每台数据库服务器自增规律相同）。
解决：设置步长（步长=数据库服务器数量）。
号段
预加载一定数量的ID，减少数据库压力，可设置半数加载机制，再次获取时根据当前最大ID（号段长度）获取。
Redis
优点：避免频繁请求数据库消耗大量资源，吞吐量高10W+，MySQL1000+。
缺点：基本只能单机，否则如果搭建了主从复制和哨兵模式后同步异步也会有ID重复的问题，利用incr(自增)命令和incrby(步长)命令。
滴滴Tinyid
原理基于号段，做了封装（根据步长、中间值、总量、现有量、批量数），客户端机制JAR包直接调用方法，与数据库的交互获取号段可以交给Service去做，直接调用Service中获取的ID，无需调用数据库。
雪花算法（Twitter-Snowflake）
一个8位Long，64位Bit，第一位不使用，后41位代表当前电脑时间戳毫秒数（最大数为2的41次方也就是69年）后10位代表工作机器ID，最后12位代表序列号，64位代表每台机器在同一毫秒内可以生成2的12次方也就是4096个分布式ID。
由于该算法是基于本地电脑时间，如果产品上线后，由于某种原因集群服务器时间需要同步，则可能出现时钟回拨现象。
时钟回拨：获取的当前时间毫秒数小于上一次获取的时间毫秒数，称之为时钟回拨，不过雪花算法有自己的处理策略，如果出现始终回拨现象，会直接抛出异常，若发现获取的当前时间毫秒数等于上一次获取的时间毫秒数，则对序列号进行++操作，进行++操作后会判断该序列号是否已经超出序列号可容纳最大值(4096)，若超出最大值则代表当前毫秒数并发量太大，超出了4096个，则自旋判断判断是否迎来了下一秒，若没有则一直自旋到迎来下一秒为止，最后在通过算法拼接出一个最多19位的Long类型分布式ID。
百度UidGenerator
原理基于雪花算法，不同点是雪花算法需要自己配置一个工作机器ID，百度UidGenerator通过策略自动生成工作机器ID。配置在Spring.xml中，启动时自动生成工作机器ID，使用前需要在数据库创建一张插件所需要用到的表，但是该插件的问题也比较多，也不支持集群，而且百度也很久不做更新，所以实际开发环境中不推荐使用。
美团Leaf
优点：同时支持号段模式和雪花算法。
号段模式：与滴滴相差无异。
雪花算法：利用Zookeeper解决了工作机器ID问题，每个应用在使用Leaf-Snowflake时，启动时都会都在Zookeeper中生成一个持久顺序ID，相当于一台机器对应一个持久顺序节点，也就是一个工作机器节点，生成出的分布式ID格式为：IP:HOST:十位的持久有序Znode节点，因为Zk挂掉会自动把ID持久化在本地，所以也实现了高可用，最后在通过算法拼接出一个最多19位的Long类型分布式ID。