你用过Redis吗？90%可能用过； 你有用Redis存储超过20G数据的经历吗？ 40%可能有过； 你见过把Redis存储的20G数据经“优化”后，将使用内存降低2000倍的神迹吗？ 肯定没有吧！别着急 瓜子啤酒矿泉水……
请您前排坐稳，咱们这就发车！
我要升级redis集群，谁也别拦着我
“我要升级redis集群，谁也别拦着我！”最近运维的同学吵着闹着要升级redis集群，原因是现有的redis主从实例最近总是莫名下线，已经影响到交易。简单粗暴的办法，就是堆机器。而我一直秉持着“只要思想不滑坡，办法总比困难多”的迷之自信，好容易发现这么难得的问题，怎么能就这么轻易放过它！就这样，我开始了此次填坑之行。
开始排查
1. 监控异常信息为：(error) LOADING Redis is loading the dataset in memory
2. 查看redis日志，无明显异常（日志不全，也是不能忽视的问题）
3. 询问是否有其他业务共用此Redis服务，回答没有
根据以上运维同学反馈的情况，结合多年填坑的经验，做出了如下推断：
1. 根据异常信息，可以确定大致的方向，Redis在恢复数据时阻塞，导致服务停止
2. 要阻塞这么久，应该是需要同步的数据量太大
3. 但是该组业务的情况我十分了解，绝对不会产生这么大的数据量，此处定有蹊跷！
万事俱备，只差动手。
收集证据
1. 运行中的redis占用内存为20.94G
2. 深入Redis内部，摸清数据情况
# 分析查看当前数据的分布情况，该命令不会阻塞服务
redis-cli -h 127.0.0.1 -p 6379 --bigkeys
# 得到如下结果
# Scanning the entire keyspace to find biggest keys as well as
# average sizes per key type. You can use -i 0.1 to sleep 0.1 sec
# per 100 SCAN commands (not usually needed).
[00.00%] Biggest hash found so far 'key1' with 8 fields
[00.98%] Biggest string found so far 'yy' with 2 bytes
[04.62%] Biggest hash found so far 'key2' with 36 fields
[11.06%] Biggest hash found so far 'key3' with 52 fields
[17.70%] Biggest string found so far 'qqqwww' with 5 bytes
[19.34%] Biggest hash found so far 'key4' with 8216 fields
[26.87%] Biggest list found so far 'logstash:redis' with 60124266 items
[43.47%] Biggest string found so far 'key5' with 29 bytes
[52.94%] Biggest string found so far 'key6' with 293 bytes
-------- summary -------
Sampled 8243 keys in the keyspace!
Total key length in bytes is 243527 (avg len 29.54)
Biggest string found 'key6' has 293 bytes
Biggest list found 'logstash:redis' has 60124266 items
Biggest hash found 'key4' has 8216 fields
10 strings with 642 bytes (00.12% of keys, avg size 64.20)
1 lists with 60124266 items (00.01% of keys, avg size 60124266.00)
0 sets with 0 members (00.00% of keys, avg size 0.00)
8232 hashs with 74318 fields (99.87% of keys, avg size 9.03)
0 zsets with 0 members (00.00% of keys, avg size 0.00)复制
3. 找到内鬼：“[26.87%] Biggest list found so far 'logstash:redis' with 60124266 items”
破案
当我见到“logstash:redis”的第一眼，我的心情十分复杂，十分复杂，复杂。它清楚的表明，这是给logstash喂数据的【大！大！！大！！！】队列。但是该组业务，并没有使用logstash做日志收集处理啊！此刻，真相已渐渐浮出水面。
首先要缓解紧张的局面！先把“logstash:redis”关进小黑屋。其他秋后再算帐。
# 新建shell文件:clean-redis-rubbish.sh ,内容如下：
redis-cli -h 127.0.0.1 -p 6379 del logstash:redis
# 新建自动任务，执行如下命令：
crontab -e
# 每分钟当时执行清除shell，保存退出
*/1 * * * * sh /home/user/clean-redis-rubbish.sh >> /home/user/clean-redis-rubbish.log复制
然后，尘归尘，土归土。整个世界都清净了。
总结
后来，运维同学对自己的犯罪事实供认不讳。某一天，他在测试完日志收集后，忘了关！忘了关！！忘了关！！！然后日志不断的被写入Redis，但是没有人消费……
这件事，也提醒我们。在我们这样的小厂，在技术人员能力参差不齐、运维制度不健全、异常情况监控不到位的情况下，首要的还是要健全制度，用制度形成约束力，在约束自由的同时，更是控制了风险，利大于弊。
同时，作为一个技术从业者，也要时刻保持对技术的警觉。发现问题，解决问题（哪怕是乌龙事件），是我们的职责所在。钱可以买硬件设备，硬件设备的堆积，可以暂时缓解问题，但是不能从根本上解决问题。
