发号器方案：雪花算法

发号器作用：生成业务内唯一的ID

业内常用方案：

1.基于UUID

2.数据库自增ID

3.数据库多主模式

4.号段模式获取

5.双Buffer号段获取

6.Redis

7.twitter的雪花算法

8.美团的Leaf

9.百度的UidGenerator

10.滴滴的TinyID

本文介绍雪花算法

什么是雪花算法

SnowFlake 算法，是 Twitter 开源的分布式 ID 生成算法。

其核心思想就是：使用一个 64 bit 的 long 型的数字作为全局唯一 ID。

在分布式系统中的应用十分广泛，且 ID 引入了时间戳，基本上保持自增

 

第一个部分是 1 个 bit：0；二进制里第一个 bit 为如果是 1，那么都是负数，但是我们生成的 id 都是正数，所以第一个 bit 统一都是 0。

第二个部分是 41 个 bit：表示的是时间戳，单位是毫秒，可支持69年的时间。

第三个部分是 5 个 bit：表示的是机房 id，可支持32个机房。

第四个部分是 5 个 bit：表示的是机器 id，可支持32台机器，也就算法支持1024台机器在同一毫秒内去使用。

第五个部分是 12 个 bit：表示的序号，就是某个机房某台机器上这一毫秒内同时生成的 id 的序号，可支持409.6w/s。

雪花算法的优点

1. 高性能高可用：生成时不依赖于数据库，完全在内存中生成。
2. 容量大：每秒中能生成数百万的自增ID。
3. ID自增：存入数据库中，索引效率高。

雪花算法的缺点

时钟回拨

雪花算法强依赖机器时钟，如果机器上时钟回拨，会导致发号重复或者服务会处于不可用状态。

如果恰巧回退前生成过一些ID，而时间回退后，生成的ID就有可能重复。

官方对于此并没有给出解决方案，而是简单的抛错处理，这样会造成在时间被追回之前的这段时间服务不可用。

解决方法1

如果机器的回拨时间比较短，如5ms的回拨，那可以等待一定时间，等机器的时间追上最后一次的时间

解决方法2

如回拨时间较长，则直接拒绝，抛出异常
 

机器ID的分配和回收问题

目前机器id需要每台机器不一样，这样的方式分配需要有方案进行处理，同时也要考虑，如果改机器宕机了，对应的workerId分配后的回收问题

机器ID的上限问题

上文讲到雪花支持的机器个数是有上限的，在某些需要大量的业务机器共享的场景，那么10bit表示的1024台机器是不够的。

雪花算法缺点解决方案---Butterfly

Butterfly（蝴蝶）是一个超高性能的发号器框架。

框架通过引入多种新的方案不仅解决了雪花算法存在的所有问题，而且还能够提供比雪花算法更高的性能

大致是通过调整不同bit的作用，具体可查看

[Butterfly]  https://github.com/SimonAlong/Butterfly