uuid
UUID由以下几部分的组合：
（1）当前日期和时间。
（2）时钟序列。
（3）全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。
标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)，以连字号分为五段形式的36个字符，示例：550e8400-e29b-41d4-a716-446655440000
优点：性能非常高：本地生成，没有网络消耗。
缺点：太长
SnowFlake雪花算法（美团）64-bit
1 符号位 +
41时间戳（当前时间戳- 开始使用的时间戳） +
10机器标示（5位机房id+5位机器id） +
12位序列（毫秒内的计数，12位的计数顺序号支持每个节点每毫秒(同一机器，同一时间截)产生4096个ID序号）
优点：
简单高效，生成速度快。
时间戳在高位，自增序列在低位，整个ID是趋势递增的，按照时间有序递增。
灵活度高，可以根据业务需求，调整bit位的划分，满足不同的需求。
qps：409w/s
缺点
依赖机器的时钟，如果服务器时钟回拨，会导致重复ID生成。
在分布式环境上，每个服务器的时钟不可能完全同步，有时会出现不是全局递增的情况。
数据库自增id
优点：简单，可靠性高。
确定：依赖数据库，id生成依赖数据库的写性能
数据库优化：根据步长，搞多台数据库
缺点：定义好步长之后不易扩展。写还是依赖数据库
优化：数据库定义
+-------------+--------------+------+-----+-------------------+-----------------------------+-----------------------------+
| Field | Type | Null | Key | Default | Extra | commoent
+-------------+--------------+------+-----+-------------------+-----------------------------+-----------------------------+
| type | varchar(128) | NO | PRI | | | 业务
| max_id | bigint(20) | NO | | 1 | | 最大的id
| step | int(11) | NO | | NULL | | 步长
| desc | varchar(256) | YES | | NULL | | 业务描述
| update_time | timestamp | NO | | CURRENT_TIMESTAMP | on update CURRENT_TIMESTAMP | 更新时间
+-------------+--------------+------+-----+-------------------+-----------------------------+-----------------------------+
重要字段说明：type用来区分业务，max_id表示该type目前所被分配的ID号段的最大值，step表示每次分配的号段长度。原来获取ID每次都需要写数据库，现在只需要把step设置得足够大，比如1000。那么只有当1000个号被消耗完了之后才会去重新读写一次数据库。读写数据库的频率从1减小到了1/step
缺点：
ID号码不够随机，能够泄露发号数量的信息，不太安全。
TP999数据波动大，当号段使用完之后还是会hang在更新数据库的I/O上，tg999数据会出现偶尔的尖刺。
DB宕机会造成整个系统不可用。
