Redis的“死键”问题(转)

转自：https://blog.csdn.net/liuxiao723846/article/details/78089577

大规模的数据库存储系统中，数据的生命周期管理是很有必要的；从业务角度发现过期数据，数据归档和数据碎片整理等。以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的内存被这类过期的”死键”所占据浪费。

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方式清理过期键

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秒未被访问过
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超过指定时阀值的键。

#-*- 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定位导致问题的”键前缀”，通过集群对接负责的工程师
很快就定位是哪个功能，什么情况引起的问题。

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

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