【原文地址：https://blog.ti-node.com/blog...】唯一ID的生成可不是小事。我想说我喜欢它，它不是简单地创建一个uniqid()那么简单为什么需要一个唯一的ID？1、数据库的自增ID在分库的时候会是一场灾难。假设分为两个数据库，因为每个数据库都会从1开始递增，那时候系统会有两个id为1的用户。2.自增id会暴露用户数或者其他业务量。3、自增id将允许有兴趣者通过API获取任何用户的信息。解决办法是什么？1.UUID，全称UniversallyUniqueIdentifier，中文通用唯一标识符。这是开放软件基金会提出的标准，用于解决在分布式环境中生成唯一标识符的问题。UUID的长度固定为32位，组织格式为8-4-4-4-12，当然使用的时候中间的分隔符要去掉。我不得不提到这个产品的几个问题。首先是字母和数字混在一起。在一些传统的数据库中，索引不是很好。好办，不仅索引量大，查询效率也差。其次，它也非常大。2、MongoDBObjectId，格式和UUID很相似，是Mongodb内置的一种数据类型。如果插入数据时没有指定_id，那么Mongodb会默认使用这个乘积来填写_id。在Mongodb这样的类KV数据库中，具有很好的查询效率。3、自建解决方案，为了解决业务问题，很多公司都自己提出了一些解决方案，而这些解决方案无疑要做到以下几点：保证全局空间的唯一性，保证使用数字类型代替混合数字和字母，保证一定的行序和含义，保证一定的可逆性。通过反解，可以知道ID的相关信息。市面上有几种方案，比如Twitter的snowflake，Flikr的数据库自增方案，Instagram的数据库存储过程方案。下面重点说下推特雪花方案的原理。使用snowflask64bit是用来表示一个id，Twitter工程师将其分为4段，每段代表不同的含义。如下图所示：第一个41bit段是时间戳，单位会精确到毫秒级别。所以这个位段可以时间容量为2^41=2.199x10^12毫秒，即2.199x10^9秒。换算成年，大约是69.7年。也就是说，从1970年1月1日开始，可以使用69.7年，达到了id生成机的上限。中间的10bit段是机器ID，最多可以容纳2^10=1024台机器。可以部署多台机器，每台机器配置一个唯一独立的id例如从1号开始，最多可以部署到1024号机器。然后在机器集群的前端挡一个nginx之类的服务器作为proxy，就可以完成一个好的身份证号分发集群。最后12bit段是自增序列（可以相当于mysql的自增id），代表1毫秒内的自增序列。也就是说，在0毫秒到1毫秒结束的时间段内是自增的。也就是说，1毫秒内最多可以生成2^12=4096个序列，也就是说同一台机器同一毫秒内最多可以生成4096个序列。如果超过这个数，则等待下一毫秒生成新的id。TIPS：顺便说一下，php的uniqid()函数有很大的风险。它生成的id不能像它的名字一样是uniqid，重复的概率略高。有关详细信息，请参阅此函数的手册页注释。点此TIPS：推荐一款基于php的snowflakeid生成器：??donkeyidgenerator
