Redis知识点脑图

BigKey 通常以 Key 的大小和 Key 中成员的数量来综合判定，例如：
Key 本身的数据量过大：一个 String 类型的 Key ，它的值为 5 MB
Key 中的成员数过多：一个 ZSET 类型的 Key ，它的成员数量为 10,000 个
Key 中成员的数据量过大：一个 Hash 类型的 Key ，它的成员数量虽然只有 1,000 个但这些成员的 Value（值）总大小为 100 MB

利用 redis-cli 提供的–bigkeys 参数（redis-cli --bigkeys），可以遍历分析所有 key，并返回 Key 的整体统计信息与每个数据类型的 Top1 的 big key

自己通过代码调用scan命令扫描出所有的key，然后再利用 strlen、hlen 等命令判断 key 的长度

利用第三方工具，如 Redis-Rdb-Tools 分析 RDB 快照文件，全面分析内存使用情况

由于redis集群是对每个key分配的slot去选择不用的redis节点，所以批处理的key有可能分配的slot不是在同一个redis节点上，也就是说一次连接并不能处理这批key，而批处理的初衷就是为了减少连接次数，所以最终会报错

串行命令

串行slot

并行slot

hash_tag

redis中key都是字符串，value也是字符串或者是字符串的集合，所以字符串在redis中随处可见，所以这是专门为了redis中存储字符串的时候使用的

c语言的字符串获取长度的时间复杂度是o(n)，而sds直接o(1)的时间复杂度就可以获取到字符串长度

c语言的字符串不是二进制安全的，因为c语言的字符串是根据/0去判断字符串是否已经结束，如果字符串中本身就有/0那么就不能获取到正确的字符串长度了

redis中提供了5种不同类型的sds，区别在于每一种sds所能存储的字符串长度是不同的，比如说flags为1的sds，最大只能够存储2的8次方-1个字符

当追加字符串的时候如果字符数组长度不够，会去动态申请足够的内存空间

sds可以在o(1)的时间复杂度中去获取字符串长度

二进制安全，可以存任意的二进制数据

支持动态扩容

contents数组存放的就是IntSet元素，而每一个元素支持的大小则是由encoding去控制的

因为只有每一个元素都按照指定的encoding去控制大小，IntSet才可以根据数组下标去计算出元素的起始地址，如上图所示

需要注意的是倒序对每个元素进行扩容，如果正序的话在升级的过程中则会覆盖掉后面的元素

redis是一个键值型的数据库，所以Dict就是用来存储我们的kv键值对的，它类似于java中的HashTable的结构

哈希表中的哈希桶肯定是比String类型的kv键值对要少很多，所以这就不可避免地会出现哈希冲突的情况，当出现哈希冲突的时候，redis会使用链表组织这些冲突的entry，每个entry里面都有个next指针指向了下一个冲突的entry，类似于HashMap结构

当一个哈希桶中的冲突entry越来越多的时候，此时这个桶的链表就会越来越长，那么如果要查找的key在链表的尾部，时间复杂度就是O（n），所以此时redis就会进行一个rehash的操作，而为了进行rehash操作，redis默认使用了两个全局哈希表

dictEntry中的key和val都是指向RedisObject的指针

ZipList是一种特殊的“双端链表”，由一系列特殊编码的连续内存块组成。可以在任意一端进行压入/弹出操作，并且该操作的时间复杂度为O(1)

针对传统的链表来说，传统的链表需要大量的指针（消耗内存）并且每一个节点都是一个独立的内存空间，这样就会产生内存碎片化的问题，所以ZipList就可以解决上述传统链表的这两个问题，它使用了一段连续的内存空间去存储字符串和数字，这样就可以解决掉内存碎片化的问题，并且数据之间不需要使用指针进行关联

zlbytes，占4个字节，记录整个压缩列表所占用的内存字节数
zltail，占4个字节，记录压缩列表表尾节点距离压缩列表的起始地址有多少字节，通过这个偏移量，可以确定表尾节点的地址，从而可以从表尾开始插入删除节点
zllen，占2个字节，记录了压缩列表包含的节点数量，最大值为65534，如果超过这个值，此处会记录为65535，此时就需要遍历整个压缩列表才能知道节点的数量
entry，占用的长度不确定，节点的长度由节点保存的内存决定
zlend，占1个字节，该字节只存特殊值0xFF（十进制255），表示标记压缩列表的末端

由于ZipList中entry不像普通链表那样通过指针进行前后关联（因为指针占用8个字节，前后指针就要占用16个字节，浪费内存），所以entry的结构就设计如上图所示：
（1）previous_entry_length，前一节点的长度，占用1个或者5个字节

• 如果前一节点的长度小于254字节，则采用1个字节来保存这个长度值
• 如果前一节点的长度大于254字节，则采用5个字节来保存这个长度值，第一个字节为0xfe，后四个字节才是真实长度数据

