redis相关总结

it噩梦

已于 2022-03-09 12:06:38 修改

阅读量788

点赞数

分类专栏： redis 文章标签： sql b树数据结构

于 2022-03-06 21:34:03 首次发布

本文链接：https://blog.csdn.net/qq_37362891/article/details/123317299

版权

redis 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

文章目录

Redis过期key是怎么样清理的？

惰性清除
在访问key时，如果发现key已经过期，那么会将key删除。
定时清理
Redis配置项hz定义了serverCron任务的执行周期，默认每次清理时间为25ms，每次清理会依次遍历所有DB，从db的expires字典(里面保存了设置了过期时间的键值对，key就是指向键对象，value是过期时间)中随机取出20个key，如果过期就删除，如果其中有5个key过期，说明过期率超过了25%，那么就继续对这个db进行清理，否则开始清理下一个db。
内存不够时清理
当执行写入命令时，如果发现内存不够，那么就会按照配置的淘汰策略清理内存，淘汰策略一般有6种，Redis4.0版本后又增加了2种，主要由分为三类

第一类不处理，等报错(默认的配置)

noeviction，发现内存不够时，不删除key，执行写入命令时发现内存不够直接返回错误信息。（Redis默认的配置就是noeviction）
第二类从所有结果集中的key中挑选，进行淘汰(随机，lru，lfu三种)

allkeys-random 就是从所有的key中随机挑选key，进行淘汰
allkeys-lru 就是从所有的key中挑选最近使用时间距离现在最远的key，进行淘汰
allkeys-lfu 就是从所有的key中挑选使用频率最低的key，进行淘汰。（这是Redis 4.0版本后新增的策略）
第三类从设置了过期时间的key中挑选，进行淘汰(随机，lru，ttl，lfu)

这种就是从设置了expires过期时间的结果集中选出一部分key淘汰，挑选的算法有：

volatile-random 从设置了过期时间的结果集中随机挑选key删除。

volatile-lru 从设置了过期时间的结果集中挑选上次使用时间距离现在最久的key开始删除

volatile-ttl 从设置了过期时间的结果集中挑选可存活时间最短的key开始删除(也就是从哪些快要过期的key中先删除)

volatile-lfu 从过期时间的结果集中选择使用频率最低的key开始删除（这是Redis 4.0版本后新增的策略）

LRU算法

LRU算法的设计原则是如果一个数据近期没有被访问到，那么之后一段时间都不会被访问到。所以当元素个数达到限制的值时，优先移除距离上次使用时间最久的元素。

可以使用双向链表Node+HashMap<String, Node>来实现，每次访问元素后，将元素移动到链表头部，当元素满了时，将链表尾部的元素移除，HashMap主要用于根据key获得Node以及添加时判断节点是否已存在和删除时快速找到节点。

PS:使用单向链表能不能实现呢，也可以，单向链表的节点虽然获取不到pre节点的信息，但是可以将下一个节点的key和value设置在当前节点上，然后把当前节点的next指针指向下下个节点，这样相当于把下一个节点删除了

//双向链表
    public static class ListNode {
        String key;//这里存储key便于元素满时，删除尾节点时可以快速从HashMap删除键值对
        Integer value;
        ListNode pre = null;
        ListNode next = null;
        ListNode(String key, Integer value) {
            this.key = key;
            this.value = value;
        }
    }

    ListNode head;
    ListNode last;
    int limit=4;

    HashMap<String, ListNode> hashMap = new HashMap<String, ListNode>();

    public void add(String key, Integer val) {
        ListNode existNode = hashMap.get(key);
        if (existNode!=null) {
            //从链表中删除这个元素
            ListNode pre = existNode.pre;
            ListNode next = existNode.next;
            if (pre!=null) {
               pre.next = next;
            }
            if (next!=null) {
               next.pre = pre;
            }
            //更新尾节点
            if (last==existNode) {
                last = existNode.pre;
            }
            //移动到最前面
            head.pre = existNode;
            existNode.next = head;
            head = existNode;
            //更新值
            existNode.value = val;
        } else {
            //达到限制，先删除尾节点
            if (hashMap.size() == limit) {
                ListNode deleteNode = last;
                hashMap.remove(deleteNode.key);
              //正是因为需要删除，所以才需要每个ListNode保存key
                last = deleteNode.pre;
                deleteNode.pre = null;
                last.next = null;
            }
            ListNode node = new ListNode(key,val);
            hashMap.put(key,node);
            if (head==null) {
                head = node;
                last = node;
            } else {
                //插入头结点
                node.next = head;
                head.pre = node;
                head = node;
            }
        }

    }

    public ListNode get(String key) {
        return hashMap.get(key);
    }

    public void remove(String key) {
        ListNode deleteNode = hashMap.get(key);
        ListNode preNode = deleteNode.pre;
        ListNode nextNode = deleteNode.next;
        if (preNode!=null) {
            preNode.next = nextNode;
        }
        if (nextNode!=null) {
            nextNode.pre = preNode;
        }
        if (head==deleteNode) {
            head = nextNode;
        }
        if (last == deleteNode) {
            last = preNode;
        }
        hashMap.remove(key);
    }

