在分布式系统设计中,全局唯一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生成分布式全局唯一id的3种策略的文章就介绍到这了,更多相关redis生成分布式全局唯一id内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
发表评论