Redis

最新推荐文章于 2024-04-04 11:33:29 发布

漠然oc

最新推荐文章于 2024-04-04 11:33:29 发布

阅读量173

点赞数 1

分类专栏：数据库

本文链接：https://blog.csdn.net/u014714713/article/details/82350520

版权

数据库专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Redis

Redis 是一个基于内存的高性能key-value数据库，是速度非常快的非关系型（NoSQL）内存键值数据库

速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)
支持丰富数据类型，支持string，list，set，sorted set，hash
支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全部不执行
丰富的特性：可用于缓存，消息，按key设置过期时间，过期后将会自动删除

数据类型

字符串String、字典Hash、列表List、集合Set、有序集合SortedSet

数据类型	可以存储的值	操作
STRING	字符串、整数或者浮点数	对整个字符串或者字符串的其中一部分执行操作对整数和浮点数执行自增或者自减操作
LIST	列表	从两端压入或者弹出元素对单个或者多个元素进行修剪，只保留一个范围内的元素
SET	无序集合	添加、获取、移除单个元素检查一个元素是否存在于集合中计算交集、并集、差集从集合里面随机获取元素
HASH	包含键值对的无序散列表	添加、获取、移除单个键值对获取所有键值对检查某个键是否存在
ZSET	有序集合	添加、获取、删除元素根据分值范围或者成员来获取元素计算一个键的排名

数据结构

字典

Redis其底层基本上就是靠字典来实现。而其字典数据结构是基于哈希表来实现的
dictht 是一个散列表结构，使用拉链法保存哈希冲突的 dictEntry。
Redis 的字典 dict 中包含两个哈希表 dictht，这是为了方便进行 rehash 操作。在扩容时，将其中一个 dictht 上的键值对 rehash 到另一个 dictht 上面，完成之后释放空间并交换两个 dictht 的角色。

结构

// 字典
typedef struct dict {
  //类型特定函数
  dictType *type;
  //私有数据
  void *privdata;
  //哈希表
  dict ht[2];
  //rehash索引，默认值-1
  int rehashidx;
} dict;

// 哈希表
typedef struct dictht {
  //哈希表数组
  dictEntry **table;
  //哈希表大小(table数组的大小)
  unsigned long size;
  //哈希表大小掩码，用于计算索引值，其值总是等于size-1
  unsigned long sizemask;
  //哈希表已有结点的数量
  unsigned long used;
} dictht;

// 哈希表节点
typedef struct dictEntry {
  //键
  void *key;
  //值
  union {
    void *val;
    uint64_t u64;
    int64_t s64;
  } v;
  struct dictEntry *next;
} dictEntry;

这里写图片描述

Rehash

随着程序的运行，字典的大小可能扩展或者收缩，为了提高效率，Redis动态地rehash哈希表。
rehash步骤如下：

为字典的ht[1]哈希表分配空间，这个哈希表需要分配的大小取决于执行的操作（扩展or收缩）以及ht[0].used的大小，具体地
1) 如果执行的是扩展操作，那么ht[1]的大小取大于等于ht[0].usedx2的第一个2^n^ (其中n是一个正整数)。例如，当ht[0].used=5的时候，那么ht[1]的大小取大于等于5x2=10的第一个2^n^，也就是16。
2) 如果执行的是收缩操作，那么ht[1]的大小取大于等于ht[0].used的第一个2^n^。例如，当ht[0].used=5的时候，那么ht[1]的大小取大于等于5的第一个2^n^，也就是8。
将保存在ht[0]中的所有键值对rehash到ht[1]中，也就是重新计算哈希索引，并根据新计算出的哈希值将键值对放到ht[1]的正确位置上。
ht[0]中的所有值都转移到ht[1]后，释放h[0]，将ht[0]设置为指向ht[1]，新建一个空的哈希表，并将ht[1]指向该空的哈希表，为以后rehash做准备。

渐进式Rehash

