Redis+DB实现基于号段的发号器原理以用于区分某些资源

2024-07-01 00:44:39 [百科] 来源：避面尹邢网

Redis+DB实现基于号段的现基发号器原理

作者：竹园李 2023-04-28 10:06:15数据库 Redis 在互联网行业中，为了保证服务的于号稳定性、可用性、发号并发性等指标，器原服务一般是现基采用集群多节点部署，如何保证在这些不同的于号节点生成符合业务要求的ID，又引出另一个概念：分布式ID生成器(实现方案有多种)。发号

什么是器原发号器

在互联网场景中，很多业务要求生成唯一的现基ID号，以用于区分某些资源。于号常见例子：电商系统中的发号订单ID号、聊天群组中的器原消息ID号、上传文件到存储系统中之后生成的现基文件ID号、用户注册系统中的于号用户ID号、商户系统中的发号商户ID号、开放平台中的开发者账号ID、餐饮店的排队进餐号、影剧院票据单号、医院/银行排队号等等，这些基本都是基于先来后到的规则生成，以期达到唯一性或稍显公平的享受某些资源。

Redis+DB实现基于号段的发号器原理以用于区分某些资源

你是否想过使用技术应该如何实现呢？下面引出本文主角：发号器（ticket dispenser），也可称之为ID生成器 (生成的ID号可以是字符串也可以是整数，本文仅探讨生成整数id的发号器实现原理)。

Redis+DB实现基于号段的发号器原理以用于区分某些资源

在互联网行业中，为了保证服务的稳定性、可用性、并发性等指标，服务一般是采用集群多节点部署，如何保证在这些不同的节点生成符合业务要求的ID，又引出另一个概念：分布式ID生成器(实现方案有多种)。关于分布式ID的常见实现方式参考笔者文章：分布式ID的5种生成方式以及Go源码中的一种应用，文章中列举了常见的5种实现方式以及原理。本文，则重点讲解使用Redis+DB基于号段的发号器实现原理。

Redis+DB实现基于号段的发号器原理以用于区分某些资源

实现发号器需要的关注点

需要关注的点大致有以下几个：

- 有序性

正序或倒序，发号器基本都是基于某种纬度的正序排列。还有一些不需要有序性，只要保证唯一性即可。

- 递增性

随着时间的流逝，号码的值只能增大不能变小，即：后面生成的一定大于前面生成的。

- 唯一性

在整个生成的号码值域中，同一个号码有且仅出现一次。

- 先到先得

先申请号码的先获取到，后申请号码的后获取到。

基于号段的发号器实现原理

由上图可知，实现基于号段的发号器逻辑有2个角色：

1. 发号生成器

2. 集中式号段管理器

对于基于号段的发号器来说，发号生成器本身存储一段可用的值域空间，其数据结构一般为：[currId, maxId]，currId为下一个可用id，maxId为当前号段最大id。每当有号码申请到达后，发号器先判断是否有可用号码。

若currId<=maxId则存在可用id，把currId返回给申请方，然后currId+=1。

若currId>maxId，说明该号段被消耗殆尽。此时，发号器需要申请新的号段值域空间。即：申请新的maxId，一般使用步长的方式，发号器每次申请新的值域空间，会得到长度固定的新值域空间 (判断发号生成器是否存在可用号码，一般有2种写法，只是处理边界条件不一样，这里以currId<=maxId视为有可用号码)。

通常情况下，发号生成器分为进程内发号生成器与进程外发号生成器。即：在进程内部维护[currId, maxId]值域空间还是在进程外部维护[currId, maxId]值域空间。进程内部可以通过全局变量+进程内部锁(或原子操作)的方式实现，进程外部通过其他中间件(Redis or DB)或服务来实现。

进程内发号生成器与进程外发号生成器的使用场景也有很大不同之处，服务一般存在多个节点，每个节点都存在一个业务进程。若对全部请求都要保证先来后到严格的时序性，则需要使用唯一的进程外发号生成器。若不用保证先来后到严格的时序性，则进程内发号生成器与进程外发号生成器都可以使用，考虑性能优先选择进程内发号生成器。

Redis+DB实现基于号段的发号器