Java分布式ID-主键自增ID

可以明确的结论：主键自增ID，对于单库单表绝对适合； 单库分表和多库单表和多库多表也有解决方案，但是比较麻烦；所以不推荐分布式id使用这种方式。

1、看下面建立订单表的语句，其中主键采用自增ID。

CREATE TABLE `order` (
	`id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增ID',
	`order_code` VARCHAR(10) NOT NULL DEFAULT '' COMMENT '订单编码',
	`order_name` VARCHAR(10) NOT NULL DEFAULT '' COMMENT '订单名称',
	 PRIMARY KEY (`id`) USING BTREE
)
COMMENT='订单表';

CREATE TABLE `order` ( `id` INT(11) UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '自增ID', `order_code` VARCHAR(10) NOT NULL DEFAULT '' COMMENT '订单编码', `order_name` VARCHAR(10) NOT NULL DEFAULT '' COMMENT '订单名称', PRIMARY KEY (`id`) USING BTREE ) COMMENT='订单表';

可以这样说，对于我们来做的绝大部分系统都达不到需要分库分表的程度，基本上用的都是单表。那么我可以笃定的对你说，使用主键自增的方案非常好。因为这对于mysql数据，无论从存储还是从B+树索引结果来说都很友好。

2、数据库分表使用ID

如果我们的系统并发量并没有那么大，但是后台设计到的数据特别多。单表存起来致使查询比较慢。那么我们需要对数据库进行分表操作。此时，可能会多个订单表，例如：分别是 order1，order2表。那么此时如果设置主键为自动增涨，很明显数据库主键id会出现重复的情况。那么如何解决？

2.1 设置增涨步长

首先预估会分3个表，然后对于每个表设置主键ID的初始值和设置步长为表的个数。（设置步长使用命令 AUTO_INCREMENT = N，可以设置整体数据库的整体步长，也可以设置单表的步长）

例如：order1 初始id：1 步长：2 。orderId的主键为 1，3，5，7，9。

order2 初始id：2 步长：2。orderId的主键为 2，4，6，8，10。

2.2 设置一个主键表（order_primary_key）

主键表专门存储主键。每次插入order1和order2表的时候都先从主键表（order_primary_key）获取主键id。生成主键可以使用数据库LAST_INSERT_ID()方法。

创建表：CREATE TABLE order_primary_key(id INT NOT NULL);

插入数据：INSERT INTO sequence VALUES (0);

产生序列：UPDATE sequence SET id=LAST_INSERT_ID(id+1);

局限性：必须是在同一个数据库中，也即是同一个链接。Java中对应得为同一个connection。

3、数据库分库使用ID

3.1如果我们数据库的访问量特别大，并发量高。那么恭喜你做的系统很牛叉了。此时单库满足不了，分表也不能满足你的用户并发量操作（单库数据库连接会成为并发的瓶颈，此时可以进行分库，也可以实现读写分离，咱们这讨论分库的情况），那么此时你需要进行分库。通过增加数据库的链接数来分担流量。那么针对此种情况，如何保证id唯一？其实答案很简单。采用2.1的设置步长增涨就可以。

3.2 特别注意：方法2.2是不能满足的。因为现在对应的是多个库，多个数据库链接（Connection）

3.3 有很多同学估计想问，那么分库分表组合到一起怎么保证主键id唯一，其实2.1也能满足你。只不过初始化每个库中每个表的起始值和步长不同。

4、号段模式

针对2.2其实应用并发量比较大的情况，如果多台服务器都是用的同一个库调用的主键(order_primary_key）表生成的id生成。那么每次调用一次生成一个主键id可能会成为瓶颈。此时我们可以一次获取1000个存储到redis中，然后服务调用一直消耗，直到消耗完毕，再次取1000个存放到redis中，这样能减少查询数据库的开销。

表的设计：

id	max_id(当前最大id)	step(步长1000)	version（版本号）
1	0	1000	0

使用方法： update set max_id = max_id+step,version = version +1 where id =1 and version = 0

version是乐观锁机制：是因为可能多台服务器同时操作，采用乐观锁，看那台服务能获取成功。这种方式不会频繁访问数据库，对数据库压力小。但是同样缺点很多，比如redis缓存失效。服务器重启都会造成id生成不连续。