rehash过程会将ht[0]的所有键值对转移到ht[1]中，但是这个操作不是一次性完成的。如果ht[0]里的键值对只有几个或者几十个，那么rehash操作会很快完成，但是若ht[0]的键值对有几亿甚至几十亿个的时候，这个rehash操作可不是立马就能执行完成的，如果一次性执行完rehash操作，redis将很难再响应正常的应用请求，吞吐量下降很快。因此rehash是渐进式的、分多次执行的。

渐进式rehash步骤：

为字典的ht[1]哈希表分配空间，做好rehash的准备
将字典的rehashidx设置为0，表示开始rehash
在rehash期间，每次对字典执行增、删、改、查的时候，还会顺带将ht[0]在rehashidx索引上的所有键值对rehash到ht[1]中。当本次rehash完成后，rehashidx递增1
随着程序的进行，在某个时刻，ht[0]上的所有键值对都会被rehash到ht[1]，此时将rehashidx设置为-1，表示rehash结束

Redis将Rehash过程分摊到了每一次的增、删、改、查操作中，避免了一次性执行rehash带来的巨大开销。

渐进式Rehash过程中，字典实际上是拥有两个哈希表（ht[0]和ht[1]）的，字典的删除、查找、更新操作会在两个表中进行。对于查找操作，首先会去ht[1]去查找，如果没有查到会去ht[0]去查找。

渐进式Rehash过程中，对字典的添加操作只会在ht[1]中操作而不会在ht[0]中操作，这保证了在渐进式Rehash过程中ht[0]的哈希结点数只会减少，而不会增加，并最终会变为空表。

跳跃表

跳跃表(skiplist)是一种有序数据结构，它通过在每个节点中维持多个指向其他节点的指针，从而达到快速访问节点的目的。

跳跃表支持平均O(logN)、最坏O(N)复杂度的节点查找，还可以通过顺序性操作来批量处理节点。

在大部分情况下，跳跃表的效率可以和平衡树相媲美，并且因为跳跃表的实现比平衡树要来得更为简单，所以有不少程序都使用跳跃表来代替平衡树。

Redis使用跳跃表作为有序集合键的底层实现之一，如果一个有序集合包含的元素数量比较多，又或者有序集合中元素的成员(member)是比较长的字符串时，Redis就会使用跳跃表来作为有序集合键的底层实现。

Redis只在两个地方用到了跳跃表，一个是实现有序集合键，另一个是在集群节点中用作内部数据结构

结构

typedef struct zskiplist {  
    // 分别指向跳跃表的表头结点和表尾结点
    struct zskiplistNode *header, *tail;  
    unsigned long length;  
    // 跳跃表的层数，也就是表中层高最大的那个结点的层数
    int level;  
} zskiplist;  

// 跳跃表结点
typedef struct zskiplistNode { 
    // 该结点的成员对象指针 
    robj *obj; 
    // 该对象的分值，是一个浮点数，跳跃表中的所有结点，都是根据score从小到大来排序的 
    double score;  
    struct zskiplistNode *backward;  
    struct zskiplistLevel {  
        // 层指针，指向该结点在本层的后继结点，用于从表头向表尾方向访问结点
        struct zskiplistNode *forward;  
        // 跨度
        unsigned int span;  
    } level[];  
} zskiplistNode;

这里写图片描述

幂次定律

一个具有k个后继指针的结点称为k层结点。假设k层结点的数量是k+1层结点的P倍，那么其实这个跳跃表可以看成是一棵平衡的P叉树。

跳跃表结点的层数，采用随机化算法得到，越大的数出现的概率越小。

数据淘汰策略

redis 内存数据集大小上升到一定大小的时候，就会施行数据淘汰策略。
redis 提供 6种数据淘汰策略：

voltile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

这里的6种机制，volatile和allkeys规定了是对已设置过期时间的数据集淘汰数据还是从全部数据集淘汰数据，后面的lru、ttl以及random是三种不同的淘汰策略，再加上一种no-enviction永不回收的策略。

使用策略规则：

如果数据呈现幂律分布，也就是一部分数据访问频率高，一部分数据访问频率低，则使用allkeys-lru
如果数据呈现平等分布，也就是所有的数据访问频率都相同，则使用allkeys-random

