本文由作者余宝虹授权网易云社区发布。
Redis是一个支持丰富数据结构的分布式key-value系统,Redis在云捕系统的地位相当重要,碰到的问题也比较多,最近才解决了一个遗留的老大难问题。由于15年的时候才接触到Redis,使用过程中姿势存在比较大的问题。在这里列举下面几个问题:
大Set问题
云捕中每天,每小时崩溃数,启动数的统计是通过Storm实时统计,将计算结果存到Redis中实现去重,然后定期将Redis中的数据汇总持久化到数据库中。
最初的实现方式是每个产品的崩溃,启动数都使用一个set来实现统计,set中存储的是设备ID。随着数据量的增加,这个set会变得非常大,会达到单机内存的极限,无法分散到多个节点,不利于扩容,最初云捕使用的物理机内存是32GB,经常会收到内存使用率的报警。分析大对象可以使用 --bigkeys 命令,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同学的文章 redis cpu 抖动问题分析 ,redis-faina redis性能问题诊断利器
应用自检
产品的崩溃数每天都是波动的,不利于发现系统的问题,所以云捕开启了一个定时发送崩溃数据的任务,每小时发送1000条,然后通过观察这个App的数据统计就可以感知到整个系统是否稳定。
重复写
将Redis中的数据持久化到数据库的过程中可能会出现网络波动,写入失败的情况,为了保证写成功,云捕中采用每小时重复写4次的策略,一方面重复写数据库比读取Redis重试的逻辑要简单,另一方面当出现网络问题的时候重试有可能反而会加剧这种情况。
更多网易技术、产品、运营经验分享请访问网易云社区。
文章来源: 网易云社区