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

标签: mysql 环境 id | 发表时间:2015-06-14 21:24 | 作者:dk05408
出处:http://www.iteye.com

在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作。在单表时代,我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象。但是当我们对数据库进行了分库分表后,就不能依赖于每个表的自增ID来全局唯一标识这些数据了。因此,我们需要提供一个全局唯一的ID号生成策略来支持分库分表的环境。下面来介绍两种非常优秀的解决方案:

1. 数据库自增ID——来自Flicker的解决方案

因为MySQL本身支持auto_increment操作,很自然地,我们会想到借助这个特性来实现这个功能。Flicker在解决全局ID生成方案里就采用了MySQL自增长ID的机制(auto_increment + replace into + MyISAM)。一个生成64位ID方案具体就是这样的: 
先创建单独的数据库(eg:ticket),然后创建一个表:

    CREATE TABLE Tickets64 (
            id bigint(20) unsigned NOT NULL auto_increment,
            stub char(1) NOT NULL default '',
            PRIMARY KEY  (id),
            UNIQUE KEY stub (stub)
    ) ENGINE=MyISAM

当我们插入记录后,执行 SELECT * from Tickets64,查询结果就是这样的:

    +-------------------+------+
| id                | stub |
+-------------------+------+
| 72157623227190423 |    a |
+-------------------+------+

在我们的应用端需要做下面这两个操作,在一个事务会话里提交:

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

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

    TicketServer1:
auto-increment-increment = 2
auto-increment-offset = 1

TicketServer2:
auto-increment-increment = 2
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部分组成:

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

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

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

from:http://my.oschina.net/u/142836/blog/174465



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [mysql 环境 id] 推荐:

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

- - 数据库 - ITeye博客
数据库自增ID——来自Flicker的解决方案. 独立的应用程序——来自Twitter的解决方案. 在大型互联网应用中,随着用户数的增加,为了提高应用的性能,我们经常需要对数据库进行分库分表操作. 在单表时代,我们可以完全依赖于数据库的自增ID来唯一标识一个用户或数据对象. 但是当我们对数据库进行了分库分表后,就不能依赖于每个表的自增ID来全局唯一标识这些数据了.

查找原始的MySQL数据库死锁ID

- - searchdatabase
  如果遇到死锁了,怎么解决呢?找到原始的锁ID,然后KILL掉一直持有的那个线程就可以了, 但是众多线程,可怎么找到引起死锁的线程ID呢. MySQL 发展到现在,已经非常强大了,这个问题很好解决.   线程A,我们用来锁定某些记录,假设这个线程一直没提交,或者忘掉提交了. 那么就一直存在,但是数据里面显示的只是SLEEP状态.

[MySQL] 生产环境MySQL数据库事务一直在RUNNING

- - CSDN博客数据库推荐文章
运营人员反映,有一单子提交卡住了,页面一直没有返回. 1,刚开始怀疑是应用服务器或者db压力过高hang住了,马上去check应用服务器以及db的负载,看起来都OK,蛮低的,应该不是DB性能问题. 2,最后去看下是否是表锁住了,查看到有2个事务一直RUNNING,没有结束. 3,通过trx_mysql_thread_id: 1662332的去查询information_schema.processlist找到执行事务的客户端请求的SQL线程.

产生Id

- - 研发管理 - ITeye博客
// worker编号最大值,决定支持的部署节点数量. // 毫秒内自增位数,每毫秒最大序号支持65535. // worker编号偏移量. // 毫秒基线:2015-01-01 00:00:00. * 从环境变量中获取worker编号,每个部署环境编号不能重复. * 每个部署环境编号不能重复. * @param workerId Worker编号.

PHP+MySQL环境下SQL Injection攻防总结

- rokeyhu - 老王的技术手册 ( 我的新博客:http://huoding.com )
程序员们写代码的时候讲究TDD(测试驱动开发):在实现一个功能前,会先写一个测试用例,然后再编写代码使之运行通过. 其实当黑客SQL Injection时,同样是一个TDD的过程:他们会先尝试着让程序报错,然后一点一点的修正参数内容,当程序再次运行成功之时,注入也就随之成功了. 假设你的程序里有类似下面内容的脚本:.

MySQL生产环境突发故障处理手册

- gOODiDEA - MySQL OPS
1.2 碎片整理和统计信息更新 OPTIMIZE 操作等于recreate + analyze 的组合操作,所以会堵塞更新类型SQL语句. 对于备机上跑只读类型操作的业务,可以考虑使用此操作命令,对于主服务器不建议使用此命令,为此备机上执行OPTIMIZE 语句,必须这样写: [...].

生产环境 MySQL 表的维护:check、optimize和analyze

- - CSDN博客数据库推荐文章
        optimize可以回收空间、减少碎片、提高I/O.         目前支持的存储引擎有:InnoDB、MyASIM和ARCHIVE.         如果是Replication环境、可加NO_WRITE_TO_BINLOG(或者LOCAL、意思完全相同)、比如:.         以下是一个简单测试:.

项目进阶 之 集群环境搭建(二)MySQL集群

- - CSDN博客推荐文章
        上次的博文中我们介绍了一下集群的相关概念,今天的博文我们介绍一下MySQL集群的相关内容.         MySQL群集技术在分布式系统中为MySQL数据提供了冗余特性,增强了安全性,使得单个MySQL服务器故障不会对系统产生巨大的负面效应,系统的稳定性得到保障.         MySQL群集需要有一组计算机,每台计算机的角色可能是不一样的.

[MySQL FAQ]系列 — 线上环境到底要不要开启query cache

- - MySQL中文网
Query Cache(查询缓存,以下简称QC)存储SELECT语句及其产生的数据结果,特别适用于:频繁提交同一个语句,并且该表数据变化不是很频繁的场景,例如一些静态页面,或者页面中的某块不经常发生变化的信息. InnoDB Buffer Pool或者. MyISAM key buffer里读取结果.

linux、mysql、nginx、tomcat 环境下压力测试的主要调试参数

- - SegmentFault 最新的文章
一、linux 系统内核参数. /etc/sysctl.conf文件常用参数. net.core.netdev_max_backlog = 32768 #允许送到队列的数据包的最大数目 net.core.rmem_max = 8388608. #SOCKET读缓存区大小 net.core.wmem_max = 8388608.