调错API，Redis出现大对象了

引言

本文讲一个前几天阿雄遇到的Redis线上出现大对象的case！

当然，这又是一个基情满满的故事！在排查故障的过程中，充满着爱恨情仇，周旋于险恶的江湖，为求一个稳定的Redis生产环境！

究竟外包韩和阿雄在那天发生了什么呢？

外包韩和阿雄在产生了怎样的爱恨纠葛？

带着我们的好奇心，开始我们的文章!
(当然，本故事改编自生活真实案例，文末附上当时现场微信截图！此文较短，3分钟就能看完！)

正文

这天外包韩正在位置上，打开孤独烟的博客，准备开始学习

突然一封运营小姐姐的邮件发来了~大致意思就是，XX系统的XX页面突然响应十分缓慢，希望外包韩排查一下原因

说到这里，外包韩想起了前几天在孤独烟博客里看到的一篇文章《Redis 敢在线上做Keys正则匹配操作!你可以离职了!》，这篇文章里大致是说，由于redis是单线程的，如果在线上执行类似

keys *

这种复杂度为O(n)级别的命令，会阻塞住其他redis命令的执行，从而导致系统响应过慢！
想到这里，外包韩第一反应就是，是不是执行了其他复杂度为O(n)的命令，导致了其他请求比阻塞住，从而线上响应时间十分缓慢！
找到头绪以后，外包韩就在线上进行查询，看看有没有那种执行特别缓慢的，且复杂度为O(n)级别的命令！
于是乎外包韩在线上执行了一个命令SLOWLOG GET。此时，输出记录如下

redis> SLOWLOG GET
1) 1) (integer) 4               # 日志的唯一标识符（uid）
   2) (integer) 1378781447      # 命令执行时的 UNIX 时间戳
   3) (integer) 13              # 命令执行的时长，以微秒计算
   4) 1) "SET"                  # 命令以及命令参数
      2) "database"
      3) "Redis"
2) 1) (integer) 3
   2) (integer) 1378781439
   3) (integer) 10
   4) 1) "SET"
      2) "number"
      3) "10086"

ps：输出结果从网上拷贝来的，目的是要让大家看到该命令的输出结果大概是什么样的，避免过于抽象。

OK，继续我们的故事！
看到结果，外包韩犯了迷糊！这不对啊，怎么都是一些SET，GET命令，并没那种复杂度高的命令，如SORT这些。这就有点让外包韩犯了迷糊！
于是乎，我们的男主阿雄登场了！

面对外包韩的疑问，阿雄说道:"你的分析方向是对的！确实，调用了复杂度高的redis命令，会导致redis出现卡顿。但是，还有一种情况也会导致Redis卡顿，就是Redis出现大key了(value值过大)！"

"当然，大key可能还会导致一些例如内存空间分布不均匀，数据倾斜问题！我们先不谈，我们先处理这次的生产事故吧！"阿雄一阵叹息道。

"那我们怎么确定这次事故是不是因为大key引起的呢？"外包韩又开始补充道。

"刚才的慢查询日志不是记录下那些key名字了么，我们执行下面的命令即可！这个命令返回一个key和它值在内存中占用的字节数!"

MEMORY USAGE key

说干就干，外包韩一阵操作，key名字为wai:bao:han，只见此时输出结果如下

>memory usage wai:bao:han
(integer) 3600112

惊了，怎么会这么大，一个key的value居然有3M多！
重点什么呢？界面显示上看不出任何异常，仅仅是加载缓慢！
到底value变成了什么，怎么显示正常，却变得这么的大，想到这里，外包韩留下了冷汗！

于是乎外包韩利用redis-cli命令和redis客户端查看数据，发现保存的值都是满屏的x00x00！(由于画面过于惊悚，我就不贴图！)

看到这里，阿雄就大概猜到界面显示上看不出任何异常，功能也看不出任何异常的原因!

阿雄:“你应该是在代码里，取出value的位置前后加了trim操作，所以前面的x00被截去了，因此界面上和功能上看不出任何异常！”
Demo代码如下

String value = stringRedisTemplate.opsForValue().get("wai:bao:han").trim();

接下来，就是定位原因！只见阿雄对着外包韩以手摸手的方式，啊不，手把手的方式找到了set值的位置，只见该处的demo代码如下

stringRedisTemplate.opsForValue().
set("wai:bao:han","I am the most handsome man in the world",60*60*1000);

坦白说，第一眼看到这行代码，阿雄觉得没啥异常，第一个值是key，第二个值是value，第三个值是过期时间。一切都是那么的顺理成章！
然而，跟进源码发现,源码如下

@Override
public void set(K key, V value, long offset) {

    byte[] rawKey = rawKey(key);
    byte[] rawValue = rawValue(value);

    execute(connection -> {
        connection.setRange(rawKey, rawValue, offset);
        return null;
    }, true);
}

原来，三个参数的api，第三个参数的意思，并不是过期时间，而是offset，偏移量。该方法调用的是redis的setRange方法，对此，官网的解释是:
Redis Setrange 命令用指定的字符串覆盖给定 key 所储存的字符串值，覆盖的位置从偏移量 offset 开始。
demo如下:

redis 127.0.0.1:6379> SET key1 "Hello World"
OK
redis 127.0.0.1:6379> SETRANGE key1 6 "Redis"
(integer) 11
redis 127.0.0.1:6379> GET key1
"Hello Redis"

原来，外包韩弄错了API。这两个API是有点像，分别是下面这样

• void set(K key, V value, long offset);

• void set(K key, V value, long timeout, TimeUnit unit);

外包韩误用了第一种，而过期时间又设成了1个小时，也就是3600*1000毫秒，那么每个value前就加了3600000个x00字符，因此value值就变得十分的大！
因此只需要像代码这么改！

stringRedisTemplate.opsForValue().
set("wai:bao:han","I am the most handsome man in the world",60*60*1000,TimeUnit.MILLISECONDS);

就能解决问题，可以正确设置过期时间了！

ok，这篇短文就结束了！至于外包韩和阿雄的故事，远不止这些～敬请期待！

末尾

附上当时现场截图！