服务化、分布式已成为当下系统开发的首选，高并发操作在数据存储时，需要一套id生成器服务，来保证分布式情况下全局唯一性，以确保系统的订单创建、交易支付等场景下数据的唯一性，否则将造成不可估量的损失。
比如流水号规则如下：XX-YYYYMMDD-N位随机数，这也是企业级应用开发常用的规则。此流水号对人比较友好，可识别性高，但容量受后面随机数的限制，且数据量越大，生成时难度越高。前三部分每天的流水号基本固定，后面的N位随机数生成后，需要校验此前不存在，可依赖redis的set机制，每天的随机数都写到一个set集合中[set容易达42亿之多，完全够用]，重新生成后要与set集合作比对，以确保其唯一性。一天内不重复，再结合确定日期来保证其唯一性。
N位随机数生成时，可基于系统时间戳，再与一个大数取模生成。
最简单直接暴力的方式，虽然能够保证ID的唯一性，但是，它无法满足业务系统需要的很多其他特性，例如：时间粗略有序性，可反解和可制造型。另外，UUID产生的时候使用完全的时间数据，性能比较差，并且UUID比较长，占用空间大，间接导致数据库性能下降，更重要的是，UUID并不具有有序性。系统容量较小的时候可以采用，变大后不建议采用此方式。
GitHub 地址：https://github.com/robertleepeak/vesta-id-generator
Vesta是一款通用的ID产生器，互联网俗称统一发号器，它具有全局唯一、粗略有序、可反解和可制造等特性，它支持三种发布模式：嵌入发布模式、中心服务器发布模式、REST发布模式，根据业务的性能需求，它可以产生最大峰值型和最小粒度型两种类型的ID，它的实现架构使其具有高性能，高可用和可伸缩等互联网产品需要的质量属性，是一款通用的高性能的发号器产品。 提供4种应用部署方式，具体使用依场景而定：
REST发布模式（Netty）
REST发布模式（Tomcat）
中心服务器发布模式
嵌入式发布模式
GitHub 地址：https://github.com/twitter/snowflake
Twitter-Snowflake算法产生的背景相当简单，为了满足Twitter每秒上万条消息的请求，每条消息都必须分配一条唯一的id，这些id还需要一些大致的顺序（方便客户端排序），并且在分布式系统中不同机器产生的id必须不同。
snowflake的结构如下(用-分开):
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。
GitHub 地址：https://github.com/hengyunabc/redis-id-generator
依赖redis的EVAL,EVALSHA两个命令，利用redis的lua脚本执行功能，在每个节点上通过lua脚本生成唯一ID。 生成的ID是64位的：
使用41 bit来存放时间，精确到毫秒，可以使用41年。
使用12 bit来存放逻辑分片ID，最大分片ID是4095
使用10 bit来存放自增长ID，意味着每个节点，每毫秒最多可以生成1024个ID
Redis提供了TIME命令，可以取得redis服务器上的秒数和微秒数。因些lua脚本返回的是一个四元组。
second, microSecond, partition, seq
客户端要自己处理，生成最终ID。
((second * 1000 + microSecond / 1000) << (12 + 10)) + (shardId << 10) + seq;
在redis-id-generator-java目录下，有example和benchmark代码，提供了 Java客户端生成模式，其它语言只要支持redis evalsha命令就可以了。
Mongodb集合中的每个document中都必须有一个"_id"键，这个键的值可以是任何类型的，在默认的情况下是个Objectid对象。mongodb的ObejctId生产思想在很多方面挺值得我们借鉴的，特别是在大型分布式的开发，如何构建轻量级的生产，如何将生产的负载进行转移，如何以空间换取时间提高生产的最大优化等等。