Memcache与Redis的区别

存储方式
Memecache把数据全部存在内存之中，断电后会挂掉，数据不能超过内存大小。
Redis有部份存在硬盘上，这样能保证数据的持久性。
数据支持类型
Memcache对数据类型支持相对简单，仅支持字符串类型。
Redis有复杂的数据类型，支持五种不同的数据类型，可以更灵活地解决问题。
数据持久化
Redis 支持两种持久化策略：RDB 快照和 AOF 日志。
而 Memcached 不支持持久化。
使用底层模型不同
它们之间底层实现方式以及与客户端之间通信的应用协议不一样。
Redis直接自己构建了VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。
value大小
redis最大可以达到1GB，而memcache只有1MB
分布式
Memcached 不支持分布式，只能通过在客户端使用一致性哈希来实现分布式存储，这种方式在存储和查询时都需要先在客户端计算一次数据所在的节点。
Redis Cluster 实现了分布式的支持。
内存管理机制
在 Redis 中，并不是所有数据都一直存储在内存中，可以将一些很久没用的 value 交换到磁盘，而 Memcached 的数据则会一直在内存中。
Memcached 将内存分割成特定长度的块来存储数据，以完全解决内存碎片的问题。但是这种方式会使得内存的利用率不高，例如块的大小为 128 bytes，只存储 100 bytes 的数据，那么剩下的 28 bytes 就浪费掉了。

持久化

　bgsave做镜像全量持久化，aof做增量持久化。因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，会使用bgsave持久化文件重新构建内存，再使用aof重放近期的操作指令来实现完整恢复重启之前的状态。

如果突然机器掉电会怎样？取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘(刷盘策略)，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。

bgsave的原理

fork和cow。fork是指redis通过创建子进程来进行bgsave操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

事务

本质是一组命令的集合,可以一次执行多个命令，所有命令都会序列化，按顺序地串行化执行而不会被其它命令插入，不许插队。将一组需要一起执行的命令放到multi和exec两个命令之间。multi命令代表事务开始，exec命令代表事务结束，它们之间的命令是原子顺序执行的

三个特性

单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
没有隔离级别的概念：队列中的命令没有提交之前都不会实际的被执行，因为事务提交前任何指令都不会被实际执行，也就不存在”事务内的查询要看到事务里的更新，在事务外查询不能看到”这个让人万分头痛的问题
不保证原子性：redis同一个事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚

事务执行

开启：以MULTI开始一个事务
入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面
执行：由EXEC命令触发事务

命令

包括MULTI、EXEC、WATCH、UNWATCH和DISCARD。

MULTI：开始一个事务

EXEC：提交事务执行（成功返回QUEUED，失败返回错误）

WATCH：监视一个或多个key的变化，一旦有一个key发生了变化，之后的事务就不会执行，监视持续到EXEC命令

UNWATCH：取消WATCH命令对key的监视。每个客户端只会取消自己WATCH的key，而不会对其他客户端有影响

DISCARD：取消WATCH命令对key的监视并清空已入队命令

Redis的同步机制

Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。

Redis集群

Redis Sentinal(哨兵模式)着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。
Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。

Redis单线程

避免了不必要的上下文切换和竞争条件，也不存在多进程或者多线程导致的切换而消耗 CPU，不用去考虑各种锁的问题，不存在加锁释放锁操作，没有因为可能出现死锁而导致的性能消耗。
使用多路I/O复用模型，非阻塞IO。
使用底层模型不同，它们之间底层实现方式以及与客户端之间通信的应用协议不一样，Redis直接自己构建了VM 机制，因为一般的系统调用系统函数的话，会浪费一定的时间去移动和请求。

多路 I/O 复用模型

多路I/O复用模型是利用 select、poll、epoll 可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有 I/O 事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll 是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。

这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络 IO 的时间消耗），且 Redis 在内存中操作数据的速度非常快，也就是说内存内的操作不会成为影响Redis性能的瓶颈，主要由以上几点造就了 Redis 具有很高的吞吐量。