LFU算法

LFU算法的设计原则时，如果一个数据在最近一段时间被访问的时次数越多，那么之后被访问的概率会越大，实现是每个数据都有一个引用计数，每次数据被访问后，引用计数加1，需要淘汰数据时，淘汰引用计数最小的数据。在Redis的实现中，每次key被访问后，引用计数是加一个介于0到1之间的数p，并且访问越频繁p值越大，而且在一定的时间间隔内，如果key没有被访问，引用计数会减少。

Redis的性能为什么这么高？

根据官网的介绍，Redis单机可以到到10W的QPS(每秒处理请求数)，Redis这么快的原因主要有以下几点：

1.完全基于内存，数据全部存储在内存中，内存读取时没有磁盘IO，所以速度非常快。

2.Redis采用单线程的模型，没有上下文切换的开销，也没有竞态条件，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。

3.Redis项目中使用的数据结构都是专门设计的，例如SDS(简单动态字符串)是对C语言中的字符串频繁修改时，会频繁地进行内存分配，十分消耗性能，而SDS会使用空间预分配和惰性空间释放来避免这些问题的出现。空间预分配技术: 对SDS进行修改时，如果修改后SDS实际使用长度为len，

当len<1M时,分配的空间会是2*len+1，也就是会预留len长度的未使用空间，其中1存储空字符

当len>1M时,分配的空间会是len+1+1M，也就是会预留1M长度的未使用空间，其中1存储空字符

4.采用多路复用IO模型，可以同时监测多个流的IO事件能力，在空闲时，会把当前线程阻塞掉，当有一个或多个流有I/O事件时，就从阻塞态唤醒，轮询那些真正发出了事件的流，并只依次顺序的处理就绪的流。可以让单个线程高效的处理多个连接请求（尽量减少网络 I/O 的时间消耗)。

Linux中IO模型一共有哪些？

IO模型主要由阻塞式I/O模型，非阻塞式I/O模型，I/O复用模型，信息驱动式I/O模型，异步I/O模型。

阻塞式I/O模型(也就是BIO，Blocking IO)

在这里插入图片描述
用户态进程发出一个IO请求时，会调用recvfrom系统调用去获取数据，如果当前内核中数据没有准备好，那么会让出CPU时间片，一直阻塞等待，不会进行其他操作。直到内核中的数据准备好，将数据拷贝到用户空间内存，然后recvfrom返回成功的信号，此时用户态进行才解除阻塞的状态，处理收到的数据。

非阻塞时I/O模型

在非阻塞式I/O模型中，当进程等待内核的数据，而当该数据未到达的时候，进程会不断询问内核，直到内核准备好数据。用户态进程调用recvfrom接收数据，当前并没有数据报文产生，此时recvfrom返回EWOULDBLOCK，用户态进程会一直调用recvfrom询问内核，待内核准备好数据的时候，之后用户态进程不再询问内核，待数据从内核复制到用户空间，recvfrom成功返回，用户态进程开始处理数据。

I/O多路复用模型

I/O复用指的是多个I/O连接复用一个进程。

基础版的I/O复用模型

最初级的I/O复用，就是一个进程对应多个Socket连接，每次从头至尾进行遍历，判断是否有I/O事件准备好了，需要处理，有的话就进行处理，缺点是效率比较低，如果一直没有事件进来，会导致CPU空转。

升级版的I/O复用模型：

select和poll

当没有I/O事件时，进程处于阻塞状态，当有I/O事件时，就会有一个代理去唤醒进程，对所有的文件描述符进行轮询(一个文件描述符对应一个Socket连接)，来处理I/O事件。（这里的代理也就是select和poll，select只能观察1024个连接，poll可以观察无限个连接，因为poll是基于链表来实现的）

