标签:word 影响 第一个 token webp ase 主键 put 并发
UUID(Universally Unique Identifier)是32个16进制数字,以连字号分为五段,形式为8-4-4-4-12的36个字符。其中32个字符和4个连字符‘ - ‘,一般我们使用的时候会将连字符删除 uuid.toString().replaceAll("-","")
。
目前UUID的产生方式有5种版本,每个版本的算法不同,应用范围也不同。
org.apache.logging.log4j.core.util
包中的 UuidUtil.getTimeBasedUuid()
来使用或者其他包中工具。由于使用了MAC地址,因此能够确保唯一性,但是同时也暴露了MAC地址,私密性不够好。我们 Java中 JDK自带的 UUID产生方式就是版本4根据随机数生成的 UUID 和版本3基于名字的 UUID,有兴趣的可以去看看它的源码。
public static void main(String[] args) {
//获取一个版本4根据随机字节数组的UUID。
UUID uuid = UUID.randomUUID();
System.out.println(uuid.toString().replaceAll("-",""));
//获取一个版本3(基于名称)根据指定的字节数组的UUID。
byte[] nbyte = {10, 20, 30};
UUID uuidFromBytes = UUID.nameUUIDFromBytes(nbyte);
System.out.println(uuidFromBytes.toString().replaceAll("-",""));
}
好处:生成简单,每个系统本地生成就可以。
坏处:太长和无序,会导致以下问题:
1、很多业务场景不适用,比如优惠券的发放,可能12位的券池就能满足发放的需要了,太长不但不易于存储,还会导致无法用于券码的展示
2、不利于做索引。mysql存储时,uuid的长度太长不利于做主键,而且无序性会导致作为主键插入时数据位置频繁变动,影响性能
所以,很多场景或者用于主键的情况下,都不能使用uuid
可以创建一个表,通过数据插入获取对应的自增主键,作为全局唯一id
缺点也很明显,就是高并发的场景下,受限于单台mysql的性能。而且可用性差,DB出现问题会导致id无法生成。
当然可以通过主从的方式增强可用性,同时增加表采用不同自增步长的方式增加并发性能,比如假设我们要部署3台机器,步长需设置为3,每台的初始值依次为1,2.3;但是还会带来新的问题,比如不利于拓展,想提升性能就要堆机器,但是步长已经确定不好更改,主从延迟会导致唯一id的不唯一,。
这是twitter开源的分布式id生成算法,这种方案把64-bit分别划分成多段,分开来标示机器、时间等,比如在snowflake中的64-bit分别表示如下图(图片来自网络)所示:
上面第一个部分,是1个bit:0,这个是无意义的上面第二个部分是41个bit:表示的是时间戳;上面第三个部分是5个bit:表示的是机房id,10001上面第四个部分是5个bit:表示的是机器id,1 1001上面第五个部分是12个bit:表示的序号,就是某个机房某台机器上这一毫秒内同时生成的id的序号,0000 00000000
优点:灵活,5位可以用来做业务标识
缺点:比较依赖时钟
标签:word 影响 第一个 token webp ase 主键 put 并发
原文地址:https://www.cnblogs.com/seven717/p/11920671.html