开篇
本来这篇文章要在年前发的，结果一直拖到年后才完成实在是惭愧。
背景：马上要过年了，但是通过zabbix监控的Redis内存占用，发现公司线上Redis的内存一直在快速增长，并且不做处理的话，会在放假期间出现内存占用过半，可能影响春节期间的正常服务。
为了预防以上问题，我和同事开始了Redis内存分析和清理的慢慢长路。。。。。。
内存分析
Redis的内存快速增长一般只有两种原因，不正确的使用Redis和业务快速增长。为了确定内存增长的真实原因，首先要做的就是Redis的Key键分析：
监控
在要解决问题之前，要先找到问题的根源。Redis作为公司的公共服务，多个部门在同时使用，首先要确定是那个部门使用的库出现了问题。我们在一周时间里，每日统计Redis的KeySpace来分析各个库的增长情况
通过一周的统计，我们发现5号库一直在持续增长，那增长的原因是什么呢？接下来就要做5号库Key键的全库分析
Key键分布
为了方便分析且不影响线上Redis提供服务，我们通过运维部门获得了线上Redis的RDB快照（为了数据安全，你要发各种邮件。。。。）。
到了这里，向大家推荐一个工具rdbtools，rdbtools可以分析Redis的RDB文件，提供详细的内存使用分析报告
我们使用的是15天免费版，并且免费版最多只能分析500M的RDB文件.
因为，我本机rdbtools莫名没法启动了，在这里就不给大家展示了。主要是通过rdbtools分析rdb文件，rdbtools会提供各个库的key值的数量和占用内存的大小。分析后得到5号库占用内存最大，符合监控时期的现象。然后我们在本地将5号库以外的所有库清空，并保存快照，再次分析（免费版只能分析500M，所以为了分析的更准确，清空了其他库）。rdbtools还提供了key键的自动分类，将相似key键分成一类，例如key:tc:2018-10-10 这种会自动归类到 key:tc:* 帮助我们更好的分析key
在通过rdbtools帮助下，我们发现了两类大key，库中一共1千万的key 这两类key就有800多万，在和使用5号库的部门沟通反馈后，得知这两类key都是无效且可以清理的，并且他们会重新上线，避免新的垃圾key的产生。接下来就是key键清理了。
Key键删除
在分析得到两类Key是内存占用最大的源头后，我们开始着手处理这些key。首先在本地将这两类总计800万的key导出到文本中。使用以下命令：
redis-cli -n 5 keys "test_tc_*" >/Users/lingyun/Desktop/test-tc-keys.txt
命令执行速度很快，几秒就完成了，我们会得到两个文本文件，在线上会用到这两个文件。
将两类Key导出后，我们在本地使用命令删除这两类key，评估可释放空间。在删除之前一定要关闭本地的AOF和RDB，否则删除过程会非常漫长，并且占用内存。
关闭AOF和RDB
关闭rdb的命令：config set save ""
关闭aof的命令：config set appendfsync no
删除
redis-cli keys "test_tc_*" | xargs redis-cli -n 5 del
在执行完以后，我们再次通过info查看内存占用，发现释放了3G以上的空间，说明我们的思路是对的，接下来就是写java代码，在线上清理这key
Java代码
package com.tcredit.clean;
import com.google.common.base.Strings;
import lombok.extern.slf4j.Slf4j;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.core.io.ClassPathResource;
import org.springframework.core.io.Resource;
import org.springframework.data.redis.core.RedisTemplate;
import org.springframework.scheduling.annotation.Scheduled;
import org.springframework.stereotype.Component;
import java.io.BufferedReader;
import java.io.IOException;
import java.io.InputStreamReader;
import java.util.ArrayList;
import java.util.List;
/**
* Redis清理任务
*
* @author Lingyun
* @Date 2019-01-07 11:11
*/
@Slf4j
@Component
public class CleanTask {
@Autowired
RedisTemplate redisTemplate;
@Scheduled(cron = "0 35 16 9 1 ?")
public void taskCleanRedis() {
log.info("Redis-Clean Start！");
action();
log.info("Redis-Clean Finish！");
}
private void action() {
Resource resource = new ClassPathResource("keys.txt");
BufferedReader br = null;
try {
br = new BufferedReader(new InputStreamReader(resource.getInputStream()));
String key = null;
List rKeys = new ArrayList<>();
int num = 0;
int total = 0;
while ((key = br.readLine()) != null) {
key = key.trim();
if (Strings.isNullOrEmpty(key)) {
continue;
}
rKeys.add(key);
num++;
total++;
// 每秒删除40个key
if (num >= 120) {
log.info(String.format("Redis-Clean 最后一个Key: %s , 当前删除：%s ", key, total));
deleteKeys(rKeys);
num = 0;
}
}
} catch (Exception e) {
log.error("Redis-Clean Error", e);
} finally {
try {
if (br != null) {
br.close();
}
} catch (IOException e) {
log.error("Redis-Clean Error", e);
}
}
}
private void deleteKeys(List keys) throws Exception {
try {
redisTemplate.delete(keys);
keys.clear();
Thread.sleep(1000);
} catch (Exception e) {
log.error("Redis-Clean Error:", e);
Thread.sleep(60000);
}
}
}
在线上删除key时一定要控住删除的速度，以防影响线上业务，我们刚开始时是每秒删除40个key，在测试多个批次后稳定在每秒删除120key是较为好的，但是每个公司的环境是不一样的，大家在删除时，可以先小批量的删除，比如先删除10万个，并且同时监控Redis的网络延时，以防删除过快导致线上业务出现延迟现象
检测网路延时
Redis-cli --latency -h 127.0.0.1 -p 6379
并且同时要关注Redis执行时长最长的十个操作是否执行时间出现异常
redis 127.0.0.1:6379> slowlog get 10
内存碎片率
如果你看到这一步，说明Redis内存已经降下来了，但是随之而来的问题就是，Redis 3.x版本是没有内存释放的功能的，在内存清理后，我们线上的Redis内存碎片率已经接近了3，唯一的解决方案就是重启。
最好的办法就是从机重启，然后手动主从切换，这样内存碎片率就会恢复正常，但是我们并没有这么操作，因为Redis所在的物理机只有Redis一个应用，过高的内存碎片率并不影响Redis提供正常服务，而且手动主从切换，是有数据丢失风险的。
简述
至此Redis的内存分析和清理就结束了，希望各位Coder喜欢。