基于Redis的3种分布式ID生成策略
mhr18 2025-08-02 19:36 1 浏览 0 评论
在分布式系统设计中,全局唯一ID是一个基础而关键的组件。随着业务规模扩大和系统架构向微服务演进,传统的单机自增ID已无法满足需求。高并发、高可用的分布式ID生成方案成为构建可靠分布式系统的必要条件。
Redis具备高性能、原子操作及简单易用的特性,因此我们可以基于Redis实现全局唯一ID的生成。
分布式ID的核心需求
一个优秀的分布式ID生成方案应满足以下要求
- 全局唯一性:在整个分布式系统中保证ID不重复
- 高性能:能够快速生成ID,支持高并发场景
- 高可用:避免单点故障,确保服务持续可用
- 趋势递增:生成的ID大致呈递增趋势,便于数据库索引和分片
- 安全性(可选) :不包含敏感信息,不易被推测和伪造
1. 基于INCR命令的简单自增ID
原理
这是最直接的Redis分布式ID实现方式,利用Redis的INCR命令原子性递增一个计数器,确保在分布式环境下ID的唯一性。
代码实现
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.stereotype.Component;
@Component
public class RedisSimpleIdGenerator {
private final RedisTemplate<String, String> redisTemplate;
private final String ID_KEY;
public RedisSimpleIdGenerator(RedisTemplate<String, String> redisTemplate) {
this.redisTemplate = redisTemplate;
this.ID_KEY = "distributed:id:generator";
}
/**
* 生成下一个ID
* @return 唯一ID
*/
public long nextId() {
Long id = redisTemplate.opsForValue().increment(ID_KEY);
if (id == null) {
throw new RuntimeException("Failed to generate id");
}
return id;
}
/**
* 为指定业务生成ID
* @param bizTag 业务标签
* @return 唯一ID
*/
public long nextId(String bizTag) {
String key = ID_KEY + ":" + bizTag;
Long id = redisTemplate.opsForValue().increment(key);
if (id == null) {
throw new RuntimeException("Failed to generate id for " + bizTag);
}
return id;
}
/**
* 获取当前ID值但不递增
* @param bizTag 业务标签
* @return 当前ID值
*/
public long currentId(String bizTag) {
String key = ID_KEY + ":" + bizTag;
String value = redisTemplate.opsForValue().get(key);
return value != null ? Long.parseLong(value) : 0;
}
}
优缺点
优点
- 实现极其简单,仅需一次Redis操作
- ID严格递增,适合作为数据库主键
- 支持多业务ID隔离
缺点
- Redis单点故障会导致ID生成服务不可用
- 主从切换可能导致ID重复
- 无法包含业务含义
适用场景
- 中小规模系统的自增主键生成
- 对ID连续性有要求的业务场景
- 单数据中心部署的应用
2. 基于Lua脚本的批量ID生成
原理
通过Lua脚本一次性获取一批ID,减少网络往返次数,客户端可在内存中顺序分配ID,显著提高性能。
代码实现
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import org.springframework.stereotype.Component;
import java.util.Collections;
import java.util.List;
import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@Component
public class RedisBatchIdGenerator {
private final RedisTemplate<String, String> redisTemplate;
private final String ID_KEY = "distributed:batch:id";
private final DefaultRedisScript<Long> batchIncrScript;
// 批量获取的大小
private final int BATCH_SIZE = 1000;
// 本地计数器和锁
private AtomicLong currentId = new AtomicLong(0);
private AtomicLong endId = new AtomicLong(0);
private final Lock lock = new ReentrantLock();
public RedisBatchIdGenerator(RedisTemplate<String, String> redisTemplate) {
this.redisTemplate = redisTemplate;
// 创建Lua脚本
String scriptText =
"local key = KEYS[1] " +
"local step = tonumber(ARGV[1]) " +
"local currentValue = redis.call('incrby', key, step) " +
"return currentValue";
this.batchIncrScript = new DefaultRedisScript<>();
this.batchIncrScript.setScriptText(scriptText);
this.batchIncrScript.setResultType(Long.class);
}
/**
* 获取下一个ID
*/
public long nextId() {
// 如果当前ID超过了分配范围,则重新获取一批
if (currentId.get() >= endId.get()) {
lock.lock();
try {
// 双重检查,防止多线程重复获取
if (currentId.get() >= endId.get()) {
// 执行Lua脚本获取一批ID
Long newEndId = redisTemplate.execute(
batchIncrScript,
Collections.singletonList(ID_KEY),
String.valueOf(BATCH_SIZE)
);
if (newEndId == null) {
throw new RuntimeException("Failed to generate batch ids");
}
// 设置新的ID范围
endId.set(newEndId);
currentId.set(newEndId - BATCH_SIZE);
}
} finally {
lock.unlock();
}
}
// 分配下一个ID
return currentId.incrementAndGet();
}
/**
* 为指定业务生成ID
*/
public long nextId(String bizTag) {
// 实际项目中应该为每个业务标签维护独立的计数器和范围
// 这里简化处理,仅使用不同的Redis key
String key = ID_KEY + ":" + bizTag;
Long newEndId = redisTemplate.execute(
batchIncrScript,
Collections.singletonList(key),
String.valueOf(1)
);
return newEndId != null ? newEndId : -1;
}
}
优缺点
优点
- 显著减少Redis网络请求次数
- 客户端缓存ID段,大幅提高性能
- 降低Redis服务器压力
- 支持突发流量处理
缺点
- 实现复杂度增加
- 服务重启可能导致ID段浪费
适用场景
- 高并发系统,需要极高ID生成性能的场景
- 对ID连续性要求不严格的业务
- 能容忍小部分ID浪费的场景
3. 基于Redis的分段式ID分配(号段模式)
原理
号段模式是一种优化的批量ID生成方案,通过预分配号段(ID范围)减少服务间竞争,同时引入双Buffer机制提高可用性。
代码实现
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.data.redis.core.script.DefaultRedisScript;
import org.springframework.stereotype.Component;
import java.util.Collections;
import java.util.Map;
import java.util.concurrent.ConcurrentHashMap;
import java.util.concurrent.atomic.AtomicLong;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
@Component
public class RedisSegmentIdGenerator {
private final RedisTemplate<String, String> redisTemplate;
private final String SEGMENT_KEY = "distributed:segment:id";
private final DefaultRedisScript<Long> segmentScript;
// 号段大小
private final int SEGMENT_STEP = 1000;
// 加载因子,当前号段使用到这个百分比时就异步加载下一个号段
private final double LOAD_FACTOR = 0.7;
// 存储业务号段信息的Map
private final Map<String, SegmentBuffer> businessSegmentMap = new ConcurrentHashMap<>();
public RedisSegmentIdGenerator(RedisTemplate<String, String> redisTemplate) {
this.redisTemplate = redisTemplate;
// 创建Lua脚本
String scriptText =
"local key = KEYS[1] " +
"local step = tonumber(ARGV[1]) " +
"local value = redis.call('incrby', key, step) " +
"return value";
this.segmentScript = new DefaultRedisScript<>();
this.segmentScript.setScriptText(scriptText);
this.segmentScript.setResultType(Long.class);
}
/**
* 获取下一个ID
* @param bizTag 业务标签
* @return 唯一ID
*/
public long nextId(String bizTag) {
// 获取或创建号段缓冲区
SegmentBuffer buffer = businessSegmentMap.computeIfAbsent(
bizTag, k -> new SegmentBuffer(bizTag));
return buffer.nextId();
}
/**
* 内部号段缓冲区类,实现双Buffer机制
*/
private class SegmentBuffer {
private String bizTag;
private Segment[] segments = new Segment[2]; // 双Buffer
private volatile int currentPos = 0; // 当前使用的segment位置
private Lock lock = new ReentrantLock();
private volatile boolean isLoadingNext = false; // 是否正在异步加载下一个号段
public SegmentBuffer(String bizTag) {
this.bizTag = bizTag;
segments[0] = new Segment(0, 0);
segments[1] = new Segment(0, 0);
}
/**
* 获取下一个ID
*/
public long nextId() {
// 获取当前号段
Segment segment = segments[currentPos];
// 如果当前号段为空或已用完,切换到另一个号段
if (!segment.isInitialized() || segment.getValue() > segment.getMax()) {
lock.lock();
try {
// 双重检查当前号段状态
segment = segments[currentPos];
if (!segment.isInitialized() || segment.getValue() > segment.getMax()) {
// 切换到另一个号段
currentPos = (currentPos + 1) % 2;
segment = segments[currentPos];
// 如果另一个号段也未初始化或已用完,则同步加载
if (!segment.isInitialized() || segment.getValue() > segment.getMax()) {
loadSegmentFromRedis(segment);
}
}
} finally {
lock.unlock();
}
}
// 检查是否需要异步加载下一个号段
long value = segment.incrementAndGet();
if (value > segment.getMin() + (segment.getMax() - segment.getMin()) * LOAD_FACTOR
&& !isLoadingNext) {
isLoadingNext = true;
// 异步加载下一个号段
new Thread(() -> {
Segment nextSegment = segments[(currentPos + 1) % 2];
loadSegmentFromRedis(nextSegment);
isLoadingNext = false;
}).start();
}
return value;
}
/**
* 从Redis加载号段
*/
private void loadSegmentFromRedis(Segment segment) {
String key = SEGMENT_KEY + ":" + bizTag;
// 执行Lua脚本获取号段最大值
Long max = redisTemplate.execute(
segmentScript,
Collections.singletonList(key),
String.valueOf(SEGMENT_STEP)
);
if (max == null) {
throw new RuntimeException("Failed to load segment from Redis");
}
// 设置号段范围
long min = max - SEGMENT_STEP + 1;
segment.setMax(max);
segment.setMin(min);
segment.setValue(min - 1); // 设置为min-1,第一次incrementAndGet返回min
segment.setInitialized(true);
}
}
/**
* 内部号段类,存储号段的范围信息
*/
private class Segment {
private long min; // 最小值
private long max; // 最大值
private AtomicLong value; // 当前值
private volatile boolean initialized; // 是否已初始化
public Segment(long min, long max) {
this.min = min;
this.max = max;
this.value = new AtomicLong(min);
this.initialized = false;
}
public long getValue() {
return value.get();
}
public void setValue(long value) {
this.value.set(value);
}
public long incrementAndGet() {
return value.incrementAndGet();
}
public long getMin() {
return min;
}
public void setMin(long min) {
this.min = min;
}
public long getMax() {
return max;
}
public void setMax(long max) {
this.max = max;
}
public boolean isInitialized() {
return initialized;
}
public void setInitialized(boolean initialized) {
this.initialized = initialized;
}
}
}
优缺点
优点
- 双Buffer设计,高可用性
- 异步加载下一个号段,性能更高
- 大幅降低Redis访问频率
- 即使Redis短暂不可用,仍可分配一段时间的ID
缺点
- 实现复杂,代码量大
- 多实例部署时,各实例获取的号段不连续
- 重启服务时号段内的ID可能浪费
- 需要在内存中维护状态
适用场景
- 对ID生成可用性要求高的业务
- 需要高性能且多服务器部署的分布式系统
4. 性能对比与选型建议
策略 | 性能 | 可用性 | ID长度 | 实现复杂度 | 单调递增 |
INCR命令 | ★★★☆☆ | ★★☆☆☆ | 递增整数 | 低 | 严格递增 |
Lua批量生成 | ★★★★★ | ★★★☆☆ | 递增整数 | 中 | 批次内递增 |
分段式ID | ★★★★★ | ★★★★☆ | 递增整数 | 高 | 段内递增 |
5. 实践优化技巧
1. Redis高可用配置
// 配置Redis哨兵模式,提高可用性
@Bean
public RedisConnectionFactory redisConnectionFactory() {
RedisSentinelConfiguration sentinelConfig = new RedisSentinelConfiguration()
.master("mymaster")
.sentinel("127.0.0.1", 26379)
.sentinel("127.0.0.1", 26380)
.sentinel("127.0.0.1", 26381);
return new LettuceConnectionFactory(sentinelConfig);
}
2. ID预热策略
// 系统启动时预热ID生成器
@PostConstruct
public void preWarmIdGenerator() {
// 预先获取一批ID,确保系统启动后立即可用
for (int i = 0; i < 10; i++) {
try {
segmentIdGenerator.nextId("order");
segmentIdGenerator.nextId("user");
segmentIdGenerator.nextId("payment");
} catch (Exception e) {
log.error("Failed to pre-warm ID generator", e);
}
}
}
3. 降级策略
// Redis不可用时的降级策略
public long nextIdWithFallback(String bizTag) {
try {
return segmentIdGenerator.nextId(bizTag);
} catch (Exception e) {
log.warn("Failed to get ID from Redis, using local fallback", e);
// 使用本地UUID或其他替代方案
return Math.abs(UUID.randomUUID().getMostSignificantBits());
}
}
6. 结论
选择合适的分布式ID生成策略时,需要综合考虑系统规模、性能需求、可靠性要求和实现复杂度。无论选择哪种方案,都应注重高可用性设计,增加监控和预警机制,确保ID生成服务的稳定运行。
在实践中,可以基于业务需求对这些方案进行组合和优化,例如为不同业务选择不同策略,或者在ID中嵌入业务标识等,打造更适合自身系统的分布式ID生成解决方案。
- 上一篇:Redis缓存降级的4种策略
- 下一篇:深入探讨常用的分布式 ID 生成算法
相关推荐
- 外贸独立站卡成PPT?你可能用错了对象缓存!
-
最近帮一个上海的电子元器件客户优化网站,发现他的WooCommerce后台操作要等5秒才能响应——查了下服务器日志,MySQL查询每秒炸出200+次!原来他的"高性能"主机根本没用对象...
- 搭建N8N
-
一、概述n8n是一款强大的工作流自动化工具,它允许用户通过可视化界面创建自动化工作流,无需编写复杂代码。作为一个开源的自动化平台,N8N支持连接各种服务和应用程序,实现数据流转和任务自动化。核心特点...
- 性能优化!7个策略,让Spring Boot 处理每秒百万请求
-
首先,我需要确定这个问题的背景。可能用户是在处理高并发的系统,或者正在设计一个需要应对大流量的应用。他们的身份可能是后端开发工程师,或者是系统架构师,对性能优化有较高需求。接下来,我要想,处理百万级的...
- 定时任务优化总结(从半个小时优化到秒级)
-
整体优化思路:1.按需查询、2.分小批次游标查询、3.JED场景下按数据库分片分组更新、4.精准定位要处理的数据、5.负载均衡业务背景:站外广告投放平台在做推广管理状态优化重构的时候,引入了...
- 跨境电商建站隐藏技巧:Redis缓存,让站点“记住”用户更高效
-
用户登录后,每次刷新页面都要重新验证身份,有时候还会出现“会话丢失”,用户不得不重新登录,体验很差找我们帮忙后,我们建议用Redis缓存会话数据。简单来说,Redis就像站点的“临时记事本”,用户登...
- 服务架构性能优化与Java实现
-
服务架构性能优化大全(附Java代码实现)一、缓存核心思想:将高频访问数据存储在高速存储中,减少慢速存储(如数据库)访问场景:读多写少的数据(用户信息、配置数据)Java实现:使用Caffeine缓存...
- 百万并发不是梦!Nginx高并发优化配置与性能调优全解
-
Nginx的最大转发能力受硬件、配置和系统参数影响,处理超高并发请求时需多维度优化和扩展。以下是具体分析和解决方案:一、Nginx最大转发能力的关键因素硬件资源CPU:Nginx依赖多核CPU,...
- 面试官:工作中优化MySQL的手段有哪些?
-
MySQL是面试中必问的模块,而MySQL中的优化内容又是常见的面试题,所以本文来看“工作中优化MySQL的手段有哪些?”。工作中常见的MySQL优化手段分为以下五大类:索引优化:确保高频查...
- 万字长文|RAG优化全攻略:微服务部署+动态权重策略,代码级详解
-
本文较长,建议点赞收藏,以免遗失。更多AI大模型应用开发学习视频及资料,尽在官网-聚客AI学院大模型应用开发微调项目实践课程学习平台从理论到实践,全面解析RAG性能瓶颈与高阶优化方案。一、RAG核心架...
- 在Windows环境下,本地部署和启动开源项目Ragflow的源代码
-
在当前AI领域中,基于检索增强生成(RAG)的应用备受关注,而开源项目RAGFlow因其灵活性和功能性成为了一个热门选择。不过,由于其快速的版本迭代,可能会存在一些Bug,并且在实际项目落地时通常需要...
- 这款 .NET 9 + React 后台权限管理系统太强了!支持多租户、按钮权限(简单易用且文档齐全)
-
前言在数字化转型浪潮中,高效且安全的权限管理是后台系统的核心基石。传统方案或依赖臃肿的三方框架,或难以满足细粒度权限需求。今天推荐一款完全独立开发、基于前沿技术栈开发的RBAC权限系统。它摒弃了现成A...
- 开源声明:只是一个随便写写的管理系统(认真脸)
-
最近微信公众号和技术博客都断更了,最近2了两周时间撸了一套管理系统的脚手架。原因是因为最近项目需要用到,但是找了一圈Github或者Gitee,基本都不合适。要么有前端,配套后端是Node而...
- 「第七期」深信服go实习一面二面HR面
-
一面面试时长:1h自我介绍channel知识点协程goroutinemysql的两种存储引擎InnoDB索引redis使用单线程还是多线程?有多少个库?redis持久化有哪些?各自优势?谁更常用?P...
- Go中使用sync.Map实现线程安全的缓存
-
不依赖外部库,在Go中实现自己的线程安全缓存照片来源:PossessedPhotography在Unsplash缓存是优化现代应用程序性能的关键方面。它允许您存储并快速检索昂贵操作的结果或经常访...
- Redis中RedisTemplate 和 StringRedisTemplate
-
前言:RedisTemplate和StringRedisTemplate都是Spring提供的操作Redis的模板类,但它们之间在序列化方式和使用场景上有显著区别。序列化方式不同Redi...
你 发表评论:
欢迎- 一周热门
- 最近发表
- 标签列表
-
- oracle位图索引 (74)
- oracle批量插入数据 (65)
- oracle事务隔离级别 (59)
- oracle主从同步 (56)
- oracle 乐观锁 (53)
- redis 命令 (83)
- php redis (97)
- redis 存储 (67)
- redis 锁 (74)
- 启动 redis (73)
- redis 时间 (60)
- redis 删除 (69)
- redis内存 (64)
- redis并发 (53)
- redis 主从 (71)
- redis同步 (53)
- redis结构 (53)
- redis 订阅 (54)
- redis 登录 (62)
- redis 面试 (58)
- redis问题 (54)
- 阿里 redis (67)
- redis的缓存 (57)
- lua redis (59)
- redis 连接池 (64)