epoll

epoll是对select和poll的升级版，解决了很多问题，是线程安全的，而且可以通知进程是哪个Socket连接有I/O事件,不需要进行全部连接进行遍历，提高了查找效率。

epoll和select/poll最大区别是

(1)epoll内部使用了mmap共享了用户和内核的部分空间，避免了数据的来回拷贝。
(2)epoll基于事件驱动，epoll_wait只返回发生的事件避免了像select和poll对事件的整个轮寻操作（时间复杂度为O(N)），epoll时间复杂度为O（1）。

一文搞懂select、poll和epoll区别

信息驱动式I/O模型

在这里插入图片描述
是阻塞的，当需要等待数据时，用户态进程会给内核发送一个信号，告知自己需要的数据，然后就去执行其他任务了，内核准备好数据后，会给用户态发送一个信号，用户态进程收到之后，会立马调用recvfrom，等待数据从从内核空间复制到用户空间，待完成之后recvfrom返回成功指示，用户态进程才处理数据。

异步I/O模型

与信息驱动式I/O模型区别在于，是在数据从内核态拷贝到用户空间之后，内核才通知用户态进程来处理数据。在复制数据到用户空间这个时间段内，用户态进程也是不阻塞的。

epoll水平触发和边缘触发的区别？

水平触发和边缘触发两种：

LT，默认的模式（水平触发）只要该fd还有数据可读，每次 epoll_wait 都会返回它的事件，提醒用户程序去操作，

ET是“高速”模式（边缘触发）

只会提示一次，直到下次再有数据流入之前都不会再提示，无论fd中是否还有数据可读。所以在ET模式下，read一个fd的时候一定要把它的buffer读完，即读到read返回值小于请求值或遇到EAGAIN错误

epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似回调机制激活该fd，epoll_wait便可收到通知。

同步与异步的区别是什么？

同步与异步的区别在于调用结果的通知方式上。同步执行一个方法后，需要等待结果返回轮询调用结果才能继续执行，然后继续执行下去。异步执行一个方法后，不会等待结果的返回，被调用方在执行完成后通过回调来通知调用方继续执行。

阻塞与非阻塞的区别是什么？

阻塞与非阻塞的区别在于进程/线程在等待消息时，进程/线程是否是挂起状态。

阻塞调用
在消息发出去后，消息返回之前，当前进程/线程会被挂起，直到有消息返回，当前进/线程才会被激活。

非阻塞调用
在消息发出去后，不会阻塞当前进/线程，而会立即返回，可以去执行其他任务。

BIO，NIO，AIO有什么区别？

一次IO的读操作分为等待就绪和IO操作两个阶段，等待就绪就是等待TCP RecvBuffer里面的数据就绪好，也就是发送方的数据全部发送到网卡里面来，操作就是CPU将数据从网卡拷贝到用户空间。

BIO(同步阻塞型)

以Java中的IO方式为例，BIO就是同步阻塞型的IO，当一个Socket连接发送数据过来以后，需要为这个Socket连接创建一个线程，由线程调用Socket的read()方法读取数据，需要先把数据从网卡拷贝到内核空间，再拷贝到用户态的内存空间，在数据读取完成前，线程都是阻塞的。这种IO方式就是比较消耗资源，假设有1000个活跃的Socket连接，需要创建出1000个线程来读取数据，读取时都是阻塞的，每个线程有自己独有的线程栈，默认大小是1M。

NIO(同步非阻塞型)

nio就是多路io复用，就是一个线程来处理多个Socket连接，节省线程资源。以select为例，就是有一个长度为1024的数组，每个元素对应一个Socket连接，线程轮询这个数据，判断哪个Socket连接的数据是出于就绪状态，此时就将数据拷贝到用户空间然后进行处理。由于IO操作阶段是需要等待数据拷贝到用户空间完成才能返回，所以是同步的。由于每次判断内核中Socket缓冲区的数据是否就绪的函数是直接返回的，如果就绪就返回有数据，不是就绪就返回0，线程不需要阻塞等待，所以是非阻塞的。

AIO(异步非阻塞型)

AIO就是NIO的升级版，在数据处于就绪状态时，也是异步将Socket缓冲区中的数据拷贝到用户空间，然后执行异步回调函数，所以在IO操作阶段也是异步的。

