南通网站,网店怎么开视频教程,海门建网站公司,全自动网站建设业务系统对分布式ID的要求 唯一性#xff1a;在分布式系统中#xff0c;每个节点都需要生成唯一的标识符来确保数据的唯一性。传统的单点生成ID方式无法满足分布式环境下的需求#xff0c;而分布式ID能够在整个系统中保证每个节点生成的ID都是唯一的。 顺序性#xff1a;某…业务系统对分布式ID的要求 唯一性在分布式系统中每个节点都需要生成唯一的标识符来确保数据的唯一性。传统的单点生成ID方式无法满足分布式环境下的需求而分布式ID能够在整个系统中保证每个节点生成的ID都是唯一的。 顺序性某些场景下需要生成的ID具有一定的顺序性例如按时间顺序记录事件或日志。分布式ID生成策略能够在保证唯一性的同时尽可能地保持ID的顺序性方便对数据进行排序和分析。 性能分布式ID生成策略通常被设计为高性能的方案能够在高并发的情况下快速生成ID。这对于分布式系统中大量的并行操作和高频率的请求是至关重要的以确保系统的吞吐量和响应时间。 可扩展性在分布式系统中节点数量可能会随着系统的扩展而增加。使用分布式ID可以避免单点生成ID的瓶颈并且能够轻松地扩展到更多的节点以适应系统的增长和负载的增加。 无依赖性分布式ID生成策略通常是独立于外部资源或服务的因此不需要依赖特定的数据库或其他中心化的组件。这使得系统更加灵活和独立减少了对外部资源的依赖性和单点故障的风险。
分布式ID生成方案 UUID 数据库自增 号段模式 Redis实现 雪花算法(SnowFlake) 美团Leaf 滴滴TinyID
UUID
UUIDUniversally Unique Identifier是一种标识符用于在分布式系统中生成唯一的标识值。它是由一组字母和数字组成的128位16字节的字符串通常以连字符分隔成五段形如aa82878d-60cb-4a01-9719-b4af90490fbd 优点唯一性、简单易用、高性能(基于本地算法生成) 缺点长度较长浪费存储空间、可读性差、无序性、不支持自增
数据库自增
假设在一个大型电商项目中将订单表拆分放在db_0、db_1的两个数据库中其中db_0数据库中有t_order_01、t_order_02两张订单表db_1数据库中也有t_order_03、t_order_04两张订单表如果使用数据库自增来生成分布式ID那么t_order_01、t_order_02、t_order_03、t_order_04的默认值分别是1、2、3、4每次插入数据时的步长是4。如下图所示 虽然数据库的自增看起来是没问题的但是如果继续扩容是一件很麻烦的事情因为要重新设置步长如一开始是4张订单表步长为4后面将订单表扩容为8那么步长就变成8并且还需要将旧数据重新迁移。
号段模式
设计一个专门生成号段的ID生成器一般是一个单独的服务或者模块在该服务中维护生成区段号的表表结构如下max_id是当前id的最大值step是步长一次请求过来则返回[max_id 1,max_id step]的区间biz_type是业务类型
CREATE TABLE id_generator (id int(10) NOT NULL,max_id bigint(20) NOT NULL COMMENT 当前最大id,step int(20) NOT NULL COMMENT 号段的布长,biz_type int(20) NOT NULL COMMENT 业务类型PRIMARY KEY (id)
) 当需要ID时则向ID生成器请求一个区段ID生成器则根据max_id和step计算一个号段返回如[max_id 1,max_id step] 优点高效性、并发性、可扩展 缺点ID的使用不连续造成资源浪费、号段的分配和更新需要进行协调和管理增加了系统的复杂性和管理成本
Redis实现
在Redis中创建一个计数器通过Redis的原子性操作来生成递增的ID 优点由于Redis是基于内存操作的具有高性能、高并发性、可通过搭建Redis集群来支撑更大规模和高负载的系统 缺点单点故障、需引进Redis组件
雪花算法(SnowFlake)
雪花算法是Sharding-jdbc默认的分布式ID生成算法由64bit的整数组成结构如下图所示可分成4部分
高位随机码毫秒数机器码数据中心机器idIO流水号
第一部分的1bit是符号位0表示是正数1表示负数一般都是0
第二部分41bit是时间戳记录生成ID的时间戳精确到毫秒级。可以有2的41次方种组合可以使用时间大概是59年。
第三部分的10bit是工作节点ID表示在同一毫秒内生成的ID的节点标识。可以分配给不同的节点最多可以有1024个不同的节点。
第四部分的12bit是序列号表示同一毫秒内生成的自增序列号。如果在同一毫秒内生成的ID超过了4096个会等到下一毫秒再继续生成。 优点雪花算法生成的ID是趋势递增不依赖数据库等第三方系统生成ID的效率非常高稳定性好可以根据自身业务特性分配bit位比较灵活。代码简单不占宽带数据迁移不受影响。是全局唯一、自增、有序、纯数字组成查询效率高且不依赖于数据库。适合在分布式的场景中应用可根据需求调整具体实现细节。 缺点雪花算法强依赖机器时钟如果机器上时钟回拨会导致发号重复或者服务会处于不可用状态。如果恰巧回退前生成过一些ID而时间回退后生成的ID就有可能重复。强依赖时钟后台服务器时间一样。依赖于系统时间雪花算法在单机系统上ID是递增的但是在分布式系统多节点的情况下所有节点的时钟改变或者其他情况就有可能会出现不是全局递增的情
美团(Leaf)
Leaf提供两种生成ID的模式分别是号段模式(Leaf-segment)和snowflake模式(Leaf-snowflake
号段模式
美团Leaf的号段模式对上面讲的号段模式做了优化在服务端与数据库之间增加了Leaf中间层由Leaf中间层事先向数据库获取一批ID段缓存起来当服务端需要获取ID时直接从Leaf中间层的内存中获取即可。虽然增加了Leaf中间层解决了数据库压力问题但是当Leaf缓存中的ID用完时就需要向数据库获取新的号段这次请求会显得很耗时为了解决这个问题美团 Leaf 采用了「双 Buffer 预加载」的策略即在内存中维护两个 ID 段并在上一个 ID 段使用达到 10% 的时候去预加载。
Leafsnowflake方案
Leafsnowflake是美团基于SnowFlake雪花算法设计的解决了雪花算法的时钟回拨问题。美团 Leaf 引入了 zookeeper 来解决时钟回拨问题其大致思路为每个 Leaf 运行时定时向 zk 上报时间戳。每次 Leaf 服务启动时先校验本机时间与上次发 ID 的时间再校验与 zk 上所有节点的平均时间戳。如果任何一个阶段有异常那么就启动失败报警。 滴滴TinyID
Tinyid是基于号段模式实现再简单啰嗦一下号段模式的原理就是从数据库批量的获取自增ID每次从数据库取出一个号段范围例如 (1,1000] 代表1000个ID业务服务将号段在本地生成1~1000的自增ID并加载到内存。
Tinyid会将可用号段加载到内存中并在内存中生成ID可用号段在首次获取ID时加载如当前号段使用达到一定比例时系统会异步的去加载下一个可用号段以此保证内存中始终有可用号段以便在发号服务宕机后一段时间内还有可用ID。
