一些keyspace过期的事件没有被触发(Redis)

ikfrs5lh  于 12个月前  发布在  Redis
关注(0)|答案(1)|浏览(133)

我在AWS ElastiCache中有一个Redis,激活了键空间通知(Kx)。
我的问题是,有时当密钥过期时,过期事件不会被触发。我正在监视密钥TTL,我实际上正在使用redis-cli观察它过期,但没有触发事件(即过期的密钥永远不会出现在psubscribe __keyspace@*__:*中)。更奇怪的是,如果我用新的过期时间再次设置完全相同的密钥,事件被触发。它几乎看起来像是如果它是随机的,当关键事件被触发或不是第一次。但第二次尝试它总是触发。
我尝试了不同的TTL之间的1和60秒,但没有区别。
我真的不知道我错过了什么。
节点类型是cache.t3.medium。下面是INFO命令的结果:

# Server
redis_version:5.0.6
redis_git_sha1:0
redis_git_dirty:0
redis_build_id:0
redis_mode:standalone
os:Amazon ElastiCache
arch_bits:64
multiplexing_api:epoll
atomicvar_api:atomic-builtin
gcc_version:0.0.0
process_id:1
run_id:29bd78297b28d1e4cd37a3bf51129f87eb6a9bd2
tcp_port:6379
uptime_in_seconds:734256
uptime_in_days:8
hz:10
configured_hz:10
lru_clock:15501077
executable:-
config_file:-

# Clients
connected_clients:50
client_recent_max_input_buffer:2
client_recent_max_output_buffer:0
blocked_clients:0

# Memory
used_memory:1383823976
used_memory_human:1.29G
used_memory_rss:1392582656
used_memory_rss_human:1.30G
used_memory_peak:2493376432
used_memory_peak_human:2.32G
used_memory_peak_perc:55.50%
used_memory_overhead:30088284
used_memory_startup:4263632
used_memory_dataset:1353735692
used_memory_dataset_perc:98.13%
allocator_allocated:1384415096
allocator_active:1393147904
allocator_resident:1419923456
used_memory_lua:45056
used_memory_lua_human:44.00K
used_memory_scripts:512
used_memory_scripts_human:512B
number_of_cached_scripts:2
maxmemory:2488396677
maxmemory_human:2.32G
maxmemory_policy:volatile-lru
allocator_frag_ratio:1.01
allocator_frag_bytes:8732808
allocator_rss_ratio:1.02
allocator_rss_bytes:26775552
rss_overhead_ratio:0.98
rss_overhead_bytes:-27340800
mem_fragmentation_ratio:1.01
mem_fragmentation_bytes:8759592
mem_not_counted_for_evict:0
mem_replication_backlog:0
mem_clients_slaves:0
mem_clients_normal:922044
mem_aof_buffer:0
mem_allocator:jemalloc-5.1.0
active_defrag_running:0
lazyfree_pending_objects:0

# Persistence
loading:0
rdb_changes_since_last_save:5525184
rdb_bgsave_in_progress:0
rdb_last_save_time:1625379557
rdb_last_bgsave_status:ok
rdb_last_bgsave_time_sec:-1
rdb_current_bgsave_time_sec:-1
rdb_last_cow_size:0
aof_enabled:0
aof_rewrite_in_progress:0
aof_rewrite_scheduled:0
aof_last_rewrite_time_sec:-1
aof_current_rewrite_time_sec:-1
aof_last_bgrewrite_status:ok
aof_last_write_status:ok
aof_last_cow_size:0

# Stats
total_connections_received:76780
total_commands_processed:9953299
instantaneous_ops_per_sec:20
total_net_input_bytes:3135151221
total_net_output_bytes:9973695547
instantaneous_input_kbps:2.58
instantaneous_output_kbps:12.09
rejected_connections:0
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:1811958
expired_stale_perc:1.86
expired_time_cap_reached_count:0
evicted_keys:107069
keyspace_hits:1694960
keyspace_misses:532376
pubsub_channels:0
pubsub_patterns:4
latest_fork_usec:0
migrate_cached_sockets:0
slave_expires_tracked_keys:0
active_defrag_hits:0
active_defrag_misses:0
active_defrag_key_hits:0
active_defrag_key_misses:0

# CPU
used_cpu_sys:519.375822
used_cpu_user:2115.832520
used_cpu_sys_children:0.000000
used_cpu_user_children:0.000000

# SSL
ssl_enabled:no
ssl_connections_to_previous_certificate:0
ssl_connections_to_current_certificate:0
ssl_current_certificate_not_before_date:(null)
ssl_current_certificate_not_after_date:(null)
ssl_current_certificate_serial:0

# Cluster
cluster_enabled:0

# Keyspace
db0:keys=325773,expires=125691,avg_ttl=32887832

字符串
谢谢

**UPDATE:**执行一个keys *命令,本来会检索到缺失过期事件的密钥,触发缺失的事件。我们仍然不知道为什么这是一个行为。

11dmarpk

11dmarpk1#

经过很长一段时间后,我们得出结论,当Redis中有TTL的密钥数量很高,并且它们的TTL的方差和平均值也很高时,就会发生这种情况。我们的分布主要由未来很长时间(有时甚至是几个月)过期的密钥组成。而且,我们也有一小部分密钥(< 5%)的TTL小于1分钟。
在我们的情况下,这种行为可以通过redis如何过期密钥来解释。我引用:
具体来说,这是Redis每秒做10次的事情:
1.从密钥集合中随机测试20个密钥,并具有相关的过期时间。
1.删除所有发现过期的密钥。
1.如果超过25%的密钥过期,请从步骤1重新开始。
这是一个平凡的概率算法,基本上假设我们的样本代表了整个密钥空间,我们继续过期,直到可能过期的密钥的百分比低于25%
后一个假设并不适用于我们的TTL发行版,所以我们得出结论,Redis并不适合我们的用例。
此外,在本文档中,他们解释了当客户端试图访问密钥时,密钥也会过期。这解释了为什么强制访问所有密钥(keys *)会触发它们的过期。

相关问题