南京企业建网站流程,wordpress查看权限,iis 编辑网站绑定,电子商务工作好找吗UUID和雪花(Snowflake)算法该如何选择#xff1f;
UUID 和 Snowflake 都可以生成唯一标识#xff0c;在分布式系统中可以说是必备利器#xff0c;那么我们该如何对不同的场景进行不同算法的选择呢#xff0c;UUID 简单无序十分适合生成 requestID#xff0c; Snowflake 里…
UUID和雪花(Snowflake)算法该如何选择
UUID 和 Snowflake 都可以生成唯一标识在分布式系统中可以说是必备利器那么我们该如何对不同的场景进行不同算法的选择呢UUID 简单无序十分适合生成 requestID Snowflake 里面包含时间序列等可以用于排序效率都还可以本文详细介绍了我们选择的使用不同算法的原因两种算法不同维度的对比。
数据库的主键要如何选择
数据库中的每一条记录都需要有一个唯一的标识依据数据库的第二范式数据库中每一个表中都需要有一个唯一的主键其他数据元素和主键一一对应。 那么关于主键的选择就成为一个关键点了一般来讲你有两种选择方式
使用业务字段作为主键比如说对于用户表来说可以使用手机号email 或者身份证号作为主键。使用生成的唯一 ID 作为主键。
不过对于大部分场景来说第一种选择并不适用比如像评论表你就很难找到一个业务字段作为主键因为在评论表中你很难找到一个字段唯一标识一条评论。而对于用户表来说我们需要考虑的是作为主键的业务字段是否能够唯一标识一个人一个人可以有多个 email 和手机号一旦出现变更 email 或者手机号的情况就需要变更所有引用的外键信息所以使用 email 或者手机作为主键是不合适的。
身份证号码确实是用户的唯一标识但是由于它的隐私属性并不是一个用户系统的必须属性你想想你的系统如果没有要求做实名认证那么肯定不会要求用户填写身份证号码的。并且已有的身份证号码是会变更的比如在 1999 年时身份证号码就从 15 位变更为 18 位但是主键一旦变更以这个主键为外键的表也都要随之变更这个工作量是巨大的。
因此我更倾向于使用生成的ID作为数据库的主键。不单单是因为它的唯一性更是因为一旦生成就不会变更可以随意引用。
在单库单表的场景下我们可以使用数据库的自增字段作为 ID因为这样最简单对于开发人员来说也是透明的。但是当数据库分库分表后使用自增字段就无法保证 ID的全局唯一性了。
想象一下当我们分库分表之后同一个逻辑表的数据被分布到多个库中这时如果使用数据库自增字段作为主键那么只能保证在这个库中是唯一的无法保证全局的唯一性。那么假如你来设计用户系统的时候使用自增 ID作为用户 ID就可能出现两个用户有两个相同的 ID这是不可接受的那么你要怎么做呢我建议你搭建发号器服务来生成全局唯一的 ID。
UUID与Snowflake对比
从我历年所经历的项目中我主要使用的是变种的 Snowflake 算法来生成业务需要的 ID的本讲的重点也是运用它去解决 ID全局唯一性的问题。搞懂这个算法知道它是怎么实现的就足够你应用它来设计一套分布式发号器了不过你可能会说了“那你提全局唯一性怎么不提 UUID 呢”
没错UUIDUniversally Unique Identifier通用唯一标识码不依赖于任何第三方系统所以在性能和可用性上都比较好我一般会使用它生成 Request ID 来标记单次请求但是如果用它来作为数据库主键它会存在以下几点问题。
排序
首先生成的 ID做好具有单调递增性也就是有序的而 UUID 不具备这个特点。为什么 ID 要是有序的呢因为在系统设计时ID有可能成为排序的字段。我给你举个例子。
比如你要实现一套评论的系统时你一般会设计两个表一张评论表存储评论的详细信息其中有 ID字段有评论的内容还有评论人 ID被评论内容的 ID等等以 ID字段作为分区键另一个是评论列表存储着内容 ID 和评论 ID的对应关系以内容 ID为分区键。
我们在获取内容的评论列表时需要按照时间序倒序排列因为 ID是时间上有序的所以我们就可以按照评论 ID的倒序排列。而如果评论 ID不是在时间上有序的话我们就需要在评论列表中再存储一个多余的创建时间的列用作排序假设内容 ID、评论 ID和时间都是使用 8 字节存储我们就要多出 50% 的存储空间存储时间字段造成了存储空间上的浪费。
有序ID会提升数据的写入性能
我们知道 MySQL InnoDB 存储引擎使用 B 树存储索引数据而主键也是一种索引。索引数据在 B 树中是有序排列的就像下面这张图一样图中 21026 都是记录的 ID也是索引数据。 20201124094634
这时当插入的下一条记录的 ID是递增的时候比如插入 30 时数据库只需要把它追加到后面就好了。但是如果插入的数据是无序的比如 ID是 13那么数据库就要查找 13 应该插入的位置再挪动 13 后面的数据这就造成了多余的数据移动的开销。 20201124094654
我们知道机械磁盘在完成随机的写时需要先做 “寻道” 找到要写入的位置也就是让磁头找到对应的磁道这个过程是非常耗时的。而顺序写就不需要寻道会大大提升索引的写入性能。
UUID不具备业务含义
其实现实世界中使用的 ID中都包含有一些有意义的数据这些数据会出现在 ID的固定的位置上。比如说我们使用的身份证的前六位是地区编号714 位是身份证持有人的生日不同城市电话号码的区号是不同的你从手机号码的的前三位就可以看出这个手机号隶属于哪一个运营商。而如果生成的 ID可以被反解那么从反解出来的信息中我们可以对 ID来做验证我们可以从中知道这个 ID的生成时间从哪个机房的发号器中生成的为哪个业务服务的对于问题的排查有一定的帮助。
最后UUID 是由 32 个 16 进制数字组成的字符串如果作为数据库主键使用比较耗费空间。
你能看到UUID 方案有很大的局限性也是我不建议你用它的原因而 twitter 提出的 Snowflake 算法完全可以弥补 UUID 存在的不足因为它不仅算法简单易实现也满足 ID所需要的全局唯一性单调递增性还包含一定的业务上的意义。
Snowflake 的核心思想是将 64bit 的二进制数字分成若干部分每一部分都存储有特定含义的数据比如说时间戳、机器 ID、序列号等等最终生成全局唯一的有序 ID。它的标准算法是这样的 20201124094828
从上面这张图中我们可以看到41 位的时间戳大概可以支撑 pow(2,41)/1000/60/60/24/365 年约等于 69 年对于一个系统是足够了。
如果你的系统部署在多个机房那么 10 位的机器 ID可以继续划分为 23 位的 IDC 标示可以支撑 4 个或者 8 个 IDC 机房和 78 位的机器 ID支持 128-256 台机器12 位的序列号代表着每个节点每毫秒最多可以生成 4096 的 ID。
不同公司也会依据自身业务的特点对 Snowflake 算法做一些改造比如说减少序列号的位数增加机器 ID的位数以支持单 IDC 更多的机器也可以在其中加入业务 ID 字段来区分不同的业务。比方说我现在使用的发号器的组成规则就是1 位兼容位恒为 0 41 位时间信息 6 位 IDC 信息支持 64 个 IDC 6 位业务信息支持 64 个业务 10 位自增信息每毫秒支持 1024 个号
我选择这个组成规则主要是因为我在单机房只部署一个发号器的节点并且使用 KeepAlive 保证可用性。业务信息指的是项目中哪个业务模块使用比如用户模块生成的 ID内容模块生成的 ID把它加入进来一是希望不同业务发出来的 ID可以不同二是因为在出现问题时可以反解 ID知道是哪一个业务发出来的 ID。
实现方式
那么了解了 Snowflake 算法的原理之后我们如何把它工程化来为业务生成全局唯一的 ID呢
嵌入到业务代码里也就是分布在业务服务器中
这种方案的好处是业务代码在使用的时候不需要跨网络调用性能上会好一些但是就需要更多的机器 ID位数来支持更多的业务服务器。另外由于业务服务器的数量很多我们很难保证机器 ID的唯一性所以就需要引入 ZooKeeper 等分布式一致性组件来保证每次机器重启时都能获得唯一的机器 ID。
作为独立的发号器服务部署
业务在使用发号器的时候就需要多一次的网络调用但是内网的调用对于性能的损耗有限却可以减少机器 ID的位数如果发号器以主备方式部署同时运行的只有一个发号器那么机器 ID可以省略这样可以留更多的位数给最后的自增信息位。即使需要机器 ID因为发号器部署实例数有限那么就可以把机器 ID写在发号器的配置文件里这样即可以保证机器 ID唯一性也无需引入第三方组件了。微博和美图都是使用独立服务的方式来部署发号器的性能上单实例单 CPU 可以达到两万每秒。
Snowflake 算法设计的非常简单且巧妙性能上也足够高效同时也能够生成具有全局唯一性、单调递增性和有业务含义的 ID但是它也有一些缺点其中最大的缺点就是它依赖于系统的时间戳一旦系统时间不准就有可能生成重复的 ID。所以如果我们发现系统时钟不准就可以让发号器暂时拒绝发号直到时钟准确为止。
另外如果请求发号器的 QPS 不高比如说发号器每毫秒只发一个 ID就会造成生成 ID的末位永远是 1那么在分库分表时如果使用 ID作为分区键就会造成库表分配的不均匀。这一点也是我在实际项目中踩过的坑而解决办法主要有两个
时间戳不记录毫秒而是记录秒这样在一个时间区间里可以多发出几个号避免出现分库分表时数据分配不均。生成的序列号的起始号可以做一下随机这一秒是 21下一秒是 30这样就会尽量的均衡了。
我在开头提到自己的实际项目中采用的是变种的 Snowflake 算法也就是说对 Snowflake 算法进行了一定的改造从上面的内容中你可以看出这些改造一是要让算法中的 ID 生成规则符合自己业务的特点二是为了解决诸如时间回拨等问题。
其实大厂除了采取 Snowflake 算法之外还会选用一些其他的方案比如滴滴和美团都有提出基于数据库生成 ID的方案。这些方法根植于公司的业务同样能解决分布式环境下 ID全局唯一性的问题。对你而言可以多角度了解不同的方法这样能够寻找到更适合自己业务目前场景的解决方案不过我想说的是方案不在多而在精方案没有最好只有最适合真正弄懂方法背后的原理并将它落地才是你最佳的选择。
总结
Snowflake 的算法并不复杂你在使用的时候可以不考虑独立部署的问题先想清楚按照自身的业务场景需要如何设计 Snowflake 算法中的每一部分占的二进制位数。比如你的业务会部署几个 IDC应用服务器要部署多少台机器每秒钟发号个数的要求是多少等等然后在业务代码中实现一个简单的版本先使用等到应用服务器数量达到一定规模再考虑独立部署的问题就可以了。这样可以避免多维护一套发号器服务减少了运维上的复杂度。