（2）encoding：编码属性，记录content的数据类型（字符串还是整数）以及长度，占用1个、2个或5个字节
（3）contents：负责保存节点的数据，可以是字符串或整数

ZipListEntry中的encoding编码分为字符串和整数两种

ZipList虽然可以节省内存，但是申请的内存必须是要连续的，所以如果当前内存占用比较大，那么申请内存的效率就会比较低，所以我们要解决这个问题的话可以直接限制ZipList的大小，但是如果我们就是要去存储大数据量的呢？那么QuitList就出现了，它是一个节点为ZipList的双端链表

节点采用了ZipList，解决了传统链表内存占用大的问题

控制了ZipList的大小，解决了连续内存空间申请效率的问题

中间节点可以压缩，进一步节省了内存

ZipList以及QuitList的缺点在于它们都需要从头到尾或者从尾到头去进行遍历才能找到对应的数据，这样就会使得查询效率比较低了，而SkipList可以通过建立多级索引然后使用二分查找法去提高查询效率（空间换时间）

如果我们都使用string类型去保存数据，那么每一对key-value都会产生两个redis对象，同样的如果使用集合的数据结构，那么就只会有两个redis对象，相对就节省了很多内存空间

redis中的任意键和值都会被封装成一个RedisObject，也叫Redis对象

raw

embstr

int

在redis3.2之前是在数据量小的情况下使用ZipList，数据量大的情况下使用LinkedList（普通链表），在redis3.2之后就把ZipList和LinkedList结合起来了，也就是QuickList

Dict，Dict中的key存储元素值，value统一为null

当存储的所有数据都是整数的时候，并且元素数量不超过set-max-intset-entries，Set就会采用intset编码，以节省内存

Dict+SkipList

ZipList

ZipList

Dict

同步写回：每个写命令执行完，立马同步地将日志写回磁盘；

每秒写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓冲
区，每隔一秒把缓冲区中的内容写入磁盘；

操作系统控制的写回：每个写命令执行完，只是先把日志写到 AOF 文件的内存缓
冲区，由操作系统决定何时将缓冲区内容写回磁盘。

比如当有一对kv键值对被多次修改形成了多条更新命令之后，在重写aof文件之后，这对kv键值对对应的命令就是只取当前内存中最新的值生成最新的写入命令，这样在恢复数据的时候就只取按照最新的命令去执行就可以了

答案是不会的，因为redis会开启一个子进程去处理aof的重写操作，首先redis会拷贝一份当前内存最新的数据（这里的拷贝不会拷贝物理内存，而是拷贝父进程内存的虚实映射，也就是能共享父进程的所有数据），然后子进程会根据这份拷贝的内存数据去生成最新的写入操作命令，然后再写入到aof的重写文件中。如果此时有写请求过来了，那么也会写入到原本的aof缓冲区中并且会写入到原来的aof文件，同时也会写入新的aof缓冲区，等到新的aof文件重写成功了，再把新的aof缓冲区的数据追加到新aof文件中，最后就可以替代掉原来旧的aof文件了

执行该命令生成RDB二进制文件，在redis的主进程中执行，执行期间redis服务器不会接受任何请求

执行该命令生成RDB二进制文件，父进程会fork出一个子进程去执行该过程，在fork子进程的时候会短暂地阻塞redis主进程

这里有个需要注意的点是replication buffer是一个环形的缓冲区，如果它满了主库的写操作会覆盖掉之前写入的数据，所以主库的这个缓冲区的大小设置是需要去研究的，可以调整repl_backlog_size这个参数去改变缓冲区的大小，如果设置得过小的话可能会导致主从库之间数据不一致

哨兵在运行的时候，会周期性地给所有的主从节点发送ping命令，如果在规定时间没有相应的主库或从库，哨兵就会认为其已经下线了，这里特别是主库，如果主库没有响应就会进入下一个“选主”的任务，但是判断主库是否下线的话并没有那么容易，因为很有可能哨兵会产生误判的情况，比如由于网络拥堵等其他问题导致主库没有及时响应给哨兵，而一旦产生了误判，就会去重新选主，首先哨兵重新选主就会花费时间，之后新主库又要与从库进行数据同步，所以为了避免误判带来的不必要的性能消耗，通常都会使用由多个哨兵实例组成的哨兵集群去判断主库是否下线了。如何判断？很简单，少数服从多数，一个哨兵实例认为这个主库下线的话就会判断为“主观下线”，如果超过一半的实例都认为这个主库是“主观下线”，那么这个主库就会被标记为“客观下线”，这时主库就会真正地被认为是已经下线了

