分库分表时用Redis自增实现计数实现分布式id

最新推荐文章于 2025-03-19 07:00:00 发布
原创 最新推荐文章于 2025-03-19 07:00:00 发布 · 3.1k 阅读 · 3 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。

随着用户量增长，原有系统面临性能瓶颈。新建系统中，通过Redis的自增功能来生成不同数据库间的唯一ID，确保了分布式环境下的ID唯一性。在获取ID时，若Redis操作失败，则采取随机数策略作为备用方案。

最近公司项目用户量越来越大，之前的老系统由于设计不合理，已经不能满足目前的需要。现在做了一个新系统，两个系统不同的库，同时在运行。涉及到表id的问题，为了解决这个问题，使用redis来实现分布式id ,具体代码如下：

1，设置一个key实现计数器功能，每取值一次调一次这个方法进行加1操作

public void incr(Integer dbIndex, String key) throws Exception {
    Jedis jedis = null;
    try {
        jedis = jedisPool.getResource();
        if (dbIndex != null) {
            jedis.select(dbIndex);
        }
        jedis.incr(key);
最低0.47元/天 解锁文章
Redis实战：构建分布式计数器
AI天才研究院
02-15 491
1. 背景介绍 1.1 什么是分布式计数器 分布式计数器是一种在分布式系统中实现计数功能的技术。它可以用于跟踪网站访问量、在线用户数、商品销售量等各种计数需求。分布式计数器的核心挑战在于如何在多个节点之间保持计数的一致性，同时保证高可用性和可扩展性。
基于redis秒杀场景的分布式锁实现(包含全局唯一id实现)
m0_65013257的博客
06-11 1242
在介绍秒杀场景之前,我们先来介绍一下全局唯一id的概念 1.1. 自增id的缺陷 - 一张数据库的表存储的空间是有限的,数据量大时,查询的效果也会减慢,**阿里巴巴手册上一个表的数据最好不超过2000万条或者数据容量不超过2GB**,如果采用自增,一张表的数据量日积月累会越来越庞大.有人肯定会说那采用分库分表啊 - 而自增id的这种处理方案,分库分表之后,**每张表的id是不是会重复啊,传入一个id为1的订单,我怎么知道是哪张表的id为1的数据**.所以这种方案并不友好
redis 分布式计数器
weixin_43931625的博客
10-02 1837
redis分布式计数器 使用redis的string类型可以实现分布式计数器 ****************************************************** 使用示例：使用计数器统计对某一路径的访问次数 实现方式：创建计数器，拦截器对指定的路径拦截获取相关参数，使用计数器计数 redis 计数器 @Component publi...
Redis实现分表分库
weixin_47723535的博客
10-27 2899
Redis压力测试 指令：./redis-benchmark -h 127.0.0.1 Redis实现分表分库 Redis数据压力 如果mysql压力不够，使用mycat 如果tomcat压力不够，使用nginx 如果redis内存不够呢？ 这时我们可以使用分表分库。 分库思路 不管数据库还是客户的缓存都找代理(网关) 对Key进行路由（这里是通过Key的长度取模） 把数据存到相应Redis服务器 代码解析 redis默认端口6379，在这里我们增添6380、6381两个端口 package c
redis用法之分库分表维护全局唯一id
qq_45261627的博客
04-03 991
当我们的某张数据库表的数据量可能会非常大的时候，我们应该对其进行分库分表，这时候的id就不能再让数据库对其进行维护了，因为数据库来维护的话，那么这个id将会大范围重复，虽然在某个子表中他是唯一的，但是在逻辑中他是重复的了，所以我们可以通过redis来维护，在redis中维护一个key，每次生成数据的时候都来取值并对其加一，这样就达到了，id全局唯一，不过这样做有个性能瓶颈，那就是这个数据库表的插入可能会非常频繁，所以每次插入一次数据都对其进行redis访问的话，那么redis将会严重浪费资源在这件事上，我们
redis 分布式计数器总结
zhaoyang10的专栏
06-19 3314
Redis实现分布式环境的计数器限流 http://www.gaowm.com/2018/05/11/Redis实现分布式环境的限流/ 利用Redis实现高并发计数器 https://blog.youkuaiyun.com/qq_33556185/article/details/79427271 ...
sharding-jdbc 分库分表后的分布式ID解决方案、取模规则
会飞的小蜗
10-25 2264
文章目录一、分布式自增ID算法---雪花算法 (snowflake，Java版)1、以下是Twitter官方原版的，用Scala写的2、Java版（常用）二、实际项目中的问题1.场景2.方案 一、分布式自增ID算法—雪花算法 (snowflake，Java版) 一般情况，实现全局唯一ID，有三种方案，分别是通过中间件方式、UUID、雪花算法。 方案一，通过中间件方式，可以是把数据库或者redis缓存作为媒介，从中间件获取ID。这种呢，优点是可以体现全局的递增趋势（优点只能想到这个），缺点呢，倒是一大堆，比如
Uuid、数据库自增、雪花算法、基于redis自研等数据库唯一ID生成策略对比
qq_41428035的博客
11-21 3835
Uuid、数据库自增、雪花算法、基于redis自研等数据库唯一ID生成策略对比 使用环境 分布式、高并发下全局唯一，趋势递增，效率高，控制并发 先直接上个对比图吧，下面大量干货警告 一、Uuid（java1.5后自带生成工具类） Uuid是按照开放软件基金会(osf)制定的标准计算用到了以太网开地址(MAC),纳米级时间,芯片id码和许多可能的数字 优点: 使用简单 不依赖其他组件 不影响数据库...
mybatis 的主键自增会适用于分库分表吗
06-25
解决方案：在分库分表架构中，应该使用分布式ID生成算法（如雪花算法）来生成主键，而不是依赖数据库自增。相关问题：1.在MyBatis-Plus中如何配置使用雪花算法生成主键？2.分库分表架构中，除了雪花算法，还有哪些...
Redisson实现分布式计数器
z110123h的博客
04-03 1819
2.调用RMapCache对象的destroy()api后，redis上的数据并未清除，反复验证得出结论：调用destroy()方法后只会删除ConcurrentMap tasks中的任务，避免任务过多产生OOM，redis上的数据并不会清除，调用RMap接口的remove可以达到实时删除redis数据的目的，只调用destory()方法时，redis上的数据将在过期失效后清除。
Redis实现高并发计数器
12-16
业务需求中经常有需要用到计数器的场景：譬如一个手机号一天限制发送5条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。使用Redis的Incr自增命令可以轻松实现以上需求。以一个接口一天限制调用次数为例： /** * 是否拒绝服务 * @return */ private boolean denialOfService(String userId){ long count=JedisUtil.setIncr(DateUtil.getDate()+"&"+userId+"&"+"queryCarViolation", 86400); if(count<=10){
分布式Redis原子操作示例
10-19
分布式Redis原子操作示例，近期项目中遇到分布式项目中多节点大并发操作redis同一个key。此案例利用java调用LUA脚本实现redis操作的原子性。分享出来大家参考。
如何实现Redis里的自增ID计数器
csd753111111的博客
07-24 2848
在关系型数据库MySQL中我们可以通过设置字段属性为AUTO_INCREMENT来实现每增加一条记录自动为其生成一个唯一的递增ID的目的，而Redis中可以通过另一种模式来实现：对于每一类对象使用名为对象类型：count的键...
redis分布式限流，计数器，令牌桶
qq_31443653的博客
03-26 1026
分布式限流方案 计数：简单，双倍临界情况 漏桶：恒定速度，不能应对峰值 令牌桶：允许一定突然，丢掉部分请求有待商榷，令牌桶普遍用得多一些 成熟方案可见，阿里Sentinel：https://sentinelguard.io/zh-cn/docs/basic-implementation.html 令牌桶方案实现 方案一、在提供给业务方的Controller层进行控制。 1、使用guava提供工具库...
分布式唯一ID生成算法——Redis 原子计数器算法
专注分享技术、实用优质教程、资源
03-19 357
分布式唯一ID生成算法——Redis 原子计数器算法全面详解
【限流算法】java实现redis分布式时间窗口计数器算法
DreamSeeker
11-18 3850
本文实现一种基于java的分布式固定时间窗口计数器算法 //每次请求进来，查询一下当前的计数值，如果超出请求数阈值，则拒绝请求，返回系统繁忙提示 private long limitFlow(String key) { //Setnx（SET if Not eXists） 命令在指定的 key 不存在时，为 key 设置指定的值。设置成功返回1，设置失败返回0 ...
如何利用 Redis 实现分布式计数器进阶
Pmyx_wyh的博客
12-02 619
Redis 是一个高性能的键值对数据库，它支持多种数据结构，并且可以用于实现分布式系统中的许多功能，包括分布式计数器。
简单认识redis - 7redis实现分布式
m0_68274160的博客
10-10 1141
假设我们有 3 个 Redis 节点，节点 1（IP: 192.168.1.101）、节点 2（IP: 192.168.1.102）和节点 3（IP: 192.168.1.103）。对于要存储的键 “user:123”，首先计算其哈希值（假设使用 CRC16），得到哈希值为 12345。在实际应用中，需要构建一个中间层来处理数据分片逻辑，使得应用程序不需要关心数据具体存储在哪个节点，这个中间层负责根据分片规则将操作转发到正确的 Redis 节点。
利用秒级时间戳和Redis自增ID 实现分布式全局ID
最新发布
09-05
<think> 我们参考了引用[1]和[2]中的实现方法，利用秒级时间戳和Redis自增ID实现分布式全局ID。核心思想是将64位ID分为两部分：高32位为时间戳（秒级），低32位为Redis自增序列号。 ### 实现步骤 1. **时间戳部分（高32位）**： - 使用当前时间减去一个固定的起始时间（如2022-01-01 00:00:00）的秒数差值，作为时间戳部分。 - 例如：当前时间为2025-01-01 00:00:00，起始时间为2022-01-01 00:00:00，则时间戳差值为94694400秒（3年）。 2. **序列号部分（低32位）**： - 使用Redis的`INCR`命令生成自增序列号。为了确保每天重新开始计数，我们在Redis的key中加入日期（精确到天）。 - 例如：key为`icr:order:20250101`，表示2025年1月1日的订单ID序列。 3. **ID拼接**： - 将时间戳左移32位，然后与序列号进行按位或运算，得到最终的64位ID。 ### 代码实现（基于引用[1][2]优化） ```java @Component public class RedisIdGenerator { // 起始时间戳（2022-01-01 00:00:00 UTC） private static final long BEGIN_TIMESTAMP = 1640995200L; // 序列号占用位数（32位） private static final int COUNT_BITS = 32; private final StringRedisTemplate stringRedisTemplate; public RedisIdGenerator(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate = stringRedisTemplate; } public long nextId(String keyPrefix) { // 1. 生成当前时间戳（秒级） LocalDateTime now = LocalDateTime.now(); long nowSecond = now.toEpochSecond(ZoneOffset.UTC); long timestamp = nowSecond - BEGIN_TIMESTAMP; // 2. 生成序列号（使用日期确保每天重置） String date = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd")); // Redis key格式：icr:{业务前缀}:{日期}，例如 icr:order:2025:01:01 String redisKey = "icr:" + keyPrefix + ":" + date; long sequence = stringRedisTemplate.opsForValue().increment(redisKey); // 3. 拼接ID（时间戳左移32位后与序列号组合） return (timestamp << COUNT_BITS) | sequence; } } ``` ### 关键点解析 1. **时间戳选择**： - 使用秒级时间戳可支持约136年的时间范围（32位最大值为4294967295秒≈136年）[^1]。 - 起始时间`BEGIN_TIMESTAMP`可根据实际业务调整。 2. **Redis序列号管理**： - 序列号按天存储，每天自动重置（例如`icr:order:20250101`），避免序列号溢出问题[^2]。 - 单业务单日理论最大ID数为$2^{32}-1$（约42.9亿），满足绝大多数场景。 3. **并发性能**： - Redis的`INCR`命令是原子操作，确保分布式环境下序列号唯一[^5]。 - 实测性能：单Redis节点可支撑5万+/秒ID生成（引用[5]中200线程并发测试）。 ### 问题解决方案 1. **时间回拨问题**： - 若服务器时间被回调，可能导致ID重复。 - 解决方案：在Redis中记录最后一次生成ID的时间戳，每次生成时校验当前时间是否小于上次记录时间[^2]。示例： ```java String lastTimeKey = "last_timestamp:" + keyPrefix; Long lastTimestamp = stringRedisTemplate.opsForValue().get(lastTimeKey); if (lastTimestamp != null && nowSecond < lastTimestamp) { throw new IllegalStateException("时间回拨异常！"); } stringRedisTemplate.opsForValue().set(lastTimeKey, String.valueOf(nowSecond)); ``` 2. **单日ID超42亿**： - 当单日ID量超过42亿时，序列号会溢出（从0重新开始），导致ID重复。 - 解决方案： - 方案一：缩短时间粒度（如改用小时时间戳），将ID结构改为`28位小时差 + 36位序列号`。 - 方案二：扩展Redis序列号存储（使用`long`类型），并调整位运算为`(timestamp << 36) | (sequence & 0xFFFFFFFFFL)`[^3]。 ### 适用场景与限制 - **推荐场景**： - 电商订单系统（日均ID量<10亿）。 - 用户注册、日志追踪等需要趋势递增ID的业务。 - **不适用场景**： - 超高并发系统（如物联网设备接入，ID需求量>1万/秒），需改用更高性能方案（如雪花算法变体）。 - 严格单调递增场景（Redis序列号每日重置会导致ID不连续）。 > **对比雪花算法**：本方案无需分配workerId，但依赖Redis可用性。若Redis宕机，需启用备用ID生成器（如数据库自增ID）[^4]。 --- ### §§相关问题§§ 1. 如何验证生成的ID在分布式环境下全局唯一？ 2. 时间戳单位改为毫秒后如何避免序列号溢出？ 3. Redis Cluster模式下如何保证自增序列的连续性？ 4. 此方案在高并发场景下如何优化Redis性能？ </think> ### 基于秒级时间戳和Redis自增ID的分布式全局ID实现方案 #### 一、核心实现原理 1. **ID结构设计（64位）**： - **高32位**：秒级时间戳，存储从固定起始时间（如2022-01-01）到当前时间的秒数差值 - **低32位**：Redis生成的序列号，按日期分区确保每日重置 $$ \text{ID} = (\text{timestamp} \ll 32) \mid \text{sequence} $$ 2. **关键特性**： - **趋势递增**：时间戳保证ID随时间单调递增 - **全局唯一**：Redis的`INCR`命令原子性确保序列号不重复 - **每日重置**：序列号key包含日期（如`icr:order:20250101`），避免溢出[^1][^2] #### 二、完整实现代码（Java） ```java @Component public class RedisSecondsIdGenerator { // 起始时间戳（2022-01-01 00:00:00 UTC） private static final long BEGIN_TIMESTAMP = 1640995200L; // 序列号占用位数 private static final int COUNT_BITS = 32; private final StringRedisTemplate stringRedisTemplate; public RedisSecondsIdGenerator(StringRedisTemplate stringRedisTemplate) { this.stringRedisTemplate = stringRedisTemplate; } public long nextId(String businessKey) { // 1. 计算秒级时间戳差值 LocalDateTime now = LocalDateTime.now(); long currentSeconds = now.toEpochSecond(ZoneOffset.UTC); long timestamp = currentSeconds - BEGIN_TIMESTAMP; // 高32位[^1][^2] // 2. 生成日期分区序列号 String dateKey = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd")); String redisKey = "icr:" + businessKey + ":" + dateKey; Long sequence = stringRedisTemplate.opsForValue().increment(redisKey); // 低32位 // 3. 位运算组合ID return (timestamp << COUNT_BITS) | sequence; } } ``` #### 三、核心机制详解 1. **日期分区序列号**： - Redis Key格式：`icr:{业务前缀}:{日期}` - 示例：`icr:order:20250101`（2025年1月1日的订单ID序列） - 优势：天然避免序列号溢出，单日理论上限42亿ID 2. **时间戳处理**： - 使用秒级时间戳（非毫秒），支持更长时间跨度 - 时间范围计算： $$ \text{最大年限} = \frac{2^{32}}{365 \times 24 \times 3600} \approx 136 \text{年} $$ 3. **分布式保障**： - Redis的`INCR`命令是原子操作，多节点并发安全 - 业务键隔离（如`order`, `user`）支持多业务并行[^3] #### 四、关键问题解决方案 1. **时间回拨问题**： ```java // 在Redis存储最后有效时间戳 String lastTimeKey = "last_valid_time:" + businessKey; Long lastTimestamp = stringRedisTemplate.opsForValue().get(lastTimeKey); if (lastTimestamp != null && currentSeconds < Long.parseLong(lastTimestamp)) { throw new TimeReverseException("系统时间回拨异常"); } stringRedisTemplate.opsForValue().set(lastTimeKey, String.valueOf(currentSeconds)); ``` 2. **单日ID超42亿**： - 方案1：缩短时间粒度（改用小时时间戳） ```java // 改为小时分区：yyyy:MM:dd:HH String hourKey = now.format(DateTimeFormatter.ofPattern("yyyy:MM:dd:HH")); ``` - 方案2：扩展序列号位宽（需调整ID结构） ```java // 新结构：28位小时时间戳 + 36位序列号 return (hourTimestamp << 36) | (sequence & 0xFFFFFFFFFL); ``` 3. **Redis高可用**： | 方案 | 实现方式 | 适用场景 | |---------------------|----------------------------|--------------| | Redis Sentinel | 主从自动故障转移 | 高可用场景 | | Redis Cluster | 数据分片存储 | 超大规模系统 | | 多实例分片 | 按业务键哈希到不同实例 | 低成本方案[^5]| #### 五、性能优化建议 1. **连接池配置**： ```yaml # Spring Boot配置 spring.redis.lettuce.pool: max-active: 16 max-idle: 8 min-idle: 4 ``` 2. **批量预生成ID**： ```java // 一次性获取1000个ID public List<Long> batchNextId(String businessKey, int batchSize) { String redisKey = ... // 构建key Long endSeq = stringRedisTemplate.opsForValue() .increment(redisKey, batchSize); List<Long> ids = new ArrayList<>(); for (long seq = endSeq - batchSize + 1; seq <= endSeq; seq++) { ids.add((timestamp << COUNT_BITS) | seq); } return ids; } ``` 3. **本地缓存优化**： - 在应用层缓存100~1000个ID，减少Redis访问频次 - 使用双Buffer机制：一个Buffer消费时，另一个异步填充 > **性能基准**：单Redis节点可达5万+ ID/秒（引用[5]中200线程测试），时延<2ms[^5] --- ###
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值