方案：
一、UUID
UUID(Universally Unique Identifier)是32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符。其中32个字符和4个连字符' - '，一般我们使用的时候会将连字符删除 uuid.toString().replaceAll("-","")。
目前UUID的产生方式有5种版本，每个版本的算法不同，应用范围也不同。
- 基于时间的UUID - 版本1：这个一般是通过当前时间，随机数，和本地Mac地址来计算出来，可以通过
org.apache.logging.log4j.core.util包中的UuidUtil.getTimeBasedUuid()来使用或者其他包中工具。由于使用了MAC地址，因此能够确保唯一性，但是同时也暴露了MAC地址，私密性不够好。 - DCE安全的UUID - 版本2DCE（Distributed Computing Environment）安全的UUID和基于时间的UUID算法相同，但会把时间戳的前4位置换为POSIX的UID或GID。这个版本的UUID在实际中较少用到。
- 基于名字的UUID（MD5）- 版本3基于名字的UUID通过计算名字和名字空间的MD5散列值得到。这个版本的UUID保证了：相同名字空间中不同名字生成的UUID的唯一性；不同名字空间中的UUID的唯一性；相同名字空间中相同名字的UUID重复生成是相同的。
- 随机UUID - 版本4根据随机数，或者伪随机数生成UUID。这种UUID产生重复的概率是可以计算出来的，但是重复的可能性可以忽略不计，因此该版本也是被经常使用的版本。JDK中使用的就是这个版本。
- 基于名字的UUID（SHA1） - 版本5和基于名字的UUID算法类似，只是散列值计算使用SHA1（Secure Hash Algorithm 1）算法。
我们 Java中 JDK自带的 UUID产生方式就是版本4根据随机数生成的 UUID 和版本3基于名字的 UUID，有兴趣的可以去看看它的源码。
public static void main(String[] args) {
//获取一个版本4根据随机字节数组的UUID。
UUID uuid = UUID.randomUUID();
System.out.println(uuid.toString().replaceAll("-",""));
//获取一个版本3(基于名称)根据指定的字节数组的UUID。
byte[] nbyte = {10, 20, 30};
UUID uuidFromBytes = UUID.nameUUIDFromBytes(nbyte);
System.out.println(uuidFromBytes.toString().replaceAll("-",""));
}
好处：生成简单，每个系统本地生成就可以。
坏处：太长和无序，会导致以下问题：
1、很多业务场景不适用，比如优惠券的发放，可能12位的券池就能满足发放的需要了，太长不但不易于存储，还会导致无法用于券码的展示
2、不利于做索引。mysql存储时，uuid的长度太长不利于做主键，而且无序性会导致作为主键插入时数据位置频繁变动，影响性能
所以，很多场景或者用于主键的情况下，都不能使用uuid
二、数据库自增主键
可以创建一个表，通过数据插入获取对应的自增主键，作为全局唯一id
缺点也很明显，就是高并发的场景下，受限于单台mysql的性能。而且可用性差，DB出现问题会导致id无法生成。
当然可以通过主从的方式增强可用性，同时增加表采用不同自增步长的方式增加并发性能，比如假设我们要部署3台机器，步长需设置为3，每台的初始值依次为1,2.3；但是还会带来新的问题，比如不利于拓展，想提升性能就要堆机器，但是步长已经确定不好更改，主从延迟会导致唯一id的不唯一，。
三、snowflake
这是twitter开源的分布式id生成算法，这种方案把64-bit分别划分成多段，分开来标示机器、时间等，比如在snowflake中的64-bit分别表示如下图（图片来自网络）所示：
上面第一个部分，是1个bit：0，这个是无意义的上面第二个部分是41个bit：表示的是时间戳；上面第三个部分是5个bit：表示的是机房id，10001上面第四个部分是5个bit：表示的是机器id，1 1001上面第五个部分是12个bit：表示的序号，就是某个机房某台机器上这一毫秒内同时生成的id的序号，0000 00000000
优点:灵活，5位可以用来做业务标识
缺点:比较依赖时钟