BIO里用户最关心“我要读”，NIO里用户最关心"我什么时候可以读了"，在AIO模型里用户更需要关注的是“什么时候读完了，我可以直接进行处理了”。

如何解决Redis缓存穿透问题？

Redis 缓存穿透指的是攻击者故意大量请求一些Redis缓存中不存在key的数据，导致请求打到数据库上，导致数据库压力过大。

解决方案如下：
1.做好参数校验，无效的请求直接返回，只能避免一部分情况，攻击者总是可以找到一些没有覆盖的情况。

2.对缓存中找不到的key，需要去数据库查找的key，缓存到Redis中，但是可能会导致Redis中缓存大量无效的key，可以设置一个很短的过期时间，例如1分钟。

3.也可以使用布隆过滤器，将所有可能的存在的数据通过去hash值的方式存入到一个足够大的bitmap中去，处理请求时，通过在bitmap中查找，可以将不存在的数据拦截掉。

如何解决Redis缓存击穿问题？

缓存击穿主要指的是某个热点key失效，导致大量请求全部转向数据库，导致数据库压力过大。

解决方案：
1.对热点key设置永不过期。

2.加互斥锁，缓存中没有热点key对应的数据时，等待100ms，由获得锁的线程去读取数据库然后设置缓存。

如何解决Redis缓存雪崩问题？

缓存雪崩主要指的是短时间内大量key失效，导致所有请求全部转向数据库，导致数据库压力过大。

解决方案：
1.在给缓存设置失效时间时加一个随机值，避免集体失效。

2.双缓存机制，缓存A的失效时间为20分钟，缓存B的失效时间会比A长一些，从缓存A读取数据，缓存A中没有时，去缓存B中读取数据，并且启动一个异步线程来更新缓存A(如果已经有异步线程正在更新了，就不用重复更新了)。以及更新缓存B，以便延迟B的过期时间。

如何解决缓存与数据库的数据一致性问题？

首先需要明白会导致缓存与数据库的数据不一致的几个诱因：多个写请求的执行顺序不同导致脏数据。更新时正好有读请求，读请求取到旧数据然后更新上。或者数据库是读写分离的，在主库更新完之后，需要一定的时间，从库才能更新。

1. 先更新数据库，后更新缓存

两个写请求，写请求A，写请求B，A先更新数据库，B后更新数据库，但是可能B会先更新缓存，A后更新缓存，这样就会导致缓存里面的是旧数据。 2.更新缓存时失败也有可能导致缓存是旧数据。

2. 先删除缓存，在更新数据库

删除缓存后，更新数据库之前假如正好有读请求，读请求把旧数据设置到缓存了。

3. 先更新数据库，再删除缓存

更新后删除缓存时，网络不好，删除失败也有可能导致缓存是旧数据。
写请求A更新数据库然后删除缓存，读请求B读数据时发现缓存中没有数据，就从数据库拿到旧数据准备设置到缓存上去时，如果整个架构是读写分离的，写请求更新数据是在主库上更新，读请求B是去从库上读数据，如果此时主库上的新数据还没有同步到从库，这样读请求B在从库读到旧数据，设置到缓存上，导致缓存里面是旧数据。

正确的方案

写请求串行化

将写请求更新之前先获取分布式锁，获得之后才能更新，这样实现写请求的串行化，但是会导致效率变低。

先更新数据库，异步删除缓存，删除失败后重试

先更新数据库，异步删除缓存，删除缓存失败时，继续异步重试，或者将操作放到消息队列中，再进行删除操作。（如果数据库是读写分离的，那么删除缓存时需要延迟删除，否则可能会在删除缓存时，从库还没有收到更新后的数据，其他读请求就去从库读到旧数据然后设置到缓存中。）

业务项目更新数据库，其他项目订阅binlog更新

业务项目直接更新数据库，然后其他项目订阅binlog，接收到更新数据库操作的消息后，更新缓存，更新缓存失败时，新建异步线程去重试或者将操作发到消息队列，然后后续进行处理。但是这种方案更新mysql后还是有一定延迟，缓冲中才是新值。

深入理解redis数据结构

Redis内部编码

例如String数据结构就包含了raw、int和embstr三种内部编码。同时，有些内部编码可以作为多种外部数据结构的内部实现，例如ziplist就是hash、list和zset共有的内部编码，而set的内部编码可能是hashtable或者intset：