在监控到当前主库已经下线的时候，这时去选主就要去从库里面筛选了，首先把一些已经下线的从库去掉，还有把一些网络总是断连的去掉，具体怎么判断哪些网络总是断连的呢？可以使用配置项 down-after-milliseconds * 10，down-after-milliseconds意思是如果超过这个配置的时长就会认为主从库断连了，而超过10的话就说明这个从库的网络状况不好，不适合选做主库。筛选之后的从库还要根据一定的打分，这个打分规则分别是从库优先级、从库复制进度以及从库 ID 号，第一个从库优先级可以通过设置slave-priority，比如说如果两个从库的内存不一样，你想希望内存大的能够被选上主库，那么这个配置就设置最高，第二个从库复制进度就是说判断下哪个从库的复制进度最接近主库的，选最接近的从库做主库，第三个每个从库都有一个自己的ID编号,在优先级和复制进度都相同的情况下，ID 号最小的从库得分最高，会被选为新主库。

在选出了新主库之后，哨兵就要去通知所有的从库说这个就是新主库，并且从库会向新主库发送replicatof命令成为该主库的从库，然后哨兵还要去发送新主库的连接信息给客户端

在配置哨兵的时候，我们只需要在配置文件中配置下主库的ip+端口就可以了，并没有配置其他哨兵节点的ip，那么哨兵之间是怎么去进行通信的呢？答案就是基于redis的pub/sub机制（发布订阅机制，类似于观察者模式）去实现的，当一个哨兵与主库进行了连接之后，那么它就可以发布自己的连接信息，当然自身也可以在主库上订阅信息去获取到其他哨兵节点的信息

既然哨兵能与主库进行通信，那么它可以向主库发送info命令，主库收到这个命令之后会把从库的ip列表返回给哨兵

当一个哨兵认定为这个从库是“主观下线”的时候，它就会向其他哨兵发送是否赞成的投票，其他哨兵会根据自己与该从库的连接情况响应“Y”或“N”，如果获得的票数大于或等于quorum这个配置值，那么这个从库就会被认定为“客观下线”，此时这个哨兵就能够再次发出投票请求，表示希望自己能够成为整个哨兵集群的Leader，只有成为了Leader才能有发起主从切换的权力，如何成为Leader呢？要满足两个条件：第一，拿到半数以上的赞成票；第二，拿到的票数同时还需要大于等于哨兵配置文件中的 quorum 值。

如果哨兵集群只有 2 个实例，此时，一个哨兵要想成为 Leader，必须获得2票，而不是1票。所以，如果有个哨兵挂掉了，那么，此时的集群是无法进行主从库切换的。

奇数个哨兵节点可以在满足选举该条件的基础上节省一个节点，比如三个master节点和四个master节点的集群相比，大家如果都挂了一个master节点都能选举新master节点，如果都挂了两个master节点都没法选举新master节点了，所以奇数的master节点更多的是从节省机器资源角度出发说的。

比如当前有3台redis节点，一台是master，另外两台是slave，如果此时master节点所在的网络分区与slave节点和sentinel所在的网络分区之间出现了网络异常，那么sentinel就会从两台slave节点中选出一台作为新的master节点，在这期间原先的master节点还是会接收客户端发送过来的请求，但是新的master节点与另一台slave节点却不能进行数据的同步。当网络正常之后，sentinel就会告诉客户端新的master节点，然后原先的master节点就会变成salve节点与新的master节点进行数据同步，这个时候因为要保持主从之间的数据一致，所以原先的master节点就会丢失掉网络异常期间客户端写入的数据

redis提供了两个配置参数

垂直扩展比较简单且粗暴，就是将机器的内存等配置加强，但是这种方式上限较高，很容易受硬件的容量成本所限制，并且会造成内存过大使得redis持久化性能下降

水平扩展就是我们所说的切片集群，采用多台机器去存储数据，每一台都存储一部分数据

集群原理

统计多个集合的交集，并集和差集

统计手机 App 每天的新增用户数和第二天的留存用户数，利用set结构能够支持交集，并集与差集计算的特点，以时间为key，value为当天App注册的所有用户，当天与前天的差集计算可以算出每天的新增用户，当天与前天的交集计算可以算出两天内的留存用户，但是set的交集，并集与差集的计算复杂化比较高，容易造成redis阻塞，所以推荐从主从集群中选用一台从库进行运算或者是直接把数据读到客户端让客户端进行运算

指的是集合元素的取值只有0和1两种，比如签到打卡，用0代表签到带卡，1代表没有签到打卡

利用redis的bitmap数据结构，redis的bitmap结构其实就是一个bit数组，如果我们现在有一个需求，需要统计1亿个用户在10天内的签到情况，那么我们以时间为key，value是1亿个用户的签到状态集合，每一个用户的签到状态用0或1表示然后放到这个bit数组中，最后对这10个bit数组进行与操作就可以知道连续签到10天的用户有多少了，而且使用bitmap结构能够节省空间，所以关于统计二值状态的需求可以尝试去使用bitmap实现