在单库单表的场景下，我们可以使用数据库的自增字段作为ID，因为这样最简单，对于开发人员来说也是透明的。但是当数据库分库分表后，使用自增字段就无法保证ID的全局唯一性了。
先说一下UUID，UUID（Universally Unique Identifier，通用唯一标识码）不依赖于任何第三方系统，所以在性能和可用性上都比较好，一般会使用它生成Request ID来标记单次请求，但是如果用它来作为数据库主键，它会存在以下几点问题。
- 首先，生成的ID做好具有单调递增性，也就是有序的，而UUID不具备这个特点。在业务表设计中可能存在多余的空间浪费，比如一对多的顺序查找。
- 另外Mysql的Innodb引擎是B+tree，存储结构是有序的，如果新增一条ID数据，那么会自动往后增加，并且ID是有序的。假如使用UUID，虽然只保证了唯一性，但是可能会出现数据移动的开销来保证数据存储的有序性。
- 最后，UUID是由32个16进制数字组成的字符串，如果作为数据库主键使用比较耗费空间。
基于Snowflake算法搭建发号器
Snowflake的核心思想是将64bit的二进制数字分成若干部分，每一部分都存储有特定含义的数据，比如说时间戳、机器ID、序列号等等，最终生成全局唯一的有序ID。它的标准算法是这样的：
从上面这张图中我们可以看到，41位的时间戳大概可以支撑pow(2,41)/1000/60/60/24/365年，约等于69年，对于一个系统是足够了。
如果你的系统部署在多个机房，那么10位的机器ID可以继续划分为2～3位的IDC标示（可以支撑4个或者8个IDC机房）和7～8位的机器ID（支持128-256台机器）；12位的序列号代表着每个节点每毫秒最多可以生成4096的ID。
不同公司也会依据自身业务的特点对Snowflake算法做一些改造，比如说减少序列号的位数增加机器ID的位数以支持单IDC更多的机器，也可以在其中加入业务ID字段来区分不同的业务。比方说我现在使用的发号器的组成规则就是：1位兼容位恒为0 + 41位时间信息 + 6位IDC信息（支持64个IDC）+ 6位业务信息（支持64个业务）+ 10位自增信息（每毫秒支持1024个号）
我选择这个组成规则，主要是因为我在单机房只部署一个发号器的节点，并且使用KeepAlive保证可用性。业务信息指的是项目中哪个业务模块使用，比如用户模块生成的ID，内容模块生成的ID，把它加入进来，一是希望不同业务发出来的ID可以不同，二是因为在出现问题时可以反解ID，知道是哪一个业务发出来的ID。
那么了解了Snowflake算法的原理之后，我们如何把它工程化，来为业务生成全局唯一的ID呢？一般来说我们会有两种算法的实现方式：
一种是嵌入到业务代码里，也就是分布在业务服务器中。这种方案的好处是业务代码在使用的时候不需要跨网络调用，性能上会好一些，但是就需要更多的机器ID位数来支持更多的业务服务器。另外，由于业务服务器的数量很多，我们很难保证机器ID的唯一性，所以就需要引入ZooKeeper等分布式一致性组件来保证每次机器重启时都能获得唯一的机器ID。
另外一个部署方式是作为独立的服务部署，这也就是我们常说的发号器服务。业务在使用发号器的时候就需要多一次的网络调用，但是内网的调用对于性能的损耗有限，却可以减少机器ID的位数，如果发号器以主备方式部署，同时运行的只有一个发号器，那么机器ID可以省略，这样可以留更多的位数给最后的自增信息位。即使需要机器ID，因为发号器部署实例数有限，那么就可以把机器ID写在发号器的配置文件里，这样即可以保证机器ID唯一性，也无需引入第三方组件了。微博和美图都是使用独立服务的方式来部署发号器的，性能上单实例单CPU可以达到两万每秒。
Snowflake算法设计的非常简单且巧妙，性能上也足够高效，同时也能够生成具有全局唯一性、单调递增性和有业务含义的ID，但是它也有一些缺点，其中最大的缺点就是它依赖于系统的时间戳，一旦系统时间不准，就有可能生成重复的ID。所以如果我们发现系统时钟不准，就可以让发号器暂时拒绝发号，直到时钟准确为止。
另外，如果请求发号器的QPS不高，比如说发号器每毫秒只发一个ID，就会造成生成ID的末位永远是1，那么在分库分表时如果使用ID作为分区键就会造成库表分配的不均匀。这一点，也是我在实际项目中踩过的坑，而解决办法主要有两个：
1.时间戳不记录毫秒而是记录秒，这样在一个时间区间里可以多发出几个号，避免出现分库分表时数据分配不均。
2.生成的序列号的起始号可以做一下随机，这一秒是21，下一秒是30，这样就会尽量的均衡了。