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

忘是亡心i 2022-08-26 15:23 168阅读 0赞

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

介绍来自flicker和twitter的两种解决分布式环境下全局ID生成方案。

目录\[-\]

*  [1. 数据库自增ID——来自Flicker的解决方案][1. _ID_Flicker]
 *  [2. 独立的应用程序——来自Twitter的解决方案][2. _Twitter]

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

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

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

[view source][]

[print][] [?][Link 2]

<table> 
 <tbody> 
  <tr> 
   <td><code>1</code></td> 
   <td><code>CREATE TABLE Tickets64 (</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>2</code></td> 
   <td><code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>id bigint(</code><code>20</code><code>) unsigned NOT NULL auto_increment,</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>3</code></td> 
   <td><code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>stub</code><code>char</code><code>(</code><code>1</code><code>) NOT NULL</code><code>default</code> <code>''</code><code>,</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>4</code></td> 
   <td><code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>PRIMARY KEY&nbsp; (id),</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>5</code></td> 
   <td><code>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</code><code>UNIQUE KEY stub (stub)</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>6</code></td> 
   <td><code>&nbsp;&nbsp;&nbsp;&nbsp;</code><code>) ENGINE=MyISAM</code></td> 
  </tr> 
 </tbody> 
</table>

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

[view source][]

[print][] [?][Link 2]

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

[view source][]

[print][] [?][Link 2]

<table> 
 <tbody> 
  <tr> 
   <td><code>1</code></td> 
   <td><code>REPLACE INTO Tickets64 (stub) VALUES (</code><code>'a'</code><code>);</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>2</code></td> 
   <td><code>SELECT LAST_INSERT_ID();</code></td> 
  </tr> 
 </tbody> 
</table>

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

[view source][]

[print][] [?][Link 2]

<table> 
 <tbody> 
  <tr> 
   <td><code>1</code></td> 
   <td><code>TicketServer1:</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>2</code></td> 
   <td><code>auto-increment-increment = </code><code>2</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>3</code></td> 
   <td><code>auto-increment-offset = </code><code>1</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>5</code></td> 
   <td><code>TicketServer2:</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>6</code></td> 
   <td><code>auto-increment-increment = </code><code>2</code></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code>7</code></td> 
   <td><code>auto-increment-offset = </code><code>2</code></td> 
  </tr> 
 </tbody> 
</table>

最后，在客户端只需要通过轮询方式取ID就可以了。

*  优点：充分借助数据库的自增ID机制，提供高可靠性，生成的ID有序。
 *  缺点：占用两个独立的MySQL实例，有些浪费资源，成本较高。

参考：[http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/][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][https_github.com_twitter_snowflake]。根据twitter的业务需求，snowflake系统生成64位的ID。由3部分组成：

[view source][]

[print][] [?][Link 2]

<table> 
 <tbody> 
  <tr> 
   <td><code><span style="color:#ff0000">1</span></code></td> 
   <td><span style="color:#ff0000"><code>41</code><code>位的时间序列（精确到毫秒，</code><code>41</code><code>位的长度可以使用</code><code>69</code><code>年）</code></span></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code><span style="color:#ff0000">2</span></code></td> 
   <td><span style="color:#ff0000"><code>10</code><code>位的机器标识（</code><code>10</code><code>位的长度最多支持部署</code><code>1024</code><code>个节点）</code></span></td> 
  </tr> 
 </tbody> 
</table>

<table> 
 <tbody> 
  <tr> 
   <td><code><span style="color:#ff0000">3</span></code></td> 
   <td><span style="color:#ff0000"><code>12</code><code>位的计数顺序号（</code><code>12</code><code>位的计数顺序号支持每个节点每毫秒产生</code><code>4096</code><code>个ID序号）</code></span></td> 
  </tr> 
 </tbody> 
</table>

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

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

推荐阅读：[MySQL使用优化与总结][MySQL]

[Link 1]: http://my.oschina.net/u/142836/blog/174465
[1. _ID_Flicker]: http://my.oschina.net/u/142836/blog/174465#OSC_h3_1
[2. _Twitter]: http://my.oschina.net/u/142836/blog/174465#OSC_h3_2
[view source]: http://my.oschina.net/u/142836/blog/174465#viewSource
[print]: http://my.oschina.net/u/142836/blog/174465#printSource
[Link 2]: http://my.oschina.net/u/142836/blog/174465#about
[http_code.flickr.net_2010_02_08_ticket-servers-distributed-unique-primary-keys-on-the-cheap]: http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
[https_github.com_twitter_snowflake]: https://github.com/twitter/snowflake
[MySQL]: http://my.oschina.net/u/142836/blog/169415