本文由作者余宝虹授权网易云社区发布。

Redis是一个支持丰富数据结构的分布式key-value系统，Redis在云捕系统的地位相当重要,碰到的问题也比较多,最近才解决了一个遗留的老大难问题。由于15年的时候才接触到Redis,使用过程中姿势存在比较大的问题。在这里列举下面几个问题:

大Set问题

云捕中每天，每小时崩溃数，启动数的统计是通过Storm实时统计，将计算结果存到Redis中实现去重，然后定期将Redis中的数据汇总持久化到数据库中。

最初的实现方式是每个产品的崩溃，启动数都使用一个set来实现统计，set中存储的是设备ID。随着数据量的增加，这个set会变得非常大，会达到单机内存的极限，无法分散到多个节点，不利于扩容，最初云捕使用的物理机内存是32GB，经常会收到内存使用率的报警。分析大对象可以使用  命令，NCR不支持。

当内存使用量到达maxmemory之后就会执行响应的缓存替换策略，默认是allkey-lru，所以当用于统计数据的set被删除后，就会出现崩溃数从0开始 统计的情况，出现统计数据丢失的问题。

改造前效果：

为了使用NCR的扩容能力，就需要消除掉对大Set的依赖，改造后，采用的方法是：对每个设备ID生成一个key，计数增加之前会判断对应的设备ID key是否存在。采用这种方式后就会出现大量的key，所以在key的命名上也应该尽量简短。

protected void add(Jedis jedis, String key, String deviceId, long expireTime) {    expireTime /= 1000;    String value ="";    String member=key+":"+deviceId;    if (jedis.setnx(member, value) == 1) {        jedis.incr(key);      }    jedis.expireAt(member, expireTime);    jedis.expireAt(key, expireTime);}

改造后效果：

CPU抖动

云捕存储在Redis中的统计数据具有时效性，每天的凌晨会将前一天的数据持久化到数据库，所以前一天的key都可以删掉。问题是如果大量的key都突发在同一时间失效的话，就会导致CPU使用率剧增，而且大Set删除时耗时更长，所以改进后key的失效时间采用随机化，分批的方式。

具体可以见DBA同学的文章  ，

应用自检

产品的崩溃数每天都是波动的，不利于发现系统的问题，所以云捕开启了一个定时发送崩溃数据的任务，每小时发送1000条，然后通过观察这个App的数据统计就可以感知到整个系统是否稳定。

重复写

将Redis中的数据持久化到数据库的过程中可能会出现网络波动，写入失败的情况，为了保证写成功，云捕中采用每小时重复写4次的策略，一方面重复写数据库比读取Redis重试的逻辑要简单，另一方面当出现网络问题的时候重试有可能反而会加剧这种情况。

更多网易技术、产品、运营经验分享请访问。

相关文章：

【推荐】