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的失效时间采用随机化，分批的方式。
应用自检
产品的崩溃数每天都是波动的，不利于发现系统的问题，所以云捕开启了一个定时发送崩溃数据的任务，每小时发送1000条，然后通过观察这个App的数据统计就可以感知到整个系统是否稳定。
重复写
将Redis中的数据持久化到数据库的过程中可能会出现网络波动，写入失败的情况，为了保证写成功，云捕中采用每小时重复写4次的策略，一方面重复写数据库比读取Redis重试的逻辑要简单，另一方面当出现网络问题的时候重试有可能反而会加剧这种情况。
本文作者：余宝虹