在这里插入图片描述

Redis这样设计有两个好处：

可以偷偷的改进内部编码，而对外的数据结构和命令没有影响，这样一旦开发出更优秀的内部编码，无需改动对外数据结构和命令。
多种内部编码实现可以在不同场景下发挥各自的优势。例如ziplist比较节省内存，但是在列表元素比较多的情况下，性能会有所下降。这时候Redis会根据配置选项将列表类型的内部实现转换为linkedlist。

String的3种内部编码

由上图可知，String的3种内部编码分别是：int、embstr、raw。int类型很好理解，当一个key的value是整型时，Redis就将其编码为int类型（另外还有一个条件：把这个value当作字符串来看，它的长度不能超过20）。如下所示。这种编码类型为了节省内存。Redis默认会缓存10000个整型值（#define OBJ_SHARED_INTEGERS 10000），这就意味着，如果有10个不同的KEY，其value都是10000以内的值，事实上全部都是共享同一个对象：

127.0.0.1:6379> set number "7890"
OK
127.0.0.1:6379> object encoding number
"int"

接下来就是ebmstr和raw两种内部编码的长度界限，请看下面的源码：

#define OBJ_ENCODING_EMBSTR_SIZE_LIMIT 44
robj *createStringObject(const char *ptr, size_t len) {
    if (len <= OBJ_ENCODING_EMBSTR_SIZE_LIMIT)
        return createEmbeddedStringObject(ptr,len);
    else
        return createRawStringObject(ptr,len);
}

也就是说，embstr和raw编码的长度界限是44，我们可以做如下验证。长度超过44以后，就是raw编码类型，不会有任何优化，是多长，就要消耗多少内存：

127.0.0.1:6379> set name "a1234567890123456789012345678901234567890123"
OK
127.0.0.1:6379> object encoding name
"embstr"
127.0.0.1:6379> set name "a12345678901234567890123456789012345678901234"
OK
127.0.0.1:6379> object encoding name
"raw"

那么为什么有embstr编码呢？它相比raw的优势在哪里？embstr编码将创建字符串对象所需的空间分配的次数从raw编码的两次降低为一次。因为embstr编码的字符串对象的所有数据都保存在一块连续的内存里面，所以这种编码的字符串对象比起raw编码的字符串对象能更好地利用缓存带来的优势。并且释放embstr编码的字符串对象只需要调用一次内存释放函数，而释放raw编码对象的字符串对象需要调用两次内存释放函数。如下图所示，左边是embstr编码，右边是raw编码

在这里插入图片描述

ziplist

List，Hash，Sorted Set三种对外结构，在特殊情况下的内部编码都是ziplist，那么这个ziplist有什么神奇之处呢？

以Hash为例，我们首先看一下什么条件下它的内部编码是ziplist：

当哈希类型元素个数小于hash-max-ziplist-entries配置（默认512个）；
所有值都小于hash-max-ziplist-value配置（默认64个字节）；

如果是sorted set的话，同样需要满足两个条件：

元素个数小于zset-max-ziplist-entries配置，默认128；
所有值都小于zset-max-ziplist-value配置，默认64。

实际上，ziplist充分体现了Redis对于存储效率的追求。一个普通的双向链表，链表中每一项都占用独立的一块内存，各项之间用地址指针（或引用）连接起来。这种方式会带来大量的内存碎片，而且地址指针也会占用额外的内存。而ziplist却是将表中每一项存放在前后连续的地址空间内，一个ziplist整体占用一大块内存。它是一个表（list），但其实不是一个链表（linked list）。

ziplist的源码在ziplist.c这个文件中，其中有一段这样的描述 – The general layout of the ziplist is as follows:：

<zlbytes> <zltail> <zllen> <entry> <entry> ... <entry> <zlend>

zlbytes：表示这个ziplist占用了多少空间，或者说占了多少字节，这其中包括了zlbytes本身占用的4个字节；
zltail：表示到ziplist中最后一个元素的偏移量，有了这个值，pop操作的时间复杂度就是O(1)了，即不需要遍历整个ziplist；
zllen：表示ziplist中有多少个entry，即保存了多少个元素。由于这个字段占用16个字节，所以最大值是2^{16-1，也就意味着，如果entry的数量超过2}16-1时，需要遍历整个ziplist才知道entry的数量；
entry：真正保存的数据，有它自己的编码；
zlend：专门用来表示ziplist尾部的特殊字符，占用8个字节，值固定为255，即8个字节每一位都是1。

 [0f 00 00 00] [0c 00 00 00] [02 00] [00 f3] [02 f6] [ff]
       |             |          |       |       |     |
    zlbytes        zltail    entries   "2"     "5"   end

