Redis

以 embstr 形式存储

对象头和内容存在一起。只需要一次分配内存

以 raw 形式存储

对象头和内容分开存储。需要 2 次分配内存

struct entry {    int prevlen;                       // 前一个 entry 的字节长度    int encoding;                    // 元素类型编码    optional byte[] content;   // 元素内容 }

typedef struct quicklistNode {    quicklistNode *prev;    //前驱节点指针    quicklistNode *next;    //后继节点指针    char *zl;                        //不设置压缩数据参数recompress时指向一个ziplist结构                                         //设置压缩数据参数recompress指向quicklistLZF结构    int sz;                           //压缩列表ziplist的总长度    int count : 16;              //ziplist中包的节点数，占16 bits长度    //表示是否采用了LZF压缩算法压缩quicklist节点，1表示压缩过，2表示没压缩，占2 bits长度    int encoding : 2;         /* RAW==1 or LZF==2 */    //表示一个quicklistNode节点是否采用ziplist结构保存数据，2表示压缩了，1表示没压缩，默认是2，占2bits长度    int container : 2;         /* NONE==1 or ZIPLIST==2 */    //标记quicklist节点的ziplist之前是否被解压缩过，占1bit长度 //如果recompress为1，则等待被再次压缩    int recompress : 1;         /* was this node previous compressed? */    int attempted_compress : 1;    //测试时使用    /* node can't compress; too small */    int extra : 10;                          //额外扩展位，占10bits长度   /* more bits to steal for future usage */ } quicklistNode;

struct zskiplistNode {    robj valObj;                         //节点数据    double score;    zskiplislLevel{    zskiplistNode  forwards;    // 连接指针    int span;                             //该层跨越的节点数量    }level[]     zskiplistNode* backward;   // 回溯指针 }

节点数据结构

embstr连续存储，raw分开存储

1.一整块内存，内存效率高

2.内存碎片少

1.正式因为一整块内存，所以不利于修改

2.每次数据变动都会引发一次内存的realloc

3.当ziplist长度很长的时候，一次realloc可能会导致大批量的数据拷贝，进一步降低性能

1.便于在表的两端进行push和pop操作

1.内存开销比较大

2.在每个节点上除了要保存数据之外，还要额外保存两个指针

3.双向链表的各个节点是单独的内存块，地址不连续，节点多了容易产生内存碎片

换出

换入

换出

换入

配置监听主服务器mymaster 地址端口 至少2个sentinel投票失效(仍然要满足大多数投票)

指定了 Sentinel 认为服务器已经断线所需的毫秒数

在给定的毫秒数内， 没有返回 Sentinel 的 PING 命令的回复， 或返回一个错误， 那么 Sentinel 将这个服务器标记为主观下线

主观下线并不是下线，只有足够数量的sentinel都标记该服务器为主管下线，则该服务器会被标记为客观下线，执行一次故障自动转移

failover过期时间，当failover开始后，在此时间内仍然没有触发任何failover操作，  当前sentinel将会认为此次failoer失败

在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越短, 虽然从服务器的同步过程是异步的，但是在同步期间从服务器是不能对外提供服务的，应避免全部从服务器同时不能对外提供服务

准备新节点，"cluster meet"加入集群

"cluster setslot importing"设置新节点负责的槽

"cluster setslot migrating"原节点准备迁移的槽

原节点"migrate"批量迁移数据

向所有主节点"cluster setslot node"通知主节点新节点负责的槽

前提知识

迁移流程

MOVED和ASK

集群 16384 个槽 任何一个 没有指派到节点时整个集群不可用 的配置

不可用期间“执行任何键命令返回 CLUSTERDOWN Hash slot not served 命令

当持有槽的主节点下线时，从故障发现到自动完成转移期间整个集群是不可用状态，对于大多数业务无法忍受这情况， 因此建议将参数 cluster-require-full-coverage 配置为 no ， 当主节点故障时只影响它负责槽的相关命令执行，不会影响其他主节点的可用性。

引用RedisClusterConfiguration

在JedisCluster基础上实现，根据key类型使用具体的Jedis类与Redis进行交互

引用JedisPoolConfig

一个抽象类，负责初始化、重建、重置Redis slot槽缓存

JedisClusterConnectionHandler类的子类，负责根据key的slot值获取Redis连接

Redis slot缓存类，负责保存、重建和自动发现Redis slot槽与集群节点的关系

在初始化连接的过程中，从RedisNode中任意连接一个， 发送 cluster slots 命令来获取Redis集群节点的槽和Redis集群节点信信息， 并将相应信息保存到Map缓存中

客户端内部维护slots缓存表，并且针对每个节点维护连接池， 当集群规模非常大时，客户端会维护非常多的连接并消耗更多的内存

命令的执行

=used_memory_rss / used_memory

在理想情况下， used_memory_rss 的值应该只比used_memory 稍微高一点儿

当 used > rss 时，表示发生内存Swap了

在redis.conf配置文件中有介绍即ACTIVE DEFRAGMENTATION： 碎片整理允许Redis压缩内存空间，从而回收内存。 这个特性默认是关闭的， 可以通过命令CONFIG SET activedefrag yes热启动这个特性。