一卓的博客

怕什么真理无穷，
进一寸有一寸的欢喜。

0%

Redis 的 “死键” 问题

发表于 阅读次数： Valine： 4.6k 4 分钟

大规模的数据库存储系统中，数据的生命周期管理是很有必要的；从业务角度发现过期数据，数据归档和数据碎片整理等。以 MySQL 为例，1 个运行很久的 TB 级 MySQL 实例中，极有可能数百 GB 的数据，对业务来说是”过期数据”可直接归档后清理。如果不能发现和及时清理，这部分“过期数据”对生产数据库备份资源消耗，占用工作集数据内存 (过期数据行可能分散 InnoDB 的 page 中)，影响数据还原的 RTO 等。从成本和运维的角度看，代价都是很大的。针对 MySQL 这类”过期数据”问题，通过 MySQL 巡检系统发现问题，使用 MySQL 归档系统备份和删除数据等。

Redis 死键的定义

本文简单聊下 Redis ”死键”的问题，从业务角度对”死键”的 2 个定义:

  • 设置有生存时间 Time to live:TTL 的键，已经过期”死亡”，但因 Redis 主动清理不及时，导致这类键堆积.(这里可能不清晰，后文会详解)
  • 未设置有 TTL 键，使用这批键的程序功能已下线，导致这类键在集群中堆积，无人管理；有的键长达 6 个月访问过一次。

Redis 过期键不能及时清理

Redis 可对键设置生存时间, 当键的生存时间为 0(过期键) 理论就会被删除，并释放占用的数据结构和内存资源。
但 Redis 为保证请求的性能，过期键并不是立即删除的。
这节主要讨论，当产生过期键的速度大于 Redis 删除过期键的速度时，导致过期键堆积的问题。

Redis 删除过期键的策略

Redis 删除过期键有两种策略：passive way 和 active way.

  • passive way(惰性删除):当客户端访问到过期键时，发现它已过期，Redis 会主动删除它
  • active way(定期删除):Redis 会定期调用删除过期键，调用频率由参数 hz 控制，默认每秒调用 10 次

我们重点讨论第二种”定期删除策略”。Redis 每个 database(Cluster 模式下只有 0 号库) 都对应 expire 的 dict，用以保存 Redis 设置有生存时间的键；Redis 每秒调用 10 次 (hz 参数决定) activeExpireCycle 函数；

每次随机获取 20 个带有生存时间的键。
删除其中已过期的键。
如果其中过期键超过 25%(即大于 5 个键是过期的),activeExpireCycle 函数会重新调用，开始第一步 (如果大量 KEY 同时过期，可能引起 Redis 性能抖动)。

Redis 定期删除的速度

Redis 定期删除过期键的速度？ 怎么监控它？

Redis 定期删除动作每秒执行 10 次，正常情况每次删除几个过期键，这样每秒删除过期键约数十个。
通过 info stats 的 expired_keys 指标记录累计删除的过期键数量。根据生产监控 (hz=10)Redis 每秒删除过期键 20~25 个,每天能删除约 200 百万个过期键。有的 Redis 单个实例包含数千万个键，如果业务设计键过期处理不合理，每天产生过期键多于 200 百万。这容易导致 Redis 实例中存在过期键，最坏情况占整个键容量的 25%；也就说 Redis 实例最坏有 1/4 的内存被这类过期的”死键”所占据浪费。

1
2
3
4
5
6
7
8
9
10
11
12
13
Redis 查看过期键删除数量
127.0.0.1:xxx> info stats
# Stats
total_connections_received:33843364
total_commands_processed:211474375292
instantaneous_ops_per_sec:9438
total_net_input_bytes:19661370696457
total_net_output_bytes:34509115216581
expired_keys:7575307675
evicted_keys:0
keyspace_hits:72743876832
keyspace_misses:57604962586
latest_fork_usec:95143

大量过期键堆积，最直接影响是浪费内存空间；另外还会有些”灵异现象”

  • Master 的键个数比 Slave 多 20%
  • 读写分离时，应用程序读取 Slave 时能返回快过期的键
  • Redis scan 或 keys 出来的键个数，远小于 dbsize 返回的个数
  • 高并发情况下，可能出现 performance 抖动,定期删除最坏可占 25%的 CPU 时间片
    这些现象都和过期键的堆积有关。那么我们怎么避免这类过期键堆积呢。

如何避免过期键堆积，成为”死键”

有效避免 Redis 过期键堆积,从两个方面解决: 降低过期键产生的速度；和加快定期删除的速度。

  • 业务设计键的过期时长时，是否考虑过期键生成的速度；能否加大过期键的生存时间。
    如天气缓存集群，大量的键要求 1 分钟过期，从产品需求角度，能否设置更大。
  • 尽量避免使用大实例，控制 Redis 单实例的键个数 (如 1kw)，可有效控制单个实例过期键产生的速度；拆分为更多的分片，加大集群定期删除的速度
  • 适当调大 hz 的值,增大每秒定期删除的次数；建议调整 60，官方建议小 100；
    因调用 serverCron 除了过期删除动作外，还有很多其他操作，可能占用过多的 CPU 时间片，影响业务请求。
    我们测试 hz 从默认 10 调整到 100 时，清理过期键的速度从 20 个升高到 140 个。
  • 主动触发 Redis”惰性删除策略”,通过 scan 命令扫描整个实例的键，Redis 会删除所有已过期的键。
    如果通过业务优化，扩容实例和调整 hz 都不能解决，可考虑定期使用这个大招。

