主键生成策略

 
       应用开发中,我们经常需要涉及到数据主键的生成。大部分情况,我们会采用数据库主键自增,比如学生表,让学生表里的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取。
 
 
 
 
posted @ 2016-06-23 21:41  li.zhiliang  阅读(3712)  评论(0编辑  收藏  举报