REDIS 主从架构key过期时间失效问题

活动中用到了Redis来存放用户的奖励票信息，原则上是一天一清，现在设置的是
expireAt(零点)
但是最近运营反馈有部分用户有异常票，经过加log排查后发现指定在零点过期的key并没有准时过期，从库中在0点23秒的时候还能读到数据，程序中用了简单的exists(key) 判断key是否存在，存在就取值。
这么想可能是主库在零点过期了，但是没有及时同步到从库。在网上一看，有用户遇到同样的情况，Redis版本3。2之前的会存在这种情况，然后查看了一下我们的redis版本，发现是3.0 这也就难怪了，应该是遇到一样的情况了；

所以解决方案是在exists(key) 判断的同时加上对key 生存时间ttl的判断，如果ttl是0就不取 了。

实验：
然后我们实测了一下，现在主库设置一个key的过期时间，然后在过期时间前后去读从库，发现直接从从库读取过期key的时候确实会有延迟，5到7秒不等。但是我们读主库，基本无延迟，到点就读不到了。

总结：对于3.2之前的版本Redis会存在主从过期key同步失效的延时

相关链接：https://www.cnblogs.com/bridger/archive/2012/11/07/2758734.html

https://blog.csdn.net/u012538947/article/details/52540313

原文地址：http://blog.51cto.com/fulin0532/2336904

时间： 2024-08-29 13:02:01

REDIS 主从架构key过期时间失效问题的相关文章

10.Redis 主从架构

作者:中华石杉 Redis 主从架构 单机的 redis,能够承载的 QPS 大概就在上万到几万不等.对于缓存来说,一般都是用来支撑读高并发的.因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读.所有的读请求全部走从节点.这样也可以很轻松实现水平扩容,支撑读高并发. redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发 redis replication 的核心机制 red

Redis主从架构

Redis 主从架构 一.简单介绍 单机的 redis,能够承载的 QPS 大概就在上万到几万不等.对于缓存来说,一般都是用来支撑读高并发的.因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读.所有的读请求全部走从节点.这样也可以很轻松实现水平扩容,支撑读高并发. redis replication -> 主从架构 -> 读写分离 -> 水平扩容支撑读高并发 二.redis replication 的核心机制 re

redis 一二事 - 设置过期时间，以文件夹形式展示key显示缓存数据

在使用redis时,有时回存在大量数据的时候,而且分类相同,ID相同 可以使用hset来设置,这样有一个大类和一个小分类和一个value组成 但是hset不能设置过期时间 过期时间只能在set上设置 1 // 向redis中添加缓存 2 jedisClient.set(REDIS_ITEM_KEY + ":" + itemId + ":" + ITEM_KEY, JsonUtils.objectToJson(item)); 3 // 设置key的过期时间 4 jed

redis文档翻译_key设置过期时间

Available since 1.0.0.    使用开始版本1.01 Time complexity: O(1)  时间复杂度O(1) 出处:http://blog.csdn.net/column/details/redisbanli.html Set a timeout on key. After the timeout has expired, the key will automatically be deleted. A key with an associated timeout

redis主从架构宕机问题手动解决

1    主机宕机 1.  设置端口6379是主机,端口6380是从机,全部都正常启动 2.  验证在6379写入数据,在6380也能得到数据 3.  现在将6379主机停掉,模拟主机宕机 4.  由于主机宕机了,现在就要将6380从机设置为主机,使用slaveof no one命令,此时原来的从机变为 主机也用了写的权限 5.  要是原来6379经过修复后,能够正常工作,先将6380主机数据进行保存持久化,将rdb文件,覆盖原主机6379的rdb文件,进行数据的统一. 6.  启动原来的主机6

redis的key过期时间

public void set(String key,String value,int liveTime){ this.set(key, value); this.getJedis().expire(key, liveTime); } 通过设置key的淘汰时间来决定key的存储策略

【高并发架构】Redis缓存高并发之-主从架构

Redis主从架构 到目前为止,Redis Cluster 能实现很好的性能,但如果只是缓存几个G的数据,那么单机Redis就足够了,但缓存主要用来读的,单机的QPS有一定的极限,一两万QPS一台应该没什么问题,但如果是几十万的QPS这类场景呢?Redis主从架构就非常合适. 主从架构主要是保证Redis的高并发性的,对于缓存来说,一般也都是用来支撑读高并发的.因此架构做成主从(master-slave)架构,一主多从,主负责写,并且将数据复制到其它的 slave 节点,从节点负责读.所有的读请

redis集群之主从架构

https://redis.io/topics/replication1. redis主从架构概述(1)一个master可以配置多个slave(2)slave与master之间使用异步复制进行数据同步.(3)redis主从数据同步是非阻塞的. 2. 配置主从master配置: repl-diskless-sync yes # 无磁盘复制,子进程直接叫RDB文件发送给slave repl-diskless-sync-delay 5 # 无盘复制延迟,默认为5s min-slaves-to-writ

Redis Sentinel环境下的Key过期事件消息订阅

一．Redis Sentinel Sentinel是Redis 2.8之后官方发布的HA解决方案,通过Sentinel可以保障整个Redis系统的高可用性.当Redis系统中的Master在异常情况下停止服务后,若干Sentinel会及时察觉并主观判断Master down(Subjectively Down),并且随后由一定数量的Sentinel共同确定Master确实客观已down(Objectively Down),这个时候Sentinel们会选举出一个新的Master继续提供服务.Red