sharding-jdbc系列（三）：分布式主键

在我们进行开发工作时，数据库表主键自动生成是一个基本的需求，而且大多数数据库也提供了基本的解决方案，比如mysql的自增主键、Oracle的自增序列。但是我们进行了分库分表后，同一个逻辑表内的不同实际表之间的自增键由于无法互相感知而产生重复主键。

目前有许多第三方解决方案可以完美解决这个问题，如UUID等依靠特定算法自生成不重复键，或者通过引入主键生成服务等。为了方便用户使用、满足不同用户不同使用场景的需求， ShardingSphere不仅提供了内置的分布式主键生成器，例如UUID、SNOWFLAKE，还抽离出分布式主键生成器的接口，方便用户自行实现自定义的自增主键生成器。

下面介绍几种分布式id的生成策略:

1、UUID

UUID(Universally Unique Identifier)的标准型式包含32个16进制数字，以连字号分为五段，形式为8-4-4-4-12的36个字符，示例：cc8fd628-ef02-426d-a954-89294591024c

java中java.util包中直接提供了生成UUID的方法：

UUID.randomUUID().toString()

优点：

• 因为是本地生成的，所以没有网络消耗，性能非常高。

缺点：

• 太长了！是一个36长度的长字符串，不利于存储。
• 不太安全，UUID基于mac地址生成，会造成mac地址泄露。
• 不适用于作为主键，以mysql为例，mysql官方建议主键长度越短越好，而UUID则是36位，不建议适用；并且UUID因为其无序性，如果作为主键插入时会引起数据位置的频繁变动，严重影响性能。

2、数据库生成

以mysql为例，在设置主键时可以通过设置自动递增来保证ID自增。

优点：

• 实现简单，基于数据库功能实现，不需要编码，对开发成本小。
• ID有顺序递增，在某些业务场景下非常适用，适用于作为mysql的主键，也是mysql官方推荐的主键生成策略。

缺点：

• 对数据库依赖太高，当数据库异常时，整个系统不可用。
• 性能不高，主要性能限制为单台mysql的读写性能。

对于以上的缺点性能问题，可以有以下的方案来进行解决：

多部署几台机器ÿ