用户UID的几种生成方案

对于一个数据库开发者来说，牢固扎实的基础是十分重要的，golang学习网就来带大家一点点的掌握基础知识点。今天本篇文章带大家了解《用户UID的几种生成方案》，主要介绍了MySQL、微服务、Java、go、uuid，希望对大家的知识积累有所帮助，快点收藏起来吧，否则需要时就找不到了！

本文目的是介绍市面上流行的UID生成方式、优劣情况，帮助读者根据自己的产品类型和用户规模选择合适的生成方案。

什么是UID?

UID是一个系统内用户的唯一标识，

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

唯一性

通过UID可以快速映射到一个具体的唯一用户上，类似于hash、短网址映射。

可公开广播

UID可以和用户的账号形成对应关系。对于某些以手机号、邮箱这些隐私内容为登录账号的系统，如果想增加转账这种业务，输入对方的UID，可以做到隐私保护。

存在可能价值

类似QQ靓号、B站短ID、微博ID这种可以存在部分价值。

流行的生成方式

1. 随机生成-普通查重模式
2. 经典表ID自增模式
3. 号池模式
4. 随机生成-查重模式-加位法
5. 类Snowflake模式
6. UUID模式

随机生成-普通查重模式

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

优点: 生成速度快、逻辑简单、生成号段格式可以通过过滤器控制。
缺点: 当用户总数变高的时候，重复率会变高。
适用: 用户总量不会很高，对于靓号没有什么要求。

经典表ID自增

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

优点: 不需要主动管理，自动生成，不会重复。
缺点: 容易暴露系统的真实用户数，不适合需要良好数据的商业公司。
适用: 普通的社区、博客内容等不关注UID模式的系统。

号池模式

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

优点: 对于靓号的控制精准、号池控制得当的话，不会发生重复。
缺点: 对于号池服务的稳定性很高, 对于号池内数据的增加和删除需要主动管理，否则会发生重复。
适用: 对靓号要求控制严格，适用于一般的等级荣誉感、靓号荣誉感较高的玩家社区。

随机生成-查重模式-加位法

加位查重法是普通查重法的升级，当碰到了重复号码的时候，向号码尾部增加一个随机数字，如果重复就继续增加，直到不重复为止。

优点: 相对于普通查重法，重复后的再次获取次数可以减少
缺点: 重复后再获取率随着用户数上升，也会遭遇瓶颈。
适用: 同普通查重模式。

类Snowflake模式

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

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

优点: 不需要主动管理就可保证防重性，可以根据业务配比调整bit。
缺点: 生成的数据结果比较长，索引需要主动优化。
适用: 不存在UID靓号需求

UUID模式

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

优点: 不需要主动管理就可保证防重性。
缺点: 生成的数据结果比较长，索引需要主动优化。
适用: 不存在UID靓号需求

总结

一般对于预计百万用户以内的系统，将UID设置为10位，使用随机成产-普通查重模式即可。查重基本上不会损耗过多性能，还可以根据过滤器过滤掉靓号，基本上可以解决大部分的业务需求。

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

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于数据库的相关知识，也可关注golang学习网公众号。