当前各大主流关系型数据库都提供了自增主键生成策略，如Mysql的AUTO_INCREMENT，Sql Server的IDENTITY，Oracle则是通过SEQUENCE来实现主键自增。使用自增主键，比较简单，占用空间较小；主键按顺序增长存放，不会产生页分裂；同时也有一些不足，如多个系统之间集成数据时，容易有主键冲突；单表自增对于数据库单表压力较大，不适用于高并发及分布式场景，自增主键容易被探知到系统业务量等。由此可见在系统业务量较小，并发量不大时使用自增主键不失为一种较好的选择，但是当面对高并发、分布式需求时，使用自增主键会存在较大的瓶颈。

下面介绍业界较为流行的一些主键生成策略。

1.UUID模式

通用唯一识别码（Universally Unique Identifier），根据标准方法生成，不依赖中央机构的注册和分配，UUID具有唯一性重复UUID码概率接近零，可以忽略不计。UUID具有多个版本：基于时间的UUID、DCE安全的UUID、基于名字的UUID（MD5）(UUID.nameUUIDFromBytes())、随机UUID(UUID.randomUUID().toString())、基于名字的UUID（SHA1）,Version 1/2适合应用于分布式计算环境下，具有高度的唯一性；Version 3/5适合于需要相同内容生成相同UUID的业务场景下；Version 4建议不要使用(随机数有可能出现重复，但是重复的概率极低，在设计时需要考虑到这一点)。UUID虽然解决了依赖于数据库生成主键的策略，但是也存在一些不足：占用存储空间大；随机生成，不具有连续性，作为主键时性能较差；无法根据主键进行排序，确定记录插入的先后顺序；对于开发人员不友好；如果生成过程中使用了机器MAC地址，存在一定安全隐患。

2.步长模式

即Flickr的sharding主键生成方案。使用多台数据库服务器，通过设置不同的起始值、一致自增步长，让每个数据库中各表主键保持唯一。如图所示：

步长方式在一定程度上解决了高并发的问题，但是也存在一些问题如：扩展困难，设置好步长后，再进行扩展将会比较困难；ID并不是按顺序严格单调递增的特性，只是趋势递增；每次获取ID仍然需要读写一次数据库，仍然存在瓶颈。

3.号段模式

即每次从数据库获取id时，从数据库取到当前id最大值，然后返回max+step，当应用程序用完这个号段后，再从数据库获取下一个长度为step的号段。为此需要专门设计一张用以记录id的表，在应用服务为集群，而主键服务器为单点时，多个应用服务节点同时获取id时，会产生冲突，可以增加version字段从而使用乐观锁进行并发访问控制。

id表主键(id)业务类型（id_type）当前最大id (max_id)号段长度(step)版本号（version）

号段模式将主键缓存在应用服务端，从而减少对数据库的访问频率；在数据库数据库不可用时，应用服务仍然可以持续运行一段时间直到当前号段用完；但是在应用服务重启时有可能丢失部分id，导致id增长不连续。

基于号段模式有一些成熟方案，且经过实践验证：美团的Leaf-segment对号段发放方式进行了双buffer缓存及高可用容灾优化。采用双buffer模式，在当前号段消费到某个点时就异步的把下一个号段加载到内存中。而不需要等到号段用尽的时候才去更新号段，不会在应用服务器向数据库请求id时，因为id号段没有取回来，导致线程阻塞。

滴滴的TinyId参照了美团Leaf的实现方式，并对其做了扩展，增加了多db支持和tinyid-client。

4.snowflake模式(雪花算法)

Twitter实现的分布式ID生成算法。结构如下：0-00000000000000000000000000000000000000000-00000-00000-000000000000

• 1 bit：保留位，为符号位，全部为0，表示生成的id都是正数。
• 41bit：时间戳，单位为毫秒，41位可以表示69年的时间。
• 10bit：机器id，10bit里面5位代表机房id，5位代表机器id，可以表示32个机房，每个机房里面可以用32台机器。
• 12bit：12位序列号，按顺序递增，记录每个节点1毫秒内产生的id，每毫秒可以产生4096个id。

snowflake的优点：

1. 主键在单个节点上是按序列递增的，能够按照时间趋势进行递增。
2. 主键的生成不依赖于数据库，可以由应用程序生成。
3. 在分布式集群内不会产生重复id。
4. 可以根据业务需求对bit位进行调整。

snowflake的缺点：

1. 对于时间依赖较高，如果时间回拨，则会产生主键重复情况。
2. 当集群规模较大时，workid配置会增加一定成本。

美团的Leaf-snowflake，使用zk解决了snowflake依赖于时钟，时间回拨产生重复主键问题；百度的UidGenerator，支持自定义时间戳、workerId、序列号等。

5.Redis模式

利用Redis原子操作INCR和INCRBY来实现，使用Redis集群提高并发量，与步长模式类似，只不过将id生成器由传统数据库换成效率更高的Redis数据库。但是当Redis重启或者宕机，记录主键值会丢失，所以利用Redis进行主键生成时需要对当前主键值进行持久化。Redis支持RDB和AOF两种持久化机制。RDB模式下，可能会丢失部分未打镜像的数据，根据快照恢复后会产生部分重复ID，故RDB不适合实施持久化Redis数据场景。AOF以独立日志记录每次写命令，重启时执行日志中的命令进行数据恢复，不会出现ID重复现象，但是会由于备份命令过多，导致Redis恢复数据时间较长。

以上介绍了五种数据库主键的生成策略，大家可以根据具体业务场景和系统实际情况选择一款最适合自己的主键策略，提升数据库性能，保证在高并发情况下系统运行稳定性。