​ 在应用程序中，经常需要全局唯一的ID作为数据库主键。如何生成全局唯一ID？

​ 首先，需要确定全局唯一ID是整型还是字符串？如果是字符串，那么现有的UUID就完全满足需求，不需要额外的工作。缺点是字符串作为ID占用空间大，索引效率比整型低。

​ 如果采用整型作为ID，那么首先排除掉32位int类型，因为范围太小，必须使用64位long型。

​ 采用整型作为ID时，如何生成自增、全局唯一且不重复的ID？

方案一：数据库自增

​ 利用数据库的自增ID，从1开始，基本可以做到连续递增。Oracle可以用SEQUENCE，MySQL可以用主键的AUTO_INCREMENT，虽然不能保证全局唯一，但每个表唯一，也基本满足需求。

​ 数据库自增ID的缺点是数据在插入前，无法获得ID。数据在插入后，获取的ID虽然是唯一的，但一定要等到事务提交后，ID才算是有效的。有些双向引用的数据，不得不插入后再做一次更新，比较麻烦。

方案二：基于redis生成全局id策略

​ 采用一个集中式ID生成器，它可以是Redis，也可以是ZooKeeper，也可以利用数据库的表记录最后分配的ID。

​ 这种方式最大的缺点是复杂性太高，需要严重依赖第三方服务，而且代码配置繁琐。一般来说，越是复杂的方案，越不可靠，并且测试越痛苦。

方案二：UUID

UUID:性能高，本地生成，没有网络消耗。

缺点： 入库性能差。无法预测它的生成顺序，不能生成递增有序的数字，MySQL推荐主键越短越好，UUID36字符明显不符合要求。

最重要的是，MySQL的主键也是索引，MySQL的索引是通过btree,每一次新的无序UUID数据的插入，为了维持顺序，会对bree进行大量的修改，大大降低了数据库插入的性能。

方案四：Snowflake

​ 类似Twitter的Snowflake算法，它给每台机器分配一个唯一标识，然后通过时间戳+标识+自增实现全局唯一ID。这种方式好处在于ID生成算法完全是一个无状态机，无网络调用，高效可靠。缺点是如果唯一标识有重复，会造成ID冲突。

​ Snowflake算法采用41bit毫秒时间戳，加上10bit机器ID，加上12bit序列号，理论上最多支持1024台机器每秒生成4096000个序列号，对于Twitter的规模来说够用了。

​ 但是对于绝大部分普通应用程序来说，根本不需要每秒超过400万的ID，机器数量也达不到1024台，所以，我们可以改进一下，使用更短的ID生成方式。