select

基本原理：select 函数监视的文件描述符分3类，分别是writefds、readfds、和exceptfds。调用后select函数会阻塞，直到有描述符就绪（有数据可读、可写、或者有except），或者超时（timeout指定等待时间，如果立即返回设为null即可），函数返回。当select函数返回后，可以通过遍历fdset，来找到就绪的描述符。
select目前几乎在所有的平台上支持，其良好跨平台支持也是它的一个优点。select的一个缺点在于单个进程能够监视的文件描述符的数量存在最大限制，在Linux上一般为1024，可以通过修改宏定义甚至重新编译内核的方式提升这一限制，但是这样也会造成效率的降低。

select本质上是通过设置或者检查存放fd标志位的数据结构来进行下一步处理。这样所带来的缺点是：
1、select最大的缺陷就是单个进程所打开的FD是有一定限制的，它由FD_SETSIZE设置，默认值是1024。
　　一般来说这个数目和系统内存关系很大，具体数目可以cat /proc/sys/fs/file-max察看。32位机默认是1024个。64位机默认是2048.
2、对socket进行扫描时是线性扫描，即采用轮询的方法，效率较低。
　　当套接字比较多的时候，每次select()都要通过遍历FD_SETSIZE个Socket来完成调度，不管哪个Socket是活跃的，都遍历一遍。这会浪费很多CPU时间。如果能给套接字注册某个回调函数，当他们活跃时，自动完成相关操作，那就避免了轮询，这正是epoll与kqueue做的。
3、需要维护一个用来存放大量fd的数据结构，这样会使得用户空间和内核空间在传递该结构时复制开销大。

poll

基本原理：poll本质上和select没有区别，它将用户传入的数组拷贝到内核空间，然后查询每个fd对应的设备状态，如果设备就绪则在设备等待队列中加入一项并继续遍历，如果遍历完所有fd后没有发现就绪设备，则挂起当前进程，直到设备就绪或者主动超时，被唤醒后它又要再次遍历fd。这个过程经历了多次无谓的遍历。

它没有最大连接数的限制，原因是它是基于链表来存储的，但是同样有一个缺点：
1）大量的fd的数组被整体复制于用户态和内核地址空间之间，而不管这样的复制是不是有意义。
2）poll还有一个特点是“水平触发”，如果报告了fd后，没有被处理，那么下次poll时会再次报告该fd。

注意：从上面看，select和poll都需要在返回后，通过遍历文件描述符来获取已经就绪的socket。事实上，同时连接的大量客户端在一时刻可能只有很少的处于就绪状态，因此随着监视的描述符数量的增长，其效率也会线性下降。

epoll

epoll是在2.6内核中提出的，是之前的select和poll的增强版本。相对于select和poll来说，epoll更加灵活，没有描述符限制。epoll使用一个文件描述符管理多个描述符，将用户关系的文件描述符的事件存放到内核的一个事件表中，这样在用户空间和内核空间的copy只需一次。

基本原理：epoll支持水平触发和边缘触发，最大的特点在于边缘触发，它只告诉进程哪些fd刚刚变为就绪态，并且只会通知一次。还有一个特点是，epoll使用“事件”的就绪通知方式，通过epoll_ctl注册fd，一旦该fd就绪，内核就会采用类似callback的回调机制来激活该fd，epoll_wait便可以收到通知。

epoll的优点：
1、没有最大并发连接的限制，能打开的FD的上限远大于1024（1G的内存上能监听约10万个端口）。
2、效率提升，不是轮询的方式，不会随着FD数目的增加效率下降。
　　只有活跃可用的FD才会调用callback函数；即Epoll最大的优点就在于它只管你“活跃”的连接，而跟连接总数无关，因此在实际的网络环境中，Epoll的效率就会远远高于select和poll。
3、内存拷贝，利用mmap()文件映射内存加速与内核空间的消息传递；即epoll使用mmap减少复制开销。

线程安全

