唯一码

前言：最近，在做用redis存储用户消息的时候，采用的结构如下： Key value Msg+userId+time 消息内容 但是如果在同一时间里面，有很多人并发发送了消息给用户怎么办呢？也就是说只是在key后面加时间 我的时间格式是yyyy-MM-ddHH:mm:ss，这样子万一有重复key怎么办，消息就会被覆盖了 于是想到在后面加uuid，但是uuid有30多位啊，我只需要简单的短的一个避免重复的id就可以了。 于是写了下面代码，并做了测试，发现在100次，每次生成10万条的情况下，都没有重复，这里没有测试100万，1000万条，因为我觉得如果你需要在这种极端情况下的话，你还是需要使用长的uuid的。 下面是8位的短id，基本可以抵抗10万条重复，如果需要9位，11位，16位的，可以如法炮制 public static void main(String args[]){ byte []bytes=new byte[8]; Random random=new Random(); HashSet<String>hash=new HashSet<>(); for(int j=0;j<100;j++) { hash.clear(); for (int i = 0; i < 100000; i++) { random.nextBytes(bytes); String s =

1. 自己写代码产生随机的数字和字母组合，每产生1个去数据库查询该随机码是否已存在，如果已存在，则重新产生，直到不重复为止。 优点：没发现有啥优点。 缺点：产生速度慢，还要查询数据库，当数据量大的时候，可能重复的机率会比较高，要查询多次数据库. 2. guid,该方法应该是用的比较多的。 　　优点：使用简单方便，不用自己编写额外的代码 　　缺点：占用数据库空间相对较大，特别是根据guid查询速度比较慢(毕竟是字符串)。 3. 主键+随机码的方式，我们产生的随机码保存到数据库肯定会有个主键，用该主键+随机字符来组合。产生步骤： 　　1) 先从id生成器中获取id，比如是155. 　　2）填充成固定位数(比如8位)的字符串(不够位数的左边填0，超过位数直接使用该数字)，得到：00000155 　　3）在每个数字后面随机插入1个字母或其它非数字符号，得到：0A0F0R0Y0H1K5L5M 　　这样就可以得到1个随机的唯一的邀请码了。 　　优点：使用也比较简单，不用查询数据库。最大的优点是查询的时候，可以根据邀请码直接得到主键id，然后根据id去数据库查询(速度很快)，再比较查询出来的邀请码和用户提交的邀请码是否一致。 　　缺点：需要使用id产生器，如果主键是数据库自增长的就不太好用(需要先插入数据库获取id，再更新邀请码)。 4. 有时候产品经理说，我要求邀请码都是数字的