分布式 ID 生成器
一个唯一 ID 在一个分布式系统中是非常重要的一个业务属性，其中包括一些如订单 ID，消息 ID ，会话 ID，他们都有一些共有的特性：
- 全局唯一。
- 趋势递增。
全局唯一很好理解，目的就是唯一标识某个次请求，某个业务。
通常有以下几种方案：
基于数据库
可以利用 MySQL 中的自增属性 auto_increment 来生成全局唯一 ID，也能保证趋势递增。 但这种方式太依赖 DB，如果数据库挂了那就非常容易出问题。
水平扩展改进
但也有改进空间，可以将数据库水平拆分，如果拆为了两个库 A 库和 B 库。 A 库的递增方式可以是 0 ,2 ,4 ,6。B 库则是 1 ,3 ,5 ,7。这样的方式可以提高系统可用性，并且 ID 也是趋势递增的。
但也有如下一下问题：
- 想要扩容增加性能变的困难，之前已经定义好了 A B 库递增的步数，新加的数据库不好加入进来，水平扩展困难。
- 也是强依赖与数据库，并且如果其中一台挂掉了那就不是绝对递增了。
本地 UUID 生成
还可以采用 UUID 的方式生成唯一 ID，由于是在本地生成没有了网络之类的消耗，所有效率非常高。
但也有以下几个问题：
- 生成的 ID 是无序性的，不能做到趋势递增。
- 由于是字符串并且不是递增，所以不太适合用作主键。
采用本地时间
这种做法非常简单，可以利用本地的毫秒数加上一些业务 ID 来生成唯一ID，这样可以做到趋势递增，并且是在本地生成效率也很高。
但有一个致命的缺点:当并发量足够高的时候唯一性就不能保证了。
Twitter 雪花算法
可以基于 Twitter 的 Snowflake 算法来实现。它主要是一种划分命名空间的算法，将生成的 ID 按照机器、时间等来进行标志。
首先一个Twitter算法生成的id为一个long长度，8字节64位
Snowflake的结构S如下(每部分用-分开):
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000
第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）
一共加起来刚好64位，为一个Long型。(转换成字符串后长度最多19)
这里还需要解释一下，41位毫秒级时间不是当前毫秒时间而是现在与开始的差，这个id生成器开始运行时会产生一个毫秒时间这个保存下来，然后每生成一个id号，会把当前时间的毫秒值和这个之前保存的相减。即是这个41位的值
10位的数据机器码值，区分分布式环境下不同机器和不同业务数据所用没啥太多解释
最后12位，代表是在41位毫秒值相同情况下，进行排序，即一毫秒可以产生4096个序列号
snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。经测试snowflake每秒能够产生26万个ID。