背景
在大型互联网应用中，随着业务量的增大，数据库中单表的数据量会达到千万、上亿的量级，为缓解数据库压力，往往采取分库分表的策略。分库分表后需要有一个唯一ID来标识一条数据或消息，数据库的自增ID显然不能满足需求，此时就需要有一个能够生成全局唯一ID的系统。全局唯一ID有几个特性：
1、全局唯一性：不能出现重复的ID号，这是最基本的要求。
2、趋势递增：以MySQL为例 Mysql InnoDB引擎中使用的是聚集索引，由于多数RDBMS使用B-tree的数据结构来存储索引数据，在主键的选择上面我们应该尽量使用有序的主键保证写入性能。
3、高性能：ID生成响应要块，否则反倒会成为业务瓶颈
4、高可用：复杂的分布式系统中，业务对分布式ID生成系统可用性要求极高，比如：订单系统、优惠券、仓库系统等因为分布式ID生成系统瘫痪从而导致一些核心业务无法进行，会引发一场灾难
我们要树立一个理念，没有完美的解决方案，每种方案都有优缺点，在具体的选择上要根据具体的业务选择合适的方案。
一：UUID （不推荐）
在用到全局唯一id时，我们很容易想到UUID，毕竟它有着全球唯一的特性。
UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：550e8400-e29b-41d4-a716-446655440000
像用作订单号UUID这样的字符串没有丝毫的意义，看不出和订单相关的有用信息；而对于数据库来说用作业务主键ID，它不仅是太长还是字符串，存储性能差查询也很耗时，所以不推荐用作分布式ID。
优点：
性能非常高：本地生成，没有网络消耗。
缺点：
1、不易于存储：UUID太长，16字节128位，通常以36长度的字符串表示，很多场景不适用。MySQL官方明确建议主键要尽量越短越好
2、无序的字符串，不具备趋势自增特性。作为数据库主键 UUID 的无序性会导致数据位置频繁变动，严重影响性能。
3、没有具体的业务含义。比如：用于订单号，这样的字符串显然没有意义。
二：利用数据库自增特性
具体实现是，单独创建一个Mysql实例，设置主键属性为auto_increment，当我们需要一个id时，往数据库中插入一条数据拿到该记录的主键id，如：利用SELECT LAST_INSERT();
优点：
实现简单，利用数据库系统特性实现
缺点：
强依赖DB，如果数据库宕机，就是引发致命问题，也可以利用集群部署保证高可用，但要考虑主从复制模式下数据一致性问题；多台机器不能生成重复id（可以设置不同的起始值和自增步长）
三：利用数据库号段模式
可以理解为从数据库批量的获取自增ID，每次从数据库取出一个号段范围，比如1~1000，可以想下如果每次获取ID都得读写一次数据库，势必会对数据库造成较大压力。顺便说下号段模式是目前很多分布式ID生成器的主流实现方式之一
CREATE TABLE id_sequence (
id int(10) NOT NULL,
max_id bigint(20) NOT NULL COMMENT '当前最大id',
step int(10) NOT NULL COMMENT '号段的步长',
biz_tag varchar(128) NOT NULL COMMENT '业务类型',
version int(20) NOT NULL COMMENT '版本号',
desc varchar(256) COMMIT '描述'
PRIMARY KEY (`id`)
)
biz_tag ：代表不同业务类型
max_id ：当前最大的可用id
step ：代表号段的长度
version ：是一个乐观锁，每次都更新version，保证并发时数据的正确性
四：基于Redis实现
Redis的所有命令操作都是单线程的，本身提供像 incr 和 increby 这样的自增原子命令，所以能保证生成的 ID 肯定是唯一有序的
需要考虑用集群方式保证可用性和高性能(高吞吐量)，同时需要主要考虑redis持久化
五：雪花算法（Snowflake）
这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图所示：
Snowflake ID组成结构：正数位（占1比特）+ 时间戳（占41比特）+ 机器ID（占5比特）+ 数据中心（占5比特）+ 自增值（占12比特），总共64比特组成的一个Long类型。
第一个bit位（1bit）：Java中long的最高位是符号位代表正负，正数是0，负数是1，一般生成ID都为正数，所以默认为0。
时间戳部分（41bit）：毫秒级的时间，不建议存当前时间戳，而是用（当前时间戳 - 固定开始时间戳）的差值，可以使产生的ID从更小的值开始；41位的时间戳可以使用69年，(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年
工作机器id（10bit）：也被叫做workId，这个可以灵活配置，机房或者机器号组合都可以。
序列号部分（12bit），自增值支持同一毫秒内同一个节点可以生成4096个ID
根据这个算法的逻辑，只需要将这个算法用Java语言实现出来，封装为一个工具方法，那么各个业务应用可以直接使用该工具方法来获取分布式ID，只需保证每个业务应用有自己的工作机器id即可，而不需要单独去搭建一个获取分布式ID的应用。
各个厂商实现的分布式生成器
美团(Leaf) 支持Leaf-segment数据库方案和Leaf-snowflake方案
百度（uid-generator） uid-generator是基于Snowflake算法实现的，与原始的snowflake算法不同在于，uid-generator支持自定义时间戳、工作机器ID和 序列号 等各部分的位数，而且uid-generator中采用用户自定义workId的生成策略。
滴滴（Tinyid） 基于号段模式
阿里（Sequence）类似号段模式
