1、为什么要实现发号器
很多地方我们都需要一个全局唯一的编号，也就是uuid。举一个常见的场景，电商系统产生订单的时候，需要有一个对应的订单编号。在composer上我们也可以看到有很多可以产生uuid的优秀组件。那么，为什么我们还要自己实现发号器，来产生uuid呢？想了一下，主要有两个原因吧：
1、我希望uuid是可反解的，通过反解uuid可以得出和我业务相关的数据。而我看到的composer关于uuid的相关组件，生成的都是一串指定格式的字符串，我很难将它同具体的业务关联起来。
2、我希望通过uuid是可以随着并放量进行调整的。比如说原有支持1秒钟可以产生1000个uuid，但随着业务规模增长，我希望变成可以支持1秒钟产生一万个。而且，最好改下配置就可以了。
出于以上两个原因，我们需要自己的发号器来产生uuid。那么，下一个问题是，我们应该如何实现发号器，实现发号器的原理又是什么呢？
2、snowFlake算法
关于发号器的实现原理，可能大家都听过鼎鼎大名的snowflake算法 -- 雪花算法，Twitter的分布式自增Id算法。国内的新浪微博也有自己实现的发号器算法，具体实现细节虽有不同，但是原理相通，明白其中一个即可。这里我们主要介绍snowflake。
关于snowflaw的介绍，已经有很多文章进行介绍，而且写的也很不错，我没有必要在重写一遍，拿来粘贴即可，出于对作者的尊重，我会将原文链接添加到参考链接中。
推特的分布式自增ID算法，使用long （8 × 8 = 64 byte）来保存uuid。其中1bit留给固定符号位0，41bit留给毫秒时间戳，10bit给MachineID，也就是机器要预先配置，剩下12位留Sequence（可支持1毫秒内4096个请求）。
也许有的人会问如果超过了1毫秒4096个请求怎么办？一般的做法是，让它等上1毫秒，促使41bit的时间戳变化。
这里我们将MachineId进行了拆分，5byte留给机器（最多可以支持32机器），5byte留给了业务号（最多可支持32种业务）
这里的时间戳保存的是当前时间与固定过去时间得一个差值，不是当前时间。这样的好处是能使用更长时间，而且不受年份限制，只取决于从什么时候开始用的，2^41 / 1000360024*365=69年。
如果保存的是当前时间戳，最多只能使用到2039年。2^41=2199023255552=2039/9/7 23:47:35
理论上单机速度：2^12*1000 = 4 096 000/s
3、如何保证在单位时间内持续递增
通过对snowflake的初步了解，发现，其实发号器也是建立在时间戳基础之上的，因为时间是天然的唯一元素。但是，如何在单位时间内，比如说一秒钟或者一毫秒之内，保证Sequence持续递增才是发号器实现的关键。
这里我们实现的方式比较简单，直接使用redis的incr进行计数，对应的key就是毫秒时间戳。出于redis内存回收的考虑，我们需要将每一个key设置过期时间。如果key是秒级别的时间戳，那么过期时间就是1秒 + 网络延迟；如果key毫秒级别的时间戳，那么过期时间就是1毫秒 + 网络延迟。
与此同时，为了保证执行incr，expire（pexpire）具有原子性，我们使用lua来进行实现。
好了，实现的思路大致如此。由于能力和水平有限，难免会有纰漏，希望及时指出。