hashtable

元素比较多时就会使用hashtable编码来作为底层实现，这个时候RedisObject的ptr指针会指向一个dict结构，dict结构中的ht数组保存了ht[0]和ht[1]两个元素，通常使用ht[0]保存键值对，ht[1]只在渐进式rehash时使用。hashtable是通过链地址法来解决冲突的，table数组存储的是链表的头结点（添加新元素，首先根据键计算出hash值，然后与数组长度取模之后得到数组下标，将元素添加到数组下标对应的链表中去）。

谈一谈你对Redis中有序集合ZSet的理解

Zset与Set的区别在于每一个元素都有一个Score属性，并且存储时会将元素按照Score从低到高排列。底层是通过跳跃表实现的。

ziplist
当元素较少时(元素个数<128个，且每个元素的长度小于64字节)，ZSet的底层编码使用ziplist实现，所有元素按照Score从低到高排序。

skiplist+dict
当元素较多时，使用skiplist+dict来实现。 skiplist存储元素的值和Score，并且将所有元素按照分值有序排列。便于以O(logN)的时间复杂度插入，删除，更新，及根据Score进行范围性查找。

dict存储元素的值和Score的映射关系，便于以O(1)的时间复杂度查找元素对应的分值。

谈一谈你对跳跃表的理解

就是单链表的查找的时间复杂度为O(N)，为了提高查询效率，可增加一些索引节点，让查询时间复杂度降低为O(logN)。（只有底层单链表会保存节点数据，上层的节点之后保存几个索引项和分数，也就是向左指向前一个节点的索引，向右指向后一个节点的索引，向下指向上一级的索引。）

时间复杂度的推理过程可以认为，从每一级索引中两个节点中选一个节点作为下一级索引的节点，让下一级索引的节点数量为本级索引节点数量的一半。假设原始链表的长度为n，第一级索引节点个数为n/2,第二级为n/4，一直到最高层。

假设h为层数，f(h)为该层索引节点数量。
f(h)=n/(2^h)
而最高层的索引节点会是只有两个索引节点。
也就是f(maxH)=n/(2^maxH)=2，所以最大层数maxH= log(n) - 1层 ，加上单链表的层数，总层数也就是log(n)层。
例如我们的单链表是1-19的，建立的多层索引如下，
如果我们要查找19，一开始在第四层遍历1，发现19>1,向右走，发现19>9,那么需要到上一级索引去找，然后发现19>13，继续到下一层，一直到第一层，发现19>17，然后往右走遍历17，18，19
所以每一层遍历的节点其实是
1 9
9 13
13 15 17
17 18 19
所以每一层最多遍历的节点数是<=3,这是由于每一层索引节点数是上一层的节点数的一半来得到的，每两个节点的区间，在上一层中都是两个区间，就是第三层的 1  5区间对应上一层的1  3 区间和3  5 区间。
所以时间复杂度=总层数*每层遍历节点数=3logN,去掉常数后是log(N)

第四层 1               9 
第三层 1       5       9          13
第二层 1   3   5   7   9    11    13    15    17
第一层 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

跳跃表是怎么执行查询操作的？

Zset是基于跳跃表+字典实现的，如果只是单key查询，那么就直接从字典中查询(字典的key就是保存了元素的值，value则是元素的分值score)，这样可以用O(1)的时间复杂度完成查询。如果是根据分值score进行范围查询，就是去跳跃表中查询

跳跃表的查询

跳跃表中查找元素只需要通过节点的前进指针完成。

因为每个节点有多层前进指针，首先取第一个节点的最上层的前进指针level[i]，比较指针level[i]跳转到的节点的score与查找的score的大小

如果大于，那么说明要查找的score就处于当前节点与当前的level[i]跳转的节点之间，不能跳转，直接下降一级，取level[i-1]的指针进行判断。如果level[i-1]是最下面的一层，也就是单链表的指针，那么就直接向后进行遍历查找，直到找到这个score或者第一个大于这个score的值(也就是范围查找的左边界)。

