分布式发号器——Vesta

1、基于时间戳 
比如流水号规则如下：XX-YYYYMMDD-N位随机数，这也是企业级应用开发常用的规则。此流水号对人比较友好，可识别性高，但容量受后面随机数的限制，且数据量越大，生成时难度越高。前三部分每天的流水号基本固定，后面的N位随机数生成后，需要校验此前不存在，可依赖redis的set机制，每天的随机数都写到一个set集合中[set容易达42亿之多，完全够用]，重新生成后要与set集合作比对，以确保其唯一性。一天内不重复，再结合确定日期来保证其唯一性。

N位随机数生成时，可基于系统时间戳，再与一个大数取模生成。 
2、UUID 
不连续，占用空间大，不利于B+发挥作用，在写的操作的是不能进行append，只能进行insert，记录占用空间比较大 
3、Vesta 
通用ID产生器，统一发号器，具有全局唯一性，大概有序，可反解，可制造，支持4种发布方式。rest发布模式netty，rest发布模式tomcat，中心服务器发布模式，嵌入式发布模式 
4、snowflake 
发布模式比较单一，而且语言是Scala 
0 - 0000000000 0000000000 0000000000 0000000000 0 - 00000 - 00000 - 000000000000

第一位为未使用，接下来的41位为毫秒级时间(41位的长度可以使用69年)，然后是5位datacenterId和5位workerId(10位的长度最多支持部署1024个节点） ，最后12位是毫秒内的计数（12位的计数顺序号支持每个节点每毫秒产生4096个ID序号）

一共加起来刚好64位，为一个Long型。(转换成字符串长度为18)

snowflake生成的ID整体上按照时间自增排序，并且整个分布式系统内不会产生ID碰撞（由datacenter和workerId作区分），并且效率较高。据说：snowflake每秒能够产生26万个ID。 
5、redis分布式id生成器 
6、mongodb的objectId

公司情况，之前公司采用的是uuid,在业务发展的过程中，发现uuid相对于long类型来说更耗费性能，而且在范围查询的时候对索引的利用率效果不是很好。再加上公司有一些其他的语言，所以经过考虑公司采用Vesta发号器。
-