您的位置:首页 > 游戏 > 游戏 > 免费推广网址注册_游戏代理平台官网_需要优化的地方_网站定制的公司

免费推广网址注册_游戏代理平台官网_需要优化的地方_网站定制的公司

2024/12/7 13:18:16 来源:https://blog.csdn.net/qq_39383767/article/details/143643311  浏览:    关键词:免费推广网址注册_游戏代理平台官网_需要优化的地方_网站定制的公司
免费推广网址注册_游戏代理平台官网_需要优化的地方_网站定制的公司

文章目录

  • 本系列
  • 前言
  • UUID
  • DB自增主键
  • Redis incr命令
  • 号段模式
  • 雪花算法

本系列

  • 漫谈分布式唯一ID(本文)
  • 分布式唯一ID生成(二):leaf
  • 分布式唯一ID生成(三):uid-generator
  • 分布式唯一ID生成(四):tinyid

前言

在大多数业务场景中,需要对每条数据分配一个唯一ID作为标识。大部分关系型数据库提供了自增主键功能来支持该需求

但若数据量较大,需要分库分表时,就不能使用每个数据库实例提供的自增键功能,因为不能保证在所有表中唯一,分布式全局唯一ID的需求应运而生

分布式唯一ID有以下功能需求:

  1. 全局唯一性:在某个业务场景下唯一,避免数据冲突,这是最基本的要求
  2. 高性能:生成速度快,不能阻塞业务流程
  3. 趋势递增:通常会将该ID作为数据库主键,由于mysql innoDB采用聚集索引,若新增的记录主键无序,可能造成 叶分裂空间利用率不高 的问题,降低写入性能
  4. 严格单调递增:适用于需要这种特性的场景,例如IM场景中需要根据此生成消息ID,用于给消息排序,并判断是否有消息丢失
  5. 安全性:防止泄露业务信息,若生成的ID严格递增,在电商场景可根据一段时间的id差算出订单量
  6. 方便追踪:例如在ID融入时间戳,就能知道是什么时间范围生成的

上述4,5需求是互斥的,无法同时满足。不同业务场景根据需求选择

还有一些非功能需求:

  1. 高可用:可用性至少5个9

  2. 低延迟:生成速度一定要快,TP50和TP99.9都要非常快,不能因为这个导致业务接口响应变慢

  3. 高并发:假如一下来10w个生成分布式 ID 的请求,要能扛得住

接下来介绍一些常见的分布式ID生成方案


UUID

UUID(Universally unique identifier)一般包含32个十六进制的字符,128位,通过一定的算法计算出来,通常基于时间戳,mac地址,随机数等

优点为:

  • 性能好:本地生成,无网络消耗
  • 唯一性:可以认为不会发生冲突

某些版本基于命名空间能保证唯一性,某些版本基于随机数生成,不保证唯一性,但出现相同UUID的概率非常小,根据百度百科的说法,以java.util.UUID为例,每秒产生10亿笔UUID,100年后只产生一次重复的几率是50%

缺点:

  • 没有趋势递增特性:作为数据库主键时插入性能不高,会导致叶分裂
  • 数据较宽:通常UUID为128bit,不能用mysql的bigint存储,需使用字符串类型,对性能有一定影响
  • 信息不安全:基于mac生成的uuid可能造成mac地址泄露

应用:生成traceId或logId


DB自增主键

以mysql为例,我们可以专门建一张表,利用其自增键来生成唯一ID

表结构如下:

CREATE TABLE unique_id (id bigint(20) unsigned NOT NULL auto_increment, value char(20) NOT NULL default '',PRIMARY KEY (id),UNIQUE KEY unique_v(value) 
) ENGINE=MyISAM;

使用以下sql获取id

begin; 
replace into unique_id (value) VALUES ('placeword'); 
select last_insert_id(); 
commit;

这里 使用replace而不是insert ,是为了保证整个表只有一条记录,因为不需要多余的记录也能生成自增id

这种方式利用数据库的自增主键保证生成id的唯一性,严格单调递增。缺点为:

  1. 性能问题:每次生成id需要一次数据库远程IO,发号器的瓶颈取决于db的读写性能
  2. 可用性问题:只用到一台db实例,存在单点问题,可用性没有保障

针对上面两个问题,可以引入多台mysql:每台实例的表使用不同的初始值

以2台mysql实例为例,分别做如下配置:

mysql1:

set @@auto_increment_offset = 1; -- 起始值 set @@auto_increment_increment = 2; -- 步长

mysql2:

