在做项目的时候经常会用id作为唯一标识。
但是当有这样一个需求出现的时候：工程分布式部署，要求抗住高并发。并且生成的id是根据时间自增的。解决这个问题有很多种方法，但是要选择一个性价比比较高的策略比较不容易，例如：
1.数据库自增id控制
小型的应用直接自增足以。稍微中型一点的可以做下分表，突破下数据库的瓶颈，那么稍微大型一点的用什么方法来突破性能的瓶颈那？
例如我们曾经一个业务用postgresql序列来产生自增id，1个月生成3000w个id，平均下来一秒10左右，高峰*5倍。还是很轻松的。
如果这种方法数据库有点吃不消、或者效率有点低，那么可以采用sql大步长+cache：意思就是一次在数据库中取100个id，缓存在cache中，生成id的时候先判断cache中有无id，如果有则取出来用，如果没有去mysql取。当然虽然这种方法减少了mysql的访问次数和锁的次数，但是带来的就是程序中的并发问题。
2.当前时间的毫秒或者纳秒
毫秒这个也有点low了，稍微明白的工程师一眼就看出来了，很容易被破解。就算破解无所谓，对于高并发来说1ms也还是有可能生成多个id的。
纳秒倒是解决了高并发的问题，应该没有应用在一纳秒生成多个id的。但是如果完全依赖于纳秒，那么就等于完全失去了可控性，出了问题的话也不是很好办。
但是对于这样一个需求用纳秒还是能轻松解决问题的，不失为一个好的选择。
3.UUID
这个有点太长了，虽然能保证性能，但是串太长，不自增。
下面进入这个技术分享的主题：
4.通过约束条件生成唯一id
此方法也叫推特的雪花ID，大家可以网上查找雪花ID的实现代码，这里只阐述它的原理：
什么是通过约束条件生成唯一id，简单说就是在很极限的条件下生成很多id，足以满足需求，类似是唯一id。
比如在同一台机器上20ms内生成4000个id甚至更多，比如有10台机器，那么就是20ms生成40000个id，这样足以应对任何需求了，那么具体的做法是什么？
首先确定id存储用的是64位，那么一个64位的二进制是这样的：
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 1 0 0 1 1 0 0 1 1 1 0 0 0 0 0 1 0 1 1 1 1 1 0 0 1 1 1 1 1 0 1 1 1 1 1 0 1 0 0
看到这个就可以有很多事情可做了，约束条件生成id的方法就是切割这个64位，把某段的二进制表示成一个约束条件，可空性非常强，能抗住高并发，并且不易破解。
如上面的需求，如果要根据时间进行自增，那么就必须把当前的毫秒数放在高位了，比如前41位是当前时间。
41时间后面紧接9位是ip，ip之后的所有位数是自增数的二进制，记录着当前面位数相同的情况下这是第几个id。
所以如果现在有10台机器，那么这个id生成器生成id的极限是：同一台机器1ms内可以生成2的14次方个id。轻松满足需求。
最后切割成的效果可能是这样：
image
但是，这不是这个方法最大的好处，最大的好处是可以根据需求定制不同的约束条件，可以增加条件，继续分割这个64位数。
那么当条件比较多，64位不够分割的时候怎么办。有办法，进行移位操作，比如讲时间条件右移4位，那么1ms的约束条件就变成了16ms了，完全根据需求而定。
所以这个方法最大好处莫过于灵活，可控性强，根据需求可以轻易定制不同类型id。
最后我们把拼凑的这个64位二进制转成10进制存入数据库或者缓存中。
具体实现因需求而异，实现起来也相当简单，就不把实现贴出来了，只是做个分析，抛砖引玉。
image
网友评论