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

转载 2014年04月20日 10:00:06

点击打开链接http://my.oschina.net/u/142836/blog/174465

介绍来自flicker和twitter的两种解决分布式环境下全局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             stubchar(1) NOT NULLdefault '',
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实例,有些浪费资源,成本较高。

参考:http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/

2. 独立的应用程序——来自Twitter的解决方案

Twitter在把存储系统从MySQL迁移到Cassandra的过程中由于Cassandra没有顺序ID生成机制,于是自己开发了一套全局唯一ID生成服务:Snowflake。GitHub地址:https://github.com/twitter/snowflake。根据twitter的业务需求,snowflake系统生成64位的ID。由3部分组成:

1 41位的时间序列(精确到毫秒,41位的长度可以使用69年)
2 10位的机器标识(10位的长度最多支持部署1024个节点)
3 12位的计数顺序号(12位的计数顺序号支持每个节点每毫秒产生4096个ID序号)

最高位是符号位,始终为0。

  • 优点:高性能,低延迟;独立的应用;按时间有序。
  • 缺点:需要独立的开发和部署。

推荐阅读:MySQL使用优化与总结

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

在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作。在单表时代,我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象。但是当我们对数据库进行了分库...

各种排序算法比较(1):稳定性

前面有讲到了9种排序算法: 1.简单选择排序 2.堆排序        (1和2是属于选择排序) 3.直接插入排序 4.希尔排序     (3和4属于插入排序,有时把改进后的直接插入排序叫...

Mysql数据库分库和分表方式(常用)

本文主要给大家介绍Mysql数据库分库和分表方式(常用),涉及到mysql数据库相关知识,对mysql数据库分库分表相关知识感兴趣的朋友一起学习吧 本文主要给大家介绍MySQL数据库...

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

MySQL分库分表环境下全局ID生成方案   在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作。在单表时代,我们可以完全依赖于数据库的自增ID来唯一标...

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

摘要 介绍来自flicker和twitter的两种解决分布式环境下全局ID生成方案。 在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作。在单表时代,我们...

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

MySQL分库分表环境下全局ID生成方案   在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作。在单表时代,我们可以完全依赖于数据库的自增ID来唯一标...
  • houkai6
  • houkai6
  • 2013年12月31日 11:53
  • 1071

每日学习20170224-分库分表全局ID生成

由于数据量以及IO效率的因素,很多项目对数据支持的数据库会采取分库分表的方式。使用了分库分表之后需要解决的一个问题就是主键的生成。多个表之间的主键就不能用数据库本身的自增主键来支持,因为不同表之间生成...

数据库分表后,并发环境下,生成全局id生成的几种方式

1.使用redis锁机制 在 Redis 里,所谓 SETNX,是「SET if Not eXists」的缩写,也就是只有不存在的时候才设置,可以利用它来实现锁的效果,不过很多人没有意识到 SETN...

数据库分库分表(一)常见分布式主键ID生成策略

主键生成策略   系统唯一ID是我们在设计一个系统的时候常常会遇见的问题,下面介绍一些常见的ID生成策略。 Sequence IDUUIDGUIDCOMBSnowflake   最开始的自增...

数据库分库分表(sharding)系列(二) 全局主键生成策略

本文将主要介绍一些常见的全局主键生成策略,然后重点介绍flickr使用的一种非常优秀的全局主键生成方案。关于分库分表(sharding)的拆分策略和实施细则,请参考该系列的前一篇文章:数据库分库分表(...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:MySQL分库分表环境下全局ID生成方案
举报原因:
原因补充:

(最多只允许输入30个字)