redis实际上是采用了线程封闭的观念，把任务封闭在一个线程，自然避免了线程安全问题，不过对于需要依赖多个redis操作的复合操作来说，依然需要锁，而且有可能是分布式锁。

分布式锁

先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。

如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？
这个锁就永远得不到释放了。set指令有非常复杂的参数，可以同时把setnx和expire合成一条指令来用的

Redis缓存

缓存雪崩

设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期，所有原本应该访问缓存的请求都去查询数据库了，而对数据库CPU和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

加锁排队

在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。
使用mutex。简单地来说，就是在缓存失效的时候（判断拿出来的值为空），不是立即去load db，而是先使用缓存工具的某些带成功操作返回值的操作（比如Redis的SETNX或者Memcache的ADD）去set一个mutex key，当操作返回成功时，再进行load db的操作并回设缓存；否则，就重试整个get缓存的方法。

数据预热

可以通过缓存reload机制，预先去更新缓存，再即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀

做二级缓存，或者双缓存策略。

A1为原始缓存，A2为拷贝缓存，A1失效时，可以访问A2，A1缓存失效时间设置为短期，A2设置为长期。

为key设置不同的缓存失效时间

缓存穿透

用户查询数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

布隆过滤

对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合则丢弃。还有最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。

缓存空对象

如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

缓存空对象会有两个问题：

空值做了缓存，意味着缓存层中存了更多的键，需要更多的内存空间 ( 如果是攻击，问题更严重 )，比较有效的方法是针对这类数据设置一个较短的过期时间，让其自动剔除。
缓存层和存储层的数据会有一段时间窗口的不一致，可能会对业务有一定影响。例如过期时间设置为 5分钟，如果此时存储层添加了这个数据，那此段时间就会出现缓存层和存储层数据的不一致，此时可以利用消息系统或者其他方式清除掉缓存层中的空对象。

缓存预热

第一种情况，对于新系统上线，redis中可能没有缓存数据，此时如果大量请求涌入，则会压垮DB是系统无法正常使用；第二种情况，可能系统运行过程中redis的数据全部丢失了，即使开启了持久化也无法恢复，那么也会出现上述描述的异常情况。

缓存预热就是系统上线后，提前将相关的缓存数据直接加载到缓存系统。避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

缓存预热解决方案：

（1）直接写个缓存刷新页面，上线时手工操作下；

（2）数据量不大，可以在项目启动的时候自动进行加载；

（3）定时刷新缓存；

缓存更新

除了缓存服务器自带的缓存失效策略之外（Redis默认的有6中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

（1）定时去清理过期的缓存；

（2）当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的key是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

缓存降级

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。

在进行降级之前要对系统进行梳理，看看系统是不是可以丢卒保帅；从而梳理出哪些必须誓死保护，哪些可降级；比如可以参考日志级别设置预案：

（1）一般：比如有些服务偶尔因为网络抖动或者服务正在上线而超时，可以自动降级；

（2）警告：有些服务在一段时间内成功率有波动（如在95~100%之间），可以自动降级或人工降级，并发送告警；

（3）错误：比如可用率低于90%，或者数据库连接池被打爆了，或者访问量突然猛增到系统能承受的最大阀值，此时可以根据情况自动降级或者人工降级；

（4）严重错误：比如因为特殊原因数据错误了，此时需要紧急人工降级。

面试题

如果有大量的key需要设置同一时间过期，一般需要注意什么？
如果大量的key过期时间设置的过于集中，到过期的那个时间点，redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值，使得过期时间分散一些。

漠然oc

关注

1
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
Redis

RedisRedis 是一个基于内存的高性能key-value数据库，是速度非常快的非关系型（NoSQL）内存键值数据库速度快，因为数据存在内存中，类似于HashMap，HashMap的优势就是查找和操作的时间复杂度都是O(1)支持丰富数据类型，支持string，list，set，sorted set，hash支持事务，操作都是原子性，所谓的原子性就是对数据的更改要么全部执行，要么全...
复制链接

扫一扫

专栏目录