以下是一个 shell, 获取当前服务器，Cluser 的 Master 通过 scan 方式清理过期键

1
2
3
4
5
6
7
local_ip=`ifconfig | grep -Eo 'inet (addr:)?([0-9]*\.){3}[0-9]*' | grep -Eo '([0-9]*\.){3}[0-9]*' | grep -v '127.0.0.1'`
redis-cli -p 6379 cluster nodes | grep "master" | grep "$local_ip" | while read node
do
  node_ins=`echo $node | awk '{print $2}' | cut -f 1 -d ":" `
  node_port=`echo $node | awk '{print $2}' | cut -f 2 -d ":" `
  redis-cli -h $node_ins -p $node_port --scan  >> /dev/null
done

你的 Redis 有堆积过期键吗？

业务低峰期，找个 Redis Master 实例，支持 scan 命令 (QPS 会增长 1w)，查看命令执行前后，dbsize/used_memory 是否有明显下降
redis-cli -h node_ins -p node_port –scan >> /dev/null

应用程序已不使用的键

一个 Redis 集群，分析键空间发现 70%的键，3 个月未访问过。这类键没未设置生存时间，实例也不能设置淘汰机制。
很多应用程序功能已下线，但它使用的 Redis 键往往无人清理或通过 DBA 处理；这样的键从业务角度看，属于无用的”死键”。

获取键的 idletime

每个 Redis 键都有一个 lru 的属性字段，用于记录它最后一次被访问的时间。
而 object idletime 命令，可通过系统当前时间-lru 时间，得到键多久没有被访问的秒数。
说明：object idletime 命令访问键时，不会改变键的 lru 属性，即不会影响键的访问时间

以下示例，键”key:000000008149”已有150039秒未被访问过

1
2
3
4
5
6
7
127.0.0.1:7000> object idletime "key:000000008149"

(integer) 150039

127.0.0.1:7000> object idletime "key:000000008149"

(integer) 150041

获取键空间空闲时间超过指定时间的键

使用Python写个简单程序，scan指定数据库的键空间，打印idletime超过指定时阀值的键。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
#-*- coding:utf8 -*
import redis
import time
//Action: scan 0号数据库的键空间，获取空闲时长大于指定时间的键的列表，达到获取业务死键的作用
//日期: 2016-08-11
TIME_THRESHOLD_SECOND = 2592000  # 获取idletime时长超过TIME_THRESHOLD_SEC秒数键打印. 默认:30天
COUNT = 200  #scan每次返回的键个数,建议不要太大，避免O(n)的n过大出现慢查询. 默认:200个
YEILD_SECOND = 0.05 #每次scan后，sleep 0.05秒；本地测试如果不sleep，此工具会增加约2w的QPS. 避免对高负载的Redis实例产生影响。
            #默认:0.05秒，增长约3500个QPS,其中一个时间复杂度是O(COUNT). 如果实例负载高，key不多可以考虑sleep 0.1秒
def get_key_idletime():
    r = redis.StrictRedis(host='127.0.0.1', port=6380, password="xxxx" ,db=0)
    cursor = '0'
        while cursor != 0:
            cursor, data = r.scan(cursor=cursor, count=COUNT)
            for key in data:
                  key_idletime = r.object("idletime",key)
            if key_idletime > TIME_THRESHOLD_SECOND:
                print key , " ", key_idletime
            time.sleep(YEILD_SECOND)
get_key_idletime()

我们定位Redis的长期未被访问的键，我们怎么确认属于哪个业务功能呢？ 怎么预防业务的“死键”存在？

怎么减少业务”死键”的产生

  • 通过3.1中定期巡检，自动发现1个月未访问过的键，并自动通知业务确认

  • 设置合理的命名空间，我们建议三段式,用”:”分隔。每个集群固定前缀:每个业务功能前缀:实际键名(前缀尽量短，建议2个字节，减少内存消耗)。

    每个团队按大业务功能有多个集群，每个集群有多个小功能模块；这样命空间管理后，集群有任何问题，DBA定位导致问题的”键前缀”，通过集群对接负责的工程师
    很快就定位是哪个功能，什么情况引起的问题。

    1
    2
    | 前缀   | 业务功能       | 存储内容            | 存储规模 | 生存时间 | 预计容量 |
    | ap:1: | 应用商场xxx功能 | 用户安装的appid列表 | x亿      | xx小时   | xxGB    |

  • 给键设置合理的生存时间; 有效避免业务死键发生。比如用户session, 用户最近x小时已安装APP列表等业务场景。有存储性质的集群，也可要求设置合理过期时间，如几个月。通过info Keyspace命令，可查看当前实例有多少键设置有生存时间属性。(另外设置过期时间，每个键多消耗约32Bytes)

可下线的过期键

数据备份
数据清理

原文链接：https://blog.csdn.net/liuxiao723846/article/details/78089577

请作者喝杯咖啡吧