Redis OOM问题排查

1. 问题描述

看到Redis报了OOM的错误，而且服务响应速度非常慢，页面上丢了很多数据，赶紧起来查看问题。

2. 问题排查

我们的系统架构是双边双活的，两个DC（Primary和GSB）都会有数据写进来，通过API把数据存到数据库（双边数据库有复制），同时写到Redis队列一份（这里把Redis当成MQ来用），然后有个Job从redis队列里面把数据取出来，写到两边，流式地处理数据。对于Redis队列来说，API是生产者，Job是消费者。这次只是GSB这边的Redis出了问题，导致了单边不可用。

架构简图

2.1 问题定位

一般Redis里的元数据大小是比较稳定的，出现OOM应该先看队列的大小。果然这个数据队列的size已经远远超过了阈值。我们先把队列清空了，然后把数据读取从Redis切换到了DB，GSB侧终于能正常工作了。

2.2 进一步跟踪

现在我们的数据量一般是每秒钟三四百条左右，按理来说Job的消费速度肯定是能跟上的。但是看问题侧（GSB侧）队列大小大致呈每秒钟一百条的速度在递增。看了一下GSB侧Job的log，发现消费速度很不稳定，最慢的时候一秒钟只能处理三四十条。按照Redis官方百万级的QPS，这简直可以用龟速来形容了。接下来我们来看具体慢在哪里。可以用

redis-cli --latency -h `host` -p `port&