Redis进阶学习篇

最近和同事交流redis的使用，但是同事都表达出redis也就是三板斧；String，hash，set，zset，list。生产环境可能，set，hash使用频率比较高。

在运用的过程中还是需要避免一定的坑，当然目的是节省内存和防止慢查询。于是还是看了一些比较不错的redis填坑的文章，个人还比较不错。

下面给大家安利一下：

1、对于大个的集合对象，放redis的时候需要额外注意，如果想依赖redis的过期，可能会造成过期时短暂的redis block。（原文：善待redis中的过期数据）

原因：

Redis提供了一套“美好”的过期数据清理机制:

• 主动过期: Redis对数据是惰性过期，当一个key到了过期时间，Redis也不会马上清理，但如果这个key过期后被再次访问，Redis就会主动将它清理掉。

• 被动过期: 如果过期的Key一直没被访问，Redis也不会一直把它放那不管，它会每秒10次(默认配置)的执行以下的清理工作：

  • 随机从所有带有过期时间的Key里取出20个
  • 如果发现有过期的，就清理
  • 如果这里有25%的Key都是过期的，就继续回到第一步再来一次
  • 同时会判断这20个里过期Key的清理时间，是否超过25% CPU时间(默认25ms)，如果超过了，也不会再继续清理，这个可以保证Redis的CPU不会被占用过长的时间。

这套过期机制设计的很赞，可以这样理解：如果当前有超过1/4的Key是过期的话，就不停地清理，直到只剩下1/4不到的Key是要过期的为止，然后就慢慢地随机抽查着清理。

对应的解决方案：

将过期时间设长一点，然后把这些可以删掉的Key标记一下，丢到一个后台线程那里分页删Set里的数据，这样就算redis再做过期操作，也不会用太多的时间来删除。

2、redis中hmget中可能包含的性能问题。(原文：hmget时间复杂度和性能问题)

对应的解决方案：

如果一次请求30个以下fields，继续使用hmget，75%的情况都是这种正常的请求；剩下的超过30个fields，就用hgetall一次拿出来，交给应用处理。同时，需要定期检查redis里的hash数据的长度，防止长度慢慢增加而出现其他的问题。

3. redis的redis内存优化。（原文: redis内存优化）