摘要

Redis缓存是公共资源。一个系统的不合理使用，会导致公共资源不可用，会引发雪崩效应，各个系统瘫痪。损失不可估量。

Redis缓存崩溃之后，想要恢复正常数据，删除错误数据，很难操作。因此，在使用时，就需要认真、小心、负责，防患于未然。

1、设置超时时间（最重要）

目前有许多key没有设置超时时间，导致一直占用内存。

需要增加操作步骤，设置超时时间。时间尽量短。

某些业务要求key长期有效。可以在每次写入时，都设置超时时间，让超时时间顺延。

短的超时时间，如 5分钟，10分钟，30分钟，1小时，3小时，1天等

长的超时时间，如 7天，15天，1个月，3个月，6个月等

示例代码如下：

// 设置有效期
jedis.expire(cacheMapName, ZLConstant.SECONDS_1_MONTH);

// 如果存在key
if (jedis.exists(mapName)) {
    existMap = true;
}
// 写入登录信息缓存
jedis.hset(mapName, cacheKey, userJson);
// 如果是新建的，就设置超时时间
if (!existMap) {
    // 设置超时时间
    jedis.expire(mapName, expireSeconds);
}

2、高频和低频分离

高频数据存入Redis缓存，低频数据不要存入Redis缓存。

高频数据是经常访问的数据，在这里做好压力缓冲就行了。对于大量数据和列表数据尤其适用。

如，某商店的所有评价数据，总共有5000条之多，最近的30条（高频）可能是最常访问的，可以存入Redis缓存，其他的数据（低频）都不需要存缓存。

3、合理使用list，map，set等集合结构

结合具体业务，设置合理的数据结构，找出更好的选择。

集合结构还可以减少key的个数。

4、尽量使用字符串格式

可视化，便于查看和管理。

特别是在大批量数据的时候，效果明显。

5、合理设置key的格式

多系统在共用缓存，需要key唯一。

合适的key，便于查看，统计，排错。

key的格式，如：系统名+业务名+业务数据+其他。

6、减少key的个数

为了过期管理，合理减少key。

比如，把key-value数据聚合，放到map、list里面。一个集合结构里面就可以包含很多个小数据。

7、精细化运营

之前的使用方法一直是粗放式。业务量小时，没问题；业务量大了，就各种问题。

为了未来系统稳定，为了每个人的职业成长，需要学会精细化运营。

深入分析业务流程，合理安排数据结构，合理使用公共资源，优化读写效率，提高系统抗风险能力。