数据库中的每条记录都需要一个ID,即使在分库分表后这个ID需要全局唯一性。因此,分库分表后不能使用Mysql自带的自增ID了。因为不通的库之间的ID可能是一样的。
我们以记录海量的用户信息为例,可能会想到身份证号、电话号码或者email。但是这些信息是会变的。如果用户要修改这些信息,那么ID就失效了。无异于新增一条记录,删掉原来的记录。
基于 Snowflake 算法搭建发号器
雪花算法可以提供全局唯一的ID。雪花算法生成的ID一般是分几段的,下图就是典型的ID组成:41位时间戳(一般是毫秒级?)+10位机器ID+12位序列号。
41位时间戳毫秒级的大概有69年,10位机器ID可以表示一个由1024台机器组成的发号器集群。12位序列号表示一毫秒每台机器可以提供4000个不通的ID,也就是一秒钟400W个。。。
为何不用UUID?
这是个好问题,我之前没考虑过。
确实,UUID是32个16进制组成的字符串,也具有全局唯一性。
那么为何不用呢。此处需要考虑业务ID需要哪些特性:1、全局唯一性(UUID符合)2、生成性能要好(UUID符合)3、写入性能要好 4、最好要有具体的业务含义,方便定位问题。
前两点UUID都符合,我们都知道Mysql对于随机写的TPS是很差的,对于顺序写性能很好。因为顺序写入节约了一次寻道时间。而写入是要按照ID排序的。UUID是随机的,不是递增的,所以如果用UUID作为mysql的ID是会严重影响写入性能的。
不用UUID作为mysql ID的另一个原因是UUID不具备业务解释性,比如我们之前设计的ID就是用类似于雪花算法生成的,时间戳+机器ID+其他一些业务信息,这样出现了badcase,第一时间拿到ID就知道是哪个方面出问题了。比如文章ID最后两位表示文章来源,那么如果badcase的ID都集中在某一个来源,那么直觉告诉我们某些特定业务出问题了,便于排查问题。
雪花算法如何落地?
大致有两种做法:
一、嵌入在代码里面,每台机器有自己的机器ID,这样就能生成唯一的ID了。这样做的好处是没有网络交互,性能好。不过如果机器众多或者机器重启,比较难保证每台机器ID是唯一的,这样就要引入ZK等组件来保证ID的一致性,这样就引入了新的zk问题。
二、第二种做法是,搭建一个发号器集群。这样做每次插入ID都会有一个额外的网络交互,但是对于内网来说,性能损失很小,这方面的损失是可以接受的。由于发号器性能很好,所以只需要少量机器就能提供大量的ID,QPS很高。这样可以减少机器数量,ID中用于表示机器ID的位数可以减少,提供的号就会变多。如果只有一台发号器,多个备份发号器,那么可以无需机器ID。一般情况下有少量的几台一起提供发号服务,此时由于机器较少,可以把机器ID写到配置文件中,也不会因为方法一带来的第三方组件问题。
可能引入的问题
雪花算法最大的问题就是他依赖于时间戳,如果时间不准了,那么就有可能导致产生重复的ID,此时需要调整时间,再发号。
还有一个可能引入的问题是如果QPS不高,那么以毫秒为粒度的ID可能分配不均匀,极端例子就是QPS为1,每秒的第一个毫秒产生一个ID,业务方拿到ID后根据时间戳去hash到每个库中,那么就会导致数据的不均匀。因此,很多实践过程中都是根据自己的需要进行变种的。可以把雪花算法前面的时间戳粒度变为秒,而不是毫秒。这样ID至于时间的分布就会相对均匀很多。
原文地址:https://www.cnblogs.com/howo/p/12147595.html