bitscn.com
mysql分库分表环境下全局id生成方案
在大型互联网应用中，随着用户数的增加，为了提高应用的性能，我们经常需要对数据库进行分库分表操作。在单表时代，我们可以完全依赖于数据库的自增id来唯一标识一个用户或数据对象。但是当我们对数据库进行了分库分表后，就不能依赖于每个表的自增id来全局唯一标识这些数据了。因此，我们需要提供一个全局唯一的id号生成策略来支持分库分表的环境。下面来介绍两种非常优秀的解决方案：
1. 数据库自增id——来自flicker的解决方案
因为mysql本身支持auto_increment操作，很自然地，我们会想到借助这个特性来实现这个功能。flicker在解决全局id生成方案里就采用了mysql自增长id的机制（auto_increment + replace into + myisam）。一个生成64位id方案具体就是这样的：
先创建单独的数据库(eg:ticket)，然后创建一个表：
1create 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+-------------------+------+在我们的应用端需要做下面这两个操作，在一个事务会话里提交：1replace into tickets64 (stub) values ('a');2select last_insert_id();
这样我们就能拿到不断增长且不重复的id了。
到上面为止，我们只是在单台数据库上生成id，从高可用角度考虑，接下来就要解决单点故障问题：flicker启用了两台数据库服务器来生成id，通过区分auto_increment的起始值和步长来生成奇偶数的id。
1ticketserver1:2auto-increment-increment = 23auto-increment-offset = 145ticketserver2:6auto-increment-increment = 27auto-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序号）
优点：高性能，低延迟；独立的应用；按时间有序。
缺点：需要独立的开发和部署。
bitscn.com