关于java:用户UID的几种生成方案

本文目标是介绍市面上风行的 UID 生成形式、优劣状况，帮忙读者依据本人的产品类型和用户规模抉择适合的生成计划。

UID是一个零碎内用户的惟一标识，

UID 的个性: 唯一性、可公开播送、存在可能价值等。

通过 UID 能够疾速映射到一个具体的惟一用户上，相似于 hash、短网址映射。

UID能够和用户的账号造成对应关系。对于某些以手机号、邮箱这些隐衷内容为登录账号的零碎，如果想减少转账这种业务，输出对方的 UID，能够做到隐衷爱护。

相似 QQ 靓号、B 站短 ID、微博 ID 这种能够存在局部价值。

应用 rand 函数随机成生后果，再去 user 表上查重，不反复就作为用户的 UID，反复则持续 rand 到不反复为止。

长处: 生成速度快、逻辑简略、生成号段格局能够通过过滤器管制。
毛病: 当用户总数变高的时候，反复率会变高。
实用: 用户总量不会很高，对于靓号没有什么要求。

将 user 表的 id 设置为 auto_increment，插入会主动生成 ID，将表的主键 ID 作为 UID.

长处: 不须要被动治理，主动生成，不会反复。
毛病: 容易裸露零碎的实在用户数，不适宜须要良好数据的商业公司。
实用: 一般的社区、博客内容等不关注 UID 模式的零碎。

生成一批 UID 寄存到号池内，注册一个取走一个。

长处: 对于靓号的管制精准、号池管制切当的话，不会产生反复。
毛病: 对于号池服务的稳定性很高, 对于号池内数据的减少和删除须要被动治理，否则会产生反复。
实用: 对靓号要求管制严格，实用于个别的等级荣誉感、靓号荣誉感较高的玩家社区。

加位查重法是一般查重法的降级，当碰到了反复号码的时候，向号码尾部减少一个随机数字，如果反复就持续减少，直到不反复为止。

长处: 绝对于一般查重法，反复后的再次获取次数能够缩小
毛病: 反复后再获取率随着用户数回升，也会遭逢瓶颈。
实用: 同一般查重模式。

Snowflake是一个经典的号段生成算法，同时市面上存在大量的 XXXflake 算法. 个别用作订单号。次要讲一下 Snowflake 的原理

应用 41bit 作为毫秒数，10bit 作为机器的 ID（5 个 bit 是数据中心，5 个 bit 的机器 ID），12bit 作为毫秒内的流水号，最初还有一个符号位，永远是 0

长处: 不须要被动治理就可保障防重性，能够依据业务配比调整 bit。
毛病: 生成的数据后果比拟长，索引须要被动优化。
实用: 不存在 UID 靓号需要

UUID是一个国际标准算法，具体介绍就不赘述了，优缺点和类 Snowflake 统一

长处: 不须要被动治理就可保障防重性。
毛病: 生成的数据后果比拟长，索引须要被动优化。
实用: 不存在 UID 靓号需要

个别对于预计百万用户以内的零碎，将 UID 设置为 10 位，应用随机成产 - 一般查重模式即可。查重基本上不会损耗过多性能，还能够依据过滤器过滤掉靓号，基本上能够解决大部分的业务需要。

对于预计超过百万的用户，最重要的是关注业务对于 UID 的依赖和靓号的需要，抉择适合的计划。

什么是 UID?