如果小于，说明说明要查找的score就处于当前节点与当前的level[i]跳转的节点的后面，跳转后，取跳转后的节点进行这个判断。

渐进式rehash

进行当负载因子>=1时，会进行哈希表扩展操作（如果是在执行BGSAVE或BGREWRITEAOF命令期间，那么需要>=5才会进行扩展）。

进行当负载因子<0.1时，会进行哈希表收缩操作。

因为直接一次性完成rehash会对性能产生影响，所以可以渐进式rehash，具体执行步骤是:

初始化

1.首先将对dict结构中ht[1]哈希表分配空间(大小取决于最接近实际使用空间的2的n次方幂)，然后将rehashindex属性设置为0。

转移

2.这种渐进式rehash转移元素不是全部转移，如果在rehash时全部转移，可能会导致rehash期间Redis实例无法处理后面的请求，所以采取的策略是每次用到某个下标下的键值对才进行转移这个下标下所有的键值对。然后每次对ht[0]中的元素查找，修改，添加时，除了执行指定操作外，还会将对应下标的所有键值对rehash到ht[1],并且会将rehashindex+1。

更改指针指向

3.当ht[0]中所有键值对都是rehash到ht[1]中后，那么会ht[1]和ht[0]的指针值进行交换，将rehashindex设置为-1，代表rehash完成。（整个rehash期间，查找，更新，删除会先去ht[0]中执行，没有才会到ht[1]中执行，新添加键值对是会被保存到ht[1]中）。

intset

Set特殊内部编码，当满足下面的条件时Set的内部编码就是intset而不是hashtable：

Set集合中必须是64位有符号的十进制整型；
元素个数不能超过set-max-intset-entries配置，默认512；

验证如下：

127.0.0.1:6379> sadd scores 135
(integer) 0
127.0.0.1:6379> sadd scores 128
(integer) 1
127.0.0.1:6379> object encoding scores
"intset"

那么intset编码到底是个什么东西呢？看它的源码定义如下，很明显，就是整型数组，并且是一个有序的整型数组。它在内存分配上与ziplist有些类似，是连续的一整块内存空间，而且对于大整数和小整数采取了不同的编码，尽量对内存的使用进行了优化。这样的数据结构，如果执行SISMEMBER命令，即查看某个元素是否在集合中时，事实上使用的是二分查找法：

typedef struct intset {
    uint32_t encoding;
    uint32_t length;
    int8_t contents[];
} intset;

// intset编码查找方法源码（人为简化），标准的二分查找法：
static uint8_t intsetSearch(intset *is, int64_t value, uint32_t *pos) {
    int min = 0, max = intrev32ifbe(is->length)-1, mid = -1;
    int64_t cur = -1;

    while(max >= min) {
        mid = ((unsigned int)min + (unsigned int)max) >> 1;
        cur = _intsetGet(is,mid);
        if (value > cur) {
            min = mid+1;
        } else if (value < cur) {
            max = mid-1;
        } else {
            break;
        }
    }

    if (value == cur) {
        if (pos) *pos = mid;
        return 1;
    } else {
        if (pos) *pos = min;
        return 0;
    }
}

#define INTSET_ENC_INT16 (sizeof(int16_t))
#define INTSET_ENC_INT32 (sizeof(int32_t))
#define INTSET_ENC_INT64 (sizeof(int64_t))

bitmap
这个就是Redis实现的BloomFilter，BloomFilter非常简单，如下图所示，假设已经有3个元素a、b和c，分别通过3个hash算法h1()、h2()和h2()计算然后对一个bit进行赋值，接下来假设需要判断d是否已经存在，那么也需要使用3个hash算法h1()、h2()和h2()对d进行计算，然后得到3个bit的值，恰好这3个bit的值为1，这就能够说明：d可能存在集合中。再判断e，由于h1(e)算出来的bit之前的值是0，那么说明：e一定不存在集合中：

在这里插入图片描述

需要说明的是，bitmap并不是一种真实的数据结构，它本质上是String数据结构，只不过操作的粒度变成了位，即bit。因为String类型最大长度为512MB，所以bitmap最多可以存储2^32个bit。

GEO

GEO数据结构可以在Redis中存储地理坐标，并且坐标有限制，由EPSG:900913 / EPSG:3785 / OSGEO:41001 规定如下：

有效的经度从-180度到180度。

有效的纬度从-85.05112878度到85.05112878度。

当坐标位置超出上述指定范围时，该命令将会返回一个错误。添加地理位置命令如下：

