主键生成策略
应用开发中,我们经常需要涉及到数据主键的生成。大部分情况,我们会采用数据库主键自增,比如学生表,让学生表里的id自增。但是如果我们希望主键里保护日期信息呢?或者我们在库里实行了分表策略,表主键自增也是不行的。
有人会想到uuid,uuid能做到全局唯一的,能解决分表策略的问题,当时在主键里加入其他信息还是不行。还有个问题uuid字符串比较长,存储费空间,不方便建索引。
我之前采用的一个策略是建立一个专门的主键表,里面包含两个字段(id, tablename) .
sql如下:
CREATE TABLE `id_temp` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `table_name` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `table_name` (`table_name`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
生成id:
REPLACE INTO id_temp (table_name) value("tablename") ; SELECT LAST_INSERT_ID() ;
如果我们业务表不介意id的连续性,可以多个业务表使用一个主键表。如果业务表要求id的连续性,那一个业务表得使用一个主键表。
如果需要主键中加入日期元素,需要使用当前日期加上上面方式生成的id就成了。
但是,当业务并发很大,这种生成速度已经满足不了需求时,怎么办呢?
以前支付宝红包刚出来的时候,记得发红包的人,生成红包后,会产生一个数字,其他人通过这个数字抢红包。假设某个关键时间点,大量用户在那个时间点生成红包,那这些数字怎么生成呢(这些数字必须得有唯一性)。
记得之前在一篇博客介绍过一个方案,地址忘记了,介绍的是Fickr使用的一种主键生成方案。他的方案和上面的类似,不过是一个分布式版。
选择N个数据库服务器,每台数据库建一个主键表,也是两个字段(id, tablename)。
不同的是,第一台数据库的建表语句是:
CREATE TABLE `id_temp` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `table_name` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `table_name` (`table_name`) ) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;
第m台建表语句是:
CREATE TABLE `id_temp` ( `id` int(11) unsigned NOT NULL AUTO_INCREMENT, `table_name` varchar(20) DEFAULT NULL, PRIMARY KEY (`id`), UNIQUE KEY `table_name` (`table_name`) ) ENGINE=InnoDB AUTO_INCREMENT=m DEFAULT CHARSET=utf8;
m是 1 到 N中间的一个数字,每台数据库主键的初始值不同,从1到N。
然后,每台数据库设置他们的 auto_increment_increment值,
set @@session.auto_increment_increment=N ;
大概意思我们应该明白了,1到N台服务器,每台服务器的自增初始值不同,分别从1到N,然后每次自增的长度是N。 应用服务器分布式调用到不同的数据库后,都能保证id的唯一性,和单台数据库的效果是一样的,而且使用上数据库集群,解决了高并发的问题。
这里在引申一下,假如需要添加服务器,或者下线服务器,怎么办呢?
方案一:
我们可以假设在这个上线、下线数据库改动期间,id能自增到的最大值M(通过平时的统计,可以有更多的富余),取一个稍微大于M的一个值,记作K。然后每台数据库,重新设置他的 auto_increment_increment和auto_increment_offset值。第一台auto_increment_offset值设为K,第二台设为K+1,依次第m台设为K+m;每台的auto_increment_increment值设置为新的服务器数。
方案二:
先生成足够的id在缓存中,后面的请求不走db,全部从缓存取。然后修改每台数据库的auto_increment_increment和auto_increment_offset值,参数修改完后,在恢复从db取。
松下问童子,言师采药去。
只言此山中,云深不知处。