我接触的最早的Unique ID,就是Oracle的自增ID。
特点是准连续的自增数字,为什么说是准连续?因为性能考虑,每个Client一次会领20个ID回去慢慢用,用完了再来拿。另一个Client过来,拿的就是另外20个ID了。
新浪微博里,Tim用Redis做相同的事情,Incr一下拿一批ID回去。如果有多个数据中心,那就拿高位的几个bit来区分。
只要舍得在总架构里增加额外Redis带来的复杂度,一个64bit的long就够表达了,而且不可能有重复ID。
Universally Unique IDentifier(UUID),有着正儿八经的RFC规范,是一个128bit的数字,也可以表现为32个16进制的字符,中间用”-"分割。
- 时间戳+UUID版本号,分三段占16个字符(60bit 4bit),
- Clock Sequence号与保留字段,占4个字符(13bit+3bit),
- 节点标识占12个字符(48bit),
比如:f81d4fae-7dec-11d0-a765-00a0c91e6bf6
实际上,UUID一共有多种算法,能用于TraceId的是:
- version1: 基于时间的算法
- version4: 基于随机数的算法
先说Version4,这是最暴力的做法,也是JDK里的算法,不管原来各个位的含义了,除了少数几个位必须按规范填,其余全部用随机数表达。
JDK里的实现,用 SecureRandom生成了16个随机的Byte,用2个long来存储。记得加-Djava.security.egd=file:/dev/./urandom,否则会锁住程序等噪音。
详见 JVM上的随机数与熵池策略
然后是Version1,严格守着原来各个位的规矩:
因为时间戳有满满的60bit,所以可以尽情花,以100纳秒为1,从1582年10月15日算起(能撑3655年,真是位数多给烧的,1582年有意思么)
湘ICP备2022002427号-10 湘公网安备:43070202000427号
© 2013~2024 haote.com 好特网