为了标识一段数据,通常我们会为其指定一个唯一id,比如数据库中的自增主键。
但是当数据量非常大时,仅靠数据库的自增主键是远远不够的。不仅是因为单表容量有限,数据库自增主键的性能也并不高。此外,某些数据库并不自带主键自增功能,需要业务代码来实现(比如Redis缓存)。
对于分布式场景,生成id时还必须考虑到全局唯一性,每台机器生成的id不能重复。而且有时我们对生成的id还有递增或连续的要求。
如果生成的id不要求递增或连续,对于简单的系统,可以直接采用随机UUID来作为id。
1位标识部分:在java中由于long的最高位是符号位,正数是0,负数是1,一般生成的ID为正数,所以为0;
41位时间戳部分:这个是毫秒级的时间,一般实现上不会存储当前的时间戳,而是时间戳的差值(当前时间-固定的开始时间),这样可以使产生的ID从更小值开始;41位的时间戳可以使用69年,(1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69年。
10位节点部分:Twitter实现中使用前5位作为数据中心标识,后5位作为机器标识,可以部署1024个节点。
12位序列号部分:支持同一毫秒内同一个节点可以生成4096个ID。
SnowFlake算法生成的ID大致上是按照时间递增的,用在分布式系统中时,需要注意数据中心标识和机器标识必须唯一,这样就能保证每个节点生成的ID都是唯一的。或许我们不一定都需要像上面那样使用5位作为数据中心标识,5位作为机器标识,可以根据我们业务的需要,灵活分配节点部分,如:若不需要数据中心,完全可以使用全部10位作为机器标识;若数据中心不多,也可以只使用3位作为数据中心,7位作为机器标识。
UUID是什么?
这串数字,其实就是一种UUID:00000000-0000-0000-0000-000000000000
UUID是通用唯一识别码(Universally Unique Identifier)的缩写,开放软件基金会(OSF)规范定义了包括网卡MAC地址、时间戳、名字空间(Namespace)、随机或伪随机数、时序等元素。利用这些元素来生成UUID,可以把它理解为一个随机的固定位数的字符串,一般为128位二进制组成,32位十六进制。 UUID有多种不同的生成策略,如Java中有四种策略。四种不同的UUID的生成策略
- randomly: 基于随机数生成UUID,由于Java中的随机数是伪随机数,其重复的概率是可以被计算出来的。
- time-based:基于时间的UUID,这个一般是通过当前时间,随机数,和本地Mac地址来计算出来,自带的JDK包并没有这个算法的我们在一些UUIDUtil中,比如我们的log4j.core.util,会重新定义UUID的高位和低位。
- DCE security:DCE安全的UUID。
- name-based:基于名字的UUID,通过计算名字和名字空间的MD5来计算UUID。
UUID的优缺点?
优点
- 本地生成,无需网络通讯,性能较高
- 无序,不可预测,可以避免爬虫之类的攻击
缺点
- 32位通常用String类型存储,空间占用较多
- 不能生成递增有序的数字
雪花算法实现原理?
SnowFlake算法产生的ID是一个64位的整型,结构如下:![d18c361393bde7ce6975207253465671.png](https://i-blog.csdnimg.cn/blog_migrate/b8edd64b9e1b9c8aa7b142505184d96c.jpeg)