分布式唯一ID服务架构

一、背景介绍

在大型互联网应用中，随着用户数的增加；为了提高应用的性能，我们经常需要对数据库进行分库分表操作。在单表时代我们可以完全依赖于数据库的自增ID来唯一标识一个条数据。但是当我们对数据库进行了分库分表之后，就不能依赖于每个表的自增ID来全局唯一标识这些数据了。因为自增的ID不能在分库分表的场景下准确的路由到正确的数据。
因此我们需要提供一个全局唯一的ID生成策略来支持分库分表的应用环境；
这个系统必须满足以下需求：
· 全局唯一： 不能出现重复的ID；
· 高可用： ID生成系统属于基础服务，同时被许多关键系统调用，一旦宕机，会造成严重影响；

二、经典方案介绍

1. UUID
UUID是Universally Unique Identifier的缩写，它是在一定范围内（从特定的名字空间到全球）唯一的机器生成的标识符，UUID是16字节128位长的数字，通常以36字节的字符串表示；比如：
UUID经由一定的算法机器生成，为了保证UUID的唯一性，规范定义了包括网卡MAC地址、时间戳、名字空间(Namespace)、随机或伪随机数、时序等元素，以及从这些元素生成UUID的算法。UUID的复杂特性在保证了其唯一性的同时，意味着只能由计算机生成。
优点：本地生成ID，不需要远程调用、低延时、性能高；
缺点：UUID过长，16字节128位，很多场景不适用；比如用UUID做数据库的索引时，插入数据时数据量越大，插入性能越低；
UUID不是有序的，无法保证趋势递增；
2. Flicker方案
该方案主要的思路是采用了MySQL自增长的ID的机制（auto_increment + replace into）

--- 数据表CREATE TABLE Tickets64 (
  id     bigint(