下面有几种常用方案，可以根据具体业务场景来选择。
1. UUID
UUID 指在一台机器上生成的数字，它保证在同一时空中的所有机器都是唯一的。
UUID 由以下几部分组成：
- 当前日期和时间。
- 时钟序列。
- 全局唯一的IEEE机器识别码（如网卡MAC地址等）。
在Java中，使用UUID 非常方便。
UUID uuid = UUID.randomUUID();
UUID 具有如下优点：
- 使用方便，很容易实现。
- 性能很高。
缺点：
- 没有顺序，不能保证单调递增。
- 太长，总长32位，无论是存储还是传输，缺点都比较明显。
2. SnowFlake 雪花算法
Twitter 的SnowFlake 是一个非常优秀的ID生成方案，实现也比较简单，8Byte 是一个Long，等于64bit，核心代码就是毫秒级时间41位+10位机器ID+毫秒序列12位。
https://github.com/twitter-archive/snowflake
SnowFlake 的优点如下：
- 比UUID 短，一般为9-17位。
- 生成的ID是数字，可以做到单调递增。由于无法统一分布式环境中每台服务器的时钟，它只能做到单台机器单调递增，无法做到全局递增。
- 性能非常出色，吞吐量达到几十万TPS。
SnowFlake的结构如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位DataCenterID和5位WorkerID(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）。
一共加起来刚好64位，为一个Long型。(转换成字符串后长度最多19)
SnowFlake 生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由DataCenterID和WorkerID作区分），并且效率较高。经测试SnowFlake 每秒能够产生26万个ID。
如下SnowFlake 算法生成的2进制和Long 型的唯一ID。
关于《SnowFlake-Java版雪花算法》实现方案和演示，可以查看小编的另外一篇文章。
3. Ticket Server
Ticket Server 是 Flickr 采用的一种分布式ID 生成方案，利用 MySQL 自增长ID 实现。
它的设计思路是利用数据库中 auto increment 的特性和MySQL 特有的 REPLACE INTO 命令来实现，可以利用多台MySQL 实现高扩展性和高可用性。
比如以 2 台MySQL 服务器实例，分别进行配置。
节点一配置：
auto_increment_increment = 2;
auto_increment_offset = 1;
节点二配置：
auto_increment_increment = 2;
auto_increment_offset = 2;
上述配置最好放到配置文件中，否则MySQL 服务器重启将丢失设置。
然后分别在2个库里面，建表，如tickets，设置ENGINE=MyISAM，表级锁，能保证所有 REPLACE INTO 的原子性。不断通过 REPLACE INTO 促使ID 自增，这样表中只有一条记录。
REPLACE INTO tickets (stub) VALUES ('a')
在同一个连接内，通过 last insert id 获取自增的ID 值。
Ticket Server 的优点：
- 对于数据量不是特别大的应用场景，长度最小。
- 如果已经有应用基于 MySQL 的自增ID，那么采用此方案非常容易迁移，而且兼容性好。
这个方案没有绝对的顺序，只能有一个近似的顺序，有可能在某个MySQL 实例的状态跑得快。
总结
如果在高并发、大数据量的情况下，建议采用 SnowFlake 方案，性能突出。
对于并非不大，并且需要兼容老业务的场景下，可以使用 Ticket Server方案，2台MySQL 物理机也能轻松达到 几万TPS，响应时间在毫秒级。
閱讀更多 軟件架構 的文章
