MySQL分库分表环境下全局ID生成方案

页面导航:首页 > 数据库 > Mysql > MySQL分库分表环境下全局ID生成方案

MySQL分库分表环境下全局ID生成方案

来源: 作者: 时间:2016-02-03 08:56 【

MySQL分库分表环境下全局ID生成方案在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作。在单表时代,我们可以完全依赖于数据库
MySQL分库分表环境下全局ID生成方案
 
在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对进行分库分表操作。在单表时代,我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象。但是当我们对数据库进行了分库分表后,就不能依赖于每个表的自增ID来全局唯一标识这些数据了。因此,我们需要提供一个全局唯一的ID号生成策略来支持分库分表的环境。下面来介绍两种非常优秀的解决方案:
 
1. 数据库自增ID——来自Flicker的解决方案
 
因为MySQL本身支持auto_increment操作,很自然地,我们会想到借助这个特性来实现这个功能。Flicker在解决全局ID生成方案里就采用了MySQL自增长ID的机制(auto_increment + replace into + MyISAM)。一个生成64位ID方案具体就是这样的:
先创建单独的数据库(eg:ticket),然后创建一个表:
1
CREATE TABLE Tickets64 (
2
            id bigint(20) unsigned NOT NULL auto_increment,
3
            stub char(1) NOT NULL default '',
4
            PRIMARY KEY  (id),
5
            UNIQUE KEY stub (stub)
6
    ) ENGINE=MyISAM
当我们插入记录后,执行SELECT * from Tickets64,查询结果就是这样的:

1
+-------------------+------+
2
| id                | stub |
3
+-------------------+------+
4
| 72157623227190423 |    a |
5
+-------------------+------+
在我们的应用端需要做下面这两个操作,在一个事务会话里提交:

1
REPLACE INTO Tickets64 (stub) VALUES ('a');
2
SELECT LAST_INSERT_ID();

 

这样我们就能拿到不断增长且不重复的ID了。
到上面为止,我们只是在单台数据库上生成ID,从高可用角度考虑,接下来就要解决单点故障问题:Flicker启用了两台数据库服务器来生成ID,通过区分auto_increment的起始值和步长来生成奇偶数的ID。
 
1
TicketServer1:
2
auto-increment-increment = 2
3
auto-increment-offset = 1
4

5
TicketServer2:
6
auto-increment-increment = 2
7
auto-increment-offset = 2

 

最后,在客户端只需要通过轮询方式取ID就可以了。
 
优点:充分借助数据库的自增ID机制,提供高可靠性,生成的ID有序。
缺点:占用两个独立的MySQL实例,有些浪费资源,成本较高。
 
2. 独立的应用程序——来自Twitter的解决方案
 
Twitter在把存储从MySQL迁移到Cassandra的过程中由于Cassandra没有顺序ID生成机制,于是自己开发了一套全局唯一ID生成服务:Snowflake。根据twitter的业务需求,snowflake系统生成64位的ID。由3部分组成:
 
1
41位的时间序列(精确到毫秒,41位的长度可以使用69年)
2
10位的机器标识(10位的长度最多支持部署1024个节点)
3
12位的计数顺序号(12位的计数顺序号支持每个节点每毫秒产生4096个ID序号)
优点:高性能,低延迟;独立的应用;按时间有序。
缺点:需要独立的开发和部署。
 
Tags:

文章评论

最 近 更 新
热 点 排 行
Js与CSS工具
代码转换工具

<