顺序全局id生成方案-flickr（转载）

全局ID的核心需求：

1、全局唯一

2、趋势递增（ID如果做为索引，有序非常重要）

3、单调递增（下一次调用的id一定要大于本次的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实例，有些浪费资源，成本较高。

参考：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。

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