Redis Memo

摘要

• 那在Redis集群模式下，如何进行批量操作 mget？
  即:
  如果执行的key数量比较少，就不用mget了，就用串行get操作。如果真的需要执行的key很多，就使用Hashtag保证这些key映射到同一台redis节点上。简单来说语法如下

  对于key为{foo}.student1、{foo}.student2，{foo}student3，这类key一定是在同一个redis节点上。因为key中“{}”之间的字符串就是当前key的hash tags， 只有key中{ }中的部分才被用来做hash，因此计算出来的redis节点一定是同一个!

• 16384个槽
•  HASH_SLOT=CRC16(key) mod 16384 ：
  • CRC16的校验码是两个字节，所以Redis的源码中使用了 uint16_t类型（unsigned short int）
  • CRC16要校验的数据位是8位

• 这里要先将节点握手讲清楚。我们让两个redis节点之间进行通信的时候，需要在客户端执行下面一个命令

  127.0.0.1:7000>cluster meet 127.0.0.1:7001

• ps:CRC16算法产生的hash值有16bit，该算法可以产生2^16-=65536个值。换句话说，值是分布在0~65535之间。那作者在做mod运算的时候，为什么不mod65536，而选择mod16384？

• (1)如果槽位为65536，发送心跳信息的消息头达8k，发送的心跳包过于庞大。
  如上所述，在消息头中，最占空间的是myslots[CLUSTER_SLOTS/8]。
  当槽位为65536时，这块的大小是:
  65536÷8÷1024=8kb

　　　　(
　　　　位："位(bit)"是电子计算机中最小的数据单位。每一位的状态只能是0或1。

　　　　字节：8个二进制位构成1个"字节(Byte)"，它是存储空间的基本计量单位。1个字节可以储存1个英文字母或者半个汉字，换句话说，1个汉字占据2个字节的存储空间。

　　　　KB：在一般的计量单位中，通常K表示1000。例如：1公里= 1000米，经常被写为1km；1公斤=1000克，写为1kg。同样K在二进制中也有类似的含义。只是这时K表示1024，也就是2的10次方。1KB表示1K个Byte，也就是1024个字节。)

• 因为每秒钟，redis节点需要发送一定数量的ping消息作为心跳包，如果槽位为65536，这个ping消息的消息头太大了，浪费带宽。
  (2)redis的集群主节点数量基本不可能超过1000个。
  如上所述，集群节点越多，心跳包的消息体内携带的数据越多。如果节点过1000个，也会导致网络拥堵。因此redis作者，不建议redis cluster节点数量超过1000个。
  那么，对于节点数在1000以内的redis cluster集群，16384个槽位够用了。没有必要拓展到65536个。
  (3)槽位越小，节点少的情况下，压缩比高
  Redis主节点的配置信息中，它所负责的哈希槽是通过一张bitmap的形式来保存的，在传输过程中，会对bitmap进行压缩，但是如果bitmap的填充率slots / N很高的话(N表示节点数)，bitmap的压缩率就很低。
  如果节点数很少，而哈希槽数量很多的话，bitmap的压缩率就很低。

  ps：文件压缩率指的是，文件压缩前后的大小比。

  综上所述，作者决定取16384个槽，不多不少，刚刚好！

　　

• Redis的LRU实现

  如果按照HashMap和双向链表实现，需要额外的存储存放 next 和 prev 指针，牺牲比较大的存储空间，显然是不划算的。所以Redis采用了一个近似的做法，就是随机取出若干个key，然后按照访问时间排序后，淘汰掉最不经常使用的，具体分析如下：

  为了支持LRU，Redis 2.8.19中使用了一个全局的LRU时钟，server.lruclock，定义如下，

  #define REDIS_LRU_BITS 24
  unsigned lruclock:REDIS_LRU_BITS; /* Clock for LRU eviction */
  

  默认的LRU时钟的分辨率是1秒，可以通过改变REDIS_LRU_CLOCK_RESOLUTION宏的值来改变，Redis会在serverCron()中调用updateLRUClock定期的更新LRU时钟，更新的频率和hz参数有关，默认为100ms一次，如下，

  #define REDIS_LRU_CLOCK_MAX ((1<<REDIS_LRU_BITS)-1) /* Max value of obj->lru */
  #define REDIS_LRU_CLOCK_RESOLUTION 1 /* LRU clock resolution in seconds */
  
  void updateLRUClock(void) {
      server.lruclock = (server.unixtime / REDIS_LRU_CLOCK_RESOLUTION) &
                                                  REDIS_LRU_CLOCK_MAX;
  }
  

  server.unixtime是系统当前的unix时间戳，当 lruclock 的值超出REDIS_LRU_CLOCK_MAX时，会从头开始计算，所以在计算一个key的最长没有访问时间时，可能key本身保存的lru访问时间会比当前的lrulock还要大，这个时候需要计算额外时间，如下，

  /* Given an object returns the min number of seconds the object was never
   * requested, using an approximated LRU algorithm. */
  unsigned long estimateObjectIdleTime(robj *o) {
      if (server.lruclock >= o->lru) {
          return (server.lruclock - o->lru) * REDIS_LRU_CLOCK_RESOLUTION;
      } else {
          return ((REDIS_LRU_CLOCK_MAX - o->lru) + server.lruclock) *
                      REDIS_LRU_CLOCK_RESOLUTION;
      }
  }
  

  Redis支持和LRU相关淘汰策略包括，

  • volatile-lru 设置了过期时间的key参与近似的lru淘汰策略
  • allkeys-lru 所有的key均参与近似的lru淘汰策略

  当进行LRU淘汰时，Redis按如下方式进行的，

  ......
              /* volatile-lru and allkeys-lru policy */
              else if (server.maxmemory_policy == REDIS_MAXMEMORY_ALLKEYS_LRU ||
                  server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
              {
                  for (k = 0; k < server.maxmemory_samples; k++) {
                      sds thiskey;
                      long thisval;
                      robj *o;
  
                      de = dictGetRandomKey(dict);
                      thiskey = dictGetKey(de);
                      /* When policy is volatile-lru we need an additional lookup
                       * to locate the real key, as dict is set to db->expires. */
                      if (server.maxmemory_policy == REDIS_MAXMEMORY_VOLATILE_LRU)
                          de = dictFind(db->dict, thiskey);
                      o = dictGetVal(de);
                      thisval = estimateObjectIdleTime(o);
  
                      /* Higher idle time is better candidate for deletion */
                      if (bestkey == NULL || thisval > bestval) {
                          bestkey = thiskey;
                          bestval = thisval;
                      }
                  }
              }
              ......
  

  Redis会基于server.maxmemory_samples配置选取固定数目的key，然后比较它们的lru访问时间，然后淘汰最近最久没有访问的key，maxmemory_samples的值越大，Redis的近似LRU算法就越接近于严格LRU算法，但是相应消耗也变高，对性能有一定影响，样本值默认为5。