set @@auto_increment_offset = 2; -- 起始值 set @@auto_increment_increment = 2; -- 步长

mysql1从 1 开始发号,mysql2从 2 开始发号,每次发号后递增2
这样mysql1生成的id序列为:

1,3,5,7,9....

mysql2为:

2,4,6,8....

当请求到来时,采用随机或轮询的方式请求这些实例,这样得到的id序列总体为趋势递增,既减少了单台实例的访问压力,也提高了可用性。缺点为:

  1. 从单调递增变为趋势递增
  2. 性能问题: 每次生成ID还是有一次远程数据库IO,对DB的压力还是大
  3. 伸缩性问题:当需要扩展更多的机器时,需要调整之前所有实例的步长,且需要保证再次期间生成ID不冲突,实现起来较麻烦

Redis incr命令

为了解决数据库自增键遇到的性能问题,可以利用 redis的incr 命令来生成不重复的递增ID。该策略相较于数据库方案,优点为:

  1. 从远程磁盘IO变为为远程内存IO性能有一定提升,毕竟redis号称10w qps

但为了保证唯一性需要费一番功夫,依次讨论redis的各种持久化策略:

  • 不开启 redis 持久化,则redis宕机后会丢失已生成的ID,再生成会导致ID重复
  • 开启 RDBAOF 中非AOF_FSYNC_ALWAYS模式的持久化,可能丢失最近一段时间的ID,一样会出现ID重复
  • 开启 AOF 中AOF_FSYNC_ALWAYS模式的持久化,能保证即使在宕机的情况下也不会出现ID重复,但性能会下降,相较于数据库方案没有太大的优势

号段模式

号段模式是为了解决数据库自增主键和redis incr方案中,每次获取ID都需要远程请求的问题

即每次从db获取一个ID范围,作为一个号段加载到内存,这样生成唯一ID时不需要每次都从数据库获取,而是从本地内存里获取,大大提高性能。本地缓存的号段用完时才请求db获取下一批号段

以mysql为例,数据库表结构如下:

CREATE TABLE unique_id ( id bigint(20) NOT NULL, max_id bigint(20) NOT NULL COMMENT '下个号段从哪开始分配', step int(10) NOT NULL COMMENT '一批ID的数量', PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT

每次获取一个号段时,执行如下sql:

update unique_id set max_id = {max_id} + step  where max_id = {max_id} 

当执行成功后判断 affectRows等于1,就能保证只有当前实例获得了 [max_id,max_id + step) 这个区间的号段,就能愉快地在内存发号了

若affectRows不等于1,说明有其他实例获取了这个号段,需要重试再次获取

号段模式的优点如下:

  1. 性能很高:大部分情况下直接在内存发号,无需远程请求,号段范围越大,远程请求的比例越低
  2. 可用性较高:若数据库宕机,可以使用之前获取的号段进行发号,号段范围越大,能撑的时间越久
  3. 趋势递增

缺点如下:

  1. 号段浪费:若某实例在号段没用完时就重启或宕机,则其号段剩余的ID就浪费了。解决方案为较小号段长度,但根据优点中的描述,这会降低性能和可用性,因此需要选择一个适中的号段长度

  2. 不够平滑:当号段用完时,会请求一次数据库,如果此时网络抖动,会使得该次请求响应较慢

    1. 为了解决这种情况,可以在号段即将用完时就异步请求数据库获取下一个号段,而不是等到要用完再请求
  3. 可用性问题:和数据库自增键策略一样的单点问题


如何解决上面提到的可用性问题呢?使用多台实例。这里还是以2台实例为例进行说明:

每次生获取完号段后,将max_id增加 号段长度 * 实例数量

例如初始化时,mysql1.max_id=0,mysql2.max_id=1000。step都是1000

  • 第一次访问mysql1,获取[0:1000)的号段,将mysql1.max_id更新成2000
  • 第二次访问mysql2,获取[1000:2000)的号段,将mysql2.max_id更新成3000
  • 第三次访问mysql1,获取[2000:3000)的号段,将mysql1.max_id更新成4000
  • 第四次访问mysql2,获取[3000:4000)的号段,将mysql2.max_id更新成5000

这样既降低了单台数据库实例的访问压力,又提高了可用性

buffer数量设为多大?峰值qps的600倍,这样db宕机还能提供至少10分钟的服务(容灾性高)


优点:

  1. id位64bit的数字趋势递增
  2. 对db的压力小
  3. 可以很方便线性扩展:按照bizkey分库分表即可
  4. 高可用:内部有缓存,如果数量为峰值qps的600倍,那么db宕机10分钟内都可用
  5. id可以做到几乎单调递增
  6. 可自定义maxId大小,方便原有业务迁移

缺点:

  1. TP999波动大:其他时候查本地缓存,但当号段用完时要查读写一次db
    1. 解决:双buffer,例如当第一个buffer用到10%时就异步请求第二个buffer的号段
  2. id不够随机,泄露发号数量

雪花算法

雪花算法使用一个64位的数字来表示唯一ID,而这64位中的每一位怎么用,就是其精髓所在

标准的雪花算法每一位含义如下:

在这里插入图片描述

  • [0:0] 1位符号位:ID一般为正数,所以该位为0
  • [1:41] 41位时间:通常用来表示 当前时间 - 业务开始时间 的时间差,而不是相对于1970年的时间戳,这样能支持的时间更久,若41位时间戳的单位为毫秒,则能支持大约(1 << 41) / (1000 * 60 * 60 * 24 * 365) = 69年
  • [42:51] 10位机器:一般机器数没那么多,可以将 10位中分5位给机房,分5位给机器。这样就可以表示32个机房,每个机房下可以有32台机器
  • [52:63] 12位自增序列号:表示某台机器上在某一毫秒(如果表示时间的单位为毫秒)内的生成的ID序列号,每毫秒支持1<<12 = 4096个ID,按照 qps算有409.6万

位的分配可以根据业务的不同进行调整,例如若机器数没那么多,不需要10位表示,可增大时间位,以支持更长的时间范围。或者业务并发量不高时,可将时间单位改为秒,将节省出来的位用于表示其他含义

只要每个实例的机器ID不同,则不同机器间生成的ID一定不同,因为其[42:51]位不一样

这样划分后,在一毫秒内一个数据中心的一台机器上可以产生4096个的不重复的ID

其优点为:

  1. 不依赖数据库,性能和可用性非常好
  2. 如果时间戳在高位,能保证ID趋势递增
  3. 理论上支持超高的并发,因为qps有409万,基本不可能有业务的写操作能达到这个qps

缺点为:

  1. ID的生成强依赖于服务器时钟,如果发生时钟回拨,则可能和以前生成过的ID产生冲突

时钟回拨:硬件时钟可能会因为各种原因发生不准的情况,网络中提供了ntp服务来做时间校准,做校准的时候就会发生时钟的跳跃或者回拨的问题

  1. 10位的机器号较难指定,最好不要手工指定,而是实例去自动获取

针对时钟回拨问题,可分两种情况讨论:
  • 实例运行过程中发生时钟回拨:此时可以在内存中 记录上次时间戳,若这次获取的时间戳比上次小,说明发生了时钟回拨,可以等待一段时间再进行ID生成,若回拨幅度较大,则可选择继续等待,或给上层报错,因为在短时间内无法生成正确的ID

也可以完全不依赖系统时间,例如百度的uid-generator使用一个原子变量,每次加一来生成下一个时间

  • 实例重启过程中发生时钟回拨:此时没办法从内存中获取上次的时间戳,因此需要将上次时间戳放到外部存储中。美团leaf的方案为,每3s往zookeeper上报一次当前时间戳,这样在实例重启时,也能判断出是否发生了时钟回拨

但存在外部不能完全避免时钟回拨,例如在t时刻将t保存在zk,在 t+1 时刻分配了一个ID,在 t+2 时刻宕机,时钟回退了1s到t+1,此时检测 t+1 > zk 中的时间t,没问题。但依然会产生 t+1 时刻的重复ID

因此最保险的办法是:宕机后sleep一段时间再重启,这段时间要超过时钟回退的时间


针对机器号生成困难问题:有以下几种解决方案:
  • 使用zookeeper:每次实例启动时,都去zookeeper下创建一个节点,利用其节点编号当做机器id,zookeeper保证每次生成的节点编号唯一

  • 使用mysql:也可以在实例启动时,去数据库的表插入一条记录,利用自增主键当做机器ID,同样能保证机器ID的唯一性

适用场景:订单中,不想让别人根据早上和晚上的订单id号猜到销量的场景

版权声明:

本网仅为发布的内容提供存储空间,不对发表、转载的内容提供任何形式的保证。凡本网注明“来源:XXX网络”的作品,均转载自其它媒体,著作权归作者所有,商业转载请联系作者获得授权,非商业转载请注明出处。

我们尊重并感谢每一位作者,均已注明文章来源和作者。如因作品内容、版权或其它问题,请及时与我们联系,联系邮箱:809451989@qq.com,投稿邮箱:809451989@qq.com