我接触的最早的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年有意思么)
小编推荐阅读