redis> GEOADD city 114.031040 22.324386 "shenzhen" 112.572154 22.267832 "guangzhou"
(integer) 2
redis> GEODIST city shenzhen guangzhou
"150265.8106"

但是，需要说明的是，Geo本身不是一种数据结构，它本质上还是借助于Sorted Set（ZSET），并且使用GeoHash技术进行填充。Redis中将经纬度使用52位的整数进行编码，放进zset中，score就是GeoHash的52位整数值。在使用Redis进行Geo查询时，其内部对应的操作其实就是zset(skiplist)的操作。通过zset的score进行排序就可以得到坐标附近的其它元素，通过将score还原成坐标值就可以得到元素的原始坐标。

总之，Redis中处理这些地理位置坐标点的思想是：二维平面坐标点 --> 一维整数编码值 --> zset(score为编码值) --> zrangebyrank(获取score相近的元素)、zrangebyscore --> 通过score(整数编码值)反解坐标点 --> 附近点的地理位置坐标。

GEOHASH原理

使用wiki上的例子，纬度为42.6，经度为-5.6的点，转化为base32的话要如何转呢？
首先拿纬度来进行说明，纬度的范围为-90到90，将这个范围划为两段，则为[-90,0]、[0,90]，然后看给定的纬度在哪个范围，在前面的范围的话，就设当前位为0，后面的话值便为1.然后继续将确定的范围1分为2，继续以确定值在前段还是后段来确定bit的值。就这样慢慢的缩小范围，一般最多缩小13次就可以了(经纬度的二进制位相加最多25位，经度13位，纬度12位)。这时的中间值，将跟给定的值最相近。如下图所示：

在这里插入图片描述

第1行，纬度42.6位于[0, 90]之间，所以bit=1；第2行，纬度42.6位于[0, 45]之间，所以bit=0；第3行，纬度42.6位于[22.5, 45]之间，所以bit=1，以此类推。这样，取出图中的bit位：1011 1100 1001，同样的方法，将经度(范围-180到180)算出来为：0111 1100 0000 0。结果对其如下：

# 经度
0111 1100 0000 0
# 纬度
1011 1100 1001

得到了经纬度的二进制位后，下面需要将两者进行结合：从经度、纬度的循环，每次取其二进制的一位(不足位取0)，合并为新的二进制数：01101111 11110000 01000001 0。每5位为一个十进制数，结合base32对应表映射为base32值为：ezs42。这样就完成了encode的过程。

geohash基本原理及算法

HyperLogLog 算法的原理讲解以及 Redis 是如何应用它的

HyperLogLog 算法的原理讲解以及 Redis 是如何应用它的

基本数据结构的应用场景？

string应用场景

string 作为数值操作, 当遇到增减类操作incr，decr时会转成数值型进行计算，redis用于控制数据库表主键id（数值计算最大范围是java中的long的最大值）
redis 控制数据的生命周期，通过数据是否失效控制业务行为，适用于所有具有时效性限定控制的操作

hash应用场景

redis 应用于购物车数据存储设计

list应用场景

微信朋友圈点赞，要求按照点赞顺序显示点赞好友信息(lpush)，如果取消点赞，移除对应好友信息(lrem key count value)
list可以对数据进行分页操作，通常第一页的信息来自于list，第2页及更多的信息通过数据库的形式加载
list具有索引的概念，但是操作数据时通常以队列的形式进行入队出队操作，或以栈的形式进行入栈出栈操作
redis 应用于最新消息展示

set 应用场景 //TODO

redis 应用于同类信息的关联搜索，二度关联搜索，深度关联搜索
显示共同关注（一度）
显示共同好友（一度）

sorted_set应用场景

it噩梦

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
redis相关总结

文章目录Redis过期key是怎么样清理的？LRU算法LFU算法Redis的性能为什么这么高？Linux中IO模型一共有哪些？epoll水平触发和边缘触发的区别？同步与异步的区别是什么？阻塞与非阻塞的区别是什么？BIO，NIO，AIO有什么区别？如何解决Redis缓存穿透问题？如何解决Redis缓存击穿问题？如何解决Redis缓存雪崩问题？如何解决缓存与数据库的数据一致性问题？Redis过期key是怎么样清理的？惰性清除在访问key时，如果发现key已经过期，那么会将key删除。定时清理R
复制链接

扫一扫