做项目的时候经常会用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 据听说twitter用的也是此方法 什么是通过约束条件生成唯一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。轻松满足需求。 最后切割成的效果可能是这样： 但是，这不是这个方法最大的好处，最大的好处是可以根据需求定制不同的约束条件，可以增加条件，继续分割这个64位数。 那么当条件比较多，64位不够分割的时候怎么办。有办法，进行移位操作，比如讲时间条件右移4位，那么1ms的约束条件就变成了16ms了，完全根据需求而定。 所以这个方法最大好处莫过于灵活，可控性强，根据需求可以轻易定制不同类型id。 最后我们把拼凑的这个64位二进制转成10进制存入数据库或者缓存中。 具体实现因需求而异，实现起来也相当简单，就不把实现贴出来了，只是做个分析，抛砖引玉。

如果想学习Java工程化、高性能及分布式、深入浅出。性能调优、Spring，MyBatis，Netty源码分析的朋友可以加我的Java高级架构进阶群：180705916，群里有阿里大牛直播讲解技术，以及Java大型互联网技术的视频免费分享给大家