redis线上问题记录

一、大key

延迟队列采取zset集合来做延迟推送能力，十个业务节点，建了十个key

key：DELAYED_MESSAGE_ZSET + new Random().nextInt(delayMessageZone)

上线之后出现慢查询和缓存使用完毕

• zcard命令查询每个key下有1588600条数据（双十一）

• 高峰期间，慢查询一天也会有几百条

• 十个key路由到redis集群中的其中四台，导致四台内存使用完毕，导致内存失效

• 扩展性不好，增加一台机器需要修改代码

解决办法：

首先是切换到mysql延迟队列中，然后修改了延迟job查询的策略

1、动态修改随机的节点数据，原则是一个key下不要超过一万

2、job五秒一次，广播形式，每个节点上可以获取到job现在执行的节点数和索引号，我们可以循环遍历key的总数，每个节点找出需要查询的key；

//delayMessageZone是key的总数，total是job执行的节点数，modulo为当job执行的节点索引

public void queryDelayedMessage(int modulo,int total) {

    try {

        for (int i = 0; i < delayMessageZone; i++) {

            getMessageSendByBucket(total,modulo, i);

        }

    } catch (Exception e) {

        log.error("queryDelayedMessage error ", e);

    }

}



private void getMessageSendByBucket(int total,int modulo, int i) throws com.tuhu.renault.common.exception.CacheParamException {

    if (i % total == modulo) {

        long min = System.currentTimeMillis() - timeThreshold;

        long max = System.currentTimeMillis() + timeThreshold;

        List<DelayedMessage> delayedMessages = delayedMessageCache.zrangeByScore(DELAYED_MESSAGE_ZSET + i, min, max);

        if (!CollectionUtils.isEmpty(delayedMessages)) {

            delayedMessageCache.zremrangeByScore(DELAYED_MESSAGE_ZSET + i, min, max);

            delayedMessages.forEach(delayedMessage -> {

                delayedQueueListenerMap.get(delayedMessage.getListener()).onMessage(delayedMessage);

            });

        }

    }

}

二、内存碎片问题

运维发现我们一个redis集群内存不足，告示我们要做主从切换

codis usertags集群因内存碎片过多，导致其中一个节点系统内存过低，先临时应急做主从切换，会导致请求瞬断数次，重连即可，请知悉

抱着好奇的心，我学习了redis为什么会产生内存碎片，主要查到原因是因为redis有一个内存管理器，不用每次都去os申请内存，相当于会先申请一部分内存自己管理起来，然后当客户端产生删除key、ttl失效的key移除和内存淘汰的key内存不会立即释放到os内存那种，还是被redis内存管理器所占用；

重点解释可以参考下文

info指令可以查看redis内存使用情况，其中mem_fragmentation_ratio为内存碎片率

used_memory:15288560

used_memory_human:14.58M

used_memory_rss:14237696

used_memory_rss_human:13.58M

mem_fragmentation_ratio:0.93

mem_allocator:jemalloc-3.6.0

然后继续抱着更加好奇的心，和redis运维大师沟通了下，碎片产生的原因，是不是业务问题，得到以下结论：

分析原因：

    redis实例启动会配置个内存大小，当写命令发生没有可用内存后，会开启内存淘汰策略一般是LRU，但是由于满载情况下，这是LRU释放的内存暂时不会立刻给内存分配器使用，内存分配器会继续想os申请内存，保障同时的写入指令，这样会导致申请的内存变多，实际使用的内存变少，这样碎片率也就高了；

解决办法：

1、redis 4.0之前只能重启服务，我们采取的措施是切换到从，重启主；

2、redis 4.0之后修改内存分配器。Redis支持glibc’s malloc、jemalloc11、tcmalloc几种不同的内存分配器，每个分配器在内存分配和碎片上都有不同的实现。不建议普通管理员修改Redis默认内存分配器，因为这需要完全理解这几种内存分配器的差异，也要重新编译Redis。

Redis4版本之后开始支持内存碎片的清理，默认情况下自动清理碎片的参数是关闭的：config get activedefrag应该得到no的输出，开启：config set activedefrag yes，再次输入config get activedefrag验证输出是否为yes。

开启后，后台会启动进程，也可以手动清理：memory purge

总结：这个问题无法解决，只能通过加更多的资源解决；