Redis基础知识

1）redis是什么

Redis 就是一个使用 C 语言开发的数据库，不过与传统数据库不同的是 Redis 的数据是存在内存中的 ，也就是它是内存数据库，所以读写速度非常快，并且使用的储存方式是key-value形式，因此 Redis 被广泛应用于缓存方向。

另外，Redis 除了做缓存之外，Redis 也经常用来做分布式锁，甚至是消息队列。

Redis 提供了多种数据类型来支持不同的业务场景。Redis 还支持事务 、持久化、Lua 脚本、多种集群方案。

2）Redis 常见数据结构

redisObjet：

typedef struct redisObject {
    unsigned type:4;           /* 对象类型 */
    unsigned encoding:4;       /* 内部编码 */
    unsigned lru:LRU_BITS;     /* lru time (relative to server.lruclock) */
                                //最后被访问的时间lru
    int refcount;              /* 引用计数器，内存回收机制就是基于该值实现的 */
    void *ptr;                 /* 若要存储的是整数值则直接存储数据，否则表示指向数据的指针 */
} robj;
//type的占5种类型：
/* Object types */
#define OBJ_STRING 0    //字符串对象
#define OBJ_LIST 1      //列表对象
#define OBJ_SET 2       //集合对象
#define OBJ_ZSET 3      //有序集合对象
#define OBJ_HASH 4      //哈希对象
 
/* Objects encoding. Some kind of objects like Strings and Hashes can be
 * internally represented in multiple ways. The 'encoding' field of the object
 * is set to one of this fields for this object. */
// encoding 的10种类型
#define OBJ_ENCODING_RAW 0     /* Raw representation */     //原始表示方式，字符串对象是简单动态字符串
#define OBJ_ENCODING_INT 1     /* Encoded as integer */         //long类型的整数
#define OBJ_ENCODING_HT 2      /* Encoded as hash table */      //字典
#define OBJ_ENCODING_ZIPMAP 3  /* Encoded as zipmap */          //不在使用
#define OBJ_ENCODING_LINKEDLIST 4 /* Encoded as regular linked list */  //双端链表,不在使用
#define OBJ_ENCODING_ZIPLIST 5 /* Encoded as ziplist */         //压缩列表
#define OBJ_ENCODING_INTSET 6  /* Encoded as intset */          //整数集合
#define OBJ_ENCODING_SKIPLIST 7  /* Encoded as skiplist */      //跳跃表和字典
#define OBJ_ENCODING_EMBSTR 8  /* Embedded sds string encoding */   //embstr编码的简单动态字符串
#define OBJ_ENCODING_QUICKLIST 9 /* Encoded as linked list of ziplists */   //由压缩列表组成的双向列表-->快速列表

1.字符串对象

字符串对象的编码可以是int、raw或者embstr。

int：存放整形值的字符串。

embstr：存放字符的短字符串(大小不超过44个字节)。
raw：存放字符的长字符串(大小不超过44个字节)。

    int:如果一个字符串对象保存的是整数值，并且这个值可以用long类型来表示，那么字符串对象会将整数值保存在对象结构ptr属性里面，并将字符串对象的属性设置为int。

  （1、字符串对象会将整数保存到ptr属性中去。

          2、long double类型在Redis中以字符串类型存储。

         3、保存浮点数会将其转换为字符串再进行保存，使用时将其转换回浮点数。）。

    embstr和raw主要区别：

   1.redis并未提供任何修改embstr的方式，即embstr是只读的形式。对embstr的修改实际上是先转换为raw再进行修改。

  2.采用内存分配方式不同，虽然raw和embstr编码方式都是使用redisObject结构和sdshdr结构。但是raw编码方式采用两次分配内存的方式，分别创建redisObject和sdshdr，而embstr编码方式则是采用一次分配，分配一个连续的空间给redisObject和sdshdr。（embstr一次性分配内存的方式：1，使得分配空间的次数减少。2、释放内存也只需要一次。3、在连续的内存块中，利用了缓存的优点。）

2.列表对象

 列表对象的编码可以是ziplist或者linkedlist。

  ziplist是一种压缩链表，它的好处是更能节省内存空间，因为它所存储的内容都是在连续的内存区域当中的。当列表对象元素不大，每个元素也不大的时候，就采用ziplist存储。但当数据量过大时就ziplist就不是那么好用了。因为为了保证他存储内容在内存中的连续性，插入的复杂度是O(N)，即每次插入都会重新进行realloc。如下图所示，对象结构中ptr所指向的就是一个ziplist。整个ziplist只需要malloc一次，它们在内存中是一块连续的区域。

　一个压缩列表的组成如下：

　　

　　　　1、zlbytes:用于记录整个压缩列表占用的内存字节数

　　　　2、zltail：记录要列表尾节点距离压缩列表的起始地址有多少字节

　　　　3、zllen：记录了压缩列表包含的节点数量。

　　　　4、entryX：要说列表包含的各个节点

　　　　5、zlend：用于标记压缩列表的末端

 

  linkedlist是一种双向链表。它的结构比较简单，节点中存放pre和next两个指针，还有节点相关的信息。当每增加一个node的时候，就需要重新malloc一块内存。

3.哈希对象

哈希对象的底层实现可以是ziplist或者hashtable。

ziplist不再介绍，而hashtable是使用字典dict实现的。

dict的结构

typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    int iterators; /* number of iterators currently running */
} dict;

我门可以看到它的实现主要是由两个dictht组成，而指针dicht ht[2] 指向了两个哈希表：

typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;

dicht[0] 是用于真正存放数据，dicht[1]一般在哈希表元素过多进行rehash的时候用于中转数据。(冲突解决方法为链地址法）

rehash:又称重新散列。

空间操作：为哈希表空间分配内存，又分为扩展操作和收缩操作。

扩展操作：那么ht[1]的大小为第一个大于等于ht[0]的的散列表的长度的2的n次幂。

收缩操作：那么ht[1]的大小为第一个大于等于ht[0]的的散列表的长度的2的n次幂。

数据转移：将ht[0]中的数据转移到ht[1]中需要对哈希节点进行再hash值计算。可以直接将所有的键值对rehash 到ht[1]中，这是因为数据量比较小。在实际开发过程中，这个rehash 操作并不是一次性、集中式完成的，而是分多次、渐进式地完成的。

渐进式rehash 的详细步骤：

1、为ht[1] 分配空间，让字典同时持有ht[0]和ht[1]两个哈希表

2、在几点钟维持一个索引计数器变量rehashidx，并将它的值设置为0，表示rehash 开始

3、在rehash 进行期间，每次对字典执行CRUD操作时，程序除了执行指定的操作以外，还会将ht[0]中的数据rehash 到ht[1]表中，并且将rehashidx加一

4、当ht[0]中所有数据转移到ht[1]中时，将rehashidx 设置成-1，表示rehash 结束

　　　　采用渐进式rehash 的好处在于它采取分而治之的方式，避免了集中式rehash 带来的庞大计算量。

特别的在进行rehash是只能对ht[0]进行使得h[0]元素减少的操作，如查询，和删除；而查询是在两个哈希表中查找的，而插入只能在ht[1]中进行，ht[1]也可以查询和删除。

最后：将ht[0]释放，然后将ht[1]设置成ht[0]，最后为ht[1]分配一个空白哈希表。有安全迭代器可用, 安全迭代器保证, 在迭代起始时, 字典中的所有结点, 都会被迭代到, 即使在迭代过程中对字典有插入操作

4.集合对象

集合对象的编码可以是intset或者hashtable。

intset是一个整数集合，里面存的为某种同一类型的整数，支持如下三种长度的整数：

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

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

intset是一个有序集合，查找元素的复杂度为O(logN)，但插入时不一定为O(logN)，因为有可能涉及到升级操作。比如当集合里全是int16_t型的整数，这时要插入一个int32_t，那么为了维持集合中数据类型的一致，那么所有的数据都会被转换成int32_t类型，涉及到内存的重新分配，这时插入的复杂度就为O(N)了。是intset不支持降级操作。（采用二分法）

hashtable（字典）：其实也类似hashset一样（使用的是hashmap的key），这里使用的是字典而已。

总结

1-当集合对象保存的所有元素都是整数值，并且元素数量小于512个，对象将使用inset编码

2-如果对象不满足inset编码的条件，对象将使用hashtable编码

5.有序集合

redis给有序集合中的每个元素设置一个分数(score)作为排序的依据。

有序集合的编码可能两种，一种是ziplist，另一种是skiplist与dict的结合。

ziplist：作为集合和作为哈希对象是一样的，member和score顺序存放。按照score从小到大顺序排列。只需要在ziplist这个数据结构的基础上做好排序与去重就可以了。它的结构不再复述。当元素个数小于zset-max-ziplist-entries(默认128个) 且 每个元素的值都小于zset-max-ziplist-value(默认64字节)时，使用ziplist作为有序集合的内部实现。

skiplist与dict结合：skiplist又叫跳跃表，结构如下：

/*
 * 跳跃表
 */
typedef struct zskiplist {
    // 头节点，尾节点
    struct zskiplistNode *header, *tail;
    // 节点数量
    unsigned long length;
    // 目前表内节点的最大层数
    int level;
} zskiplist;
/* ZSETs use a specialized version of Skiplists */
/*
 * 跳跃表节点
 */
typedef struct zskiplistNode {
    // member 对象
    robj *obj;
    // 分值
    double score;
    // 后退指针
    struct zskiplistNode *backward;
    // 层
    struct zskiplistLevel {
        // 前进指针
        struct zskiplistNode *forward;
        // 这个层跨越的节点数量
        unsigned int span;
    } level[];
} zskiplistNode;

head和tail分别指向头节点和尾节点，然后每个skiplistNode里面的结构又是分层的(即level数组)。每一列都代表一个节点，保存了member和score，按score从小到大排序。每个节点有不同的层数，这个层数是在生成节点的时候随机生成的数值。每一层都是一个指向后面某个节点的指针。这种结构使得跳跃表可以跨越很多节点来快速访问。（前进可以跳跃式的跳过几个节点，而后退只能后退一个节点）。

 查找时间复杂度平均O(logn)、最坏O(n)。

前面说到了，有序集合ZSET是有跳跃表和hashtable共同形成的。

typedef struct zset {
    // 字典
    dict *dict;
    // 跳跃表
    zskiplist *zsl;
} zset;

为什么要用这种结构呢。试想如果单一用hashtable，那可以快速查找、添加和删除元素，但没法保持集合的有序性。如果单一用skiplist，有序性可以得到保障，但查找的速度太慢O（logN）。

也就是在使用dict与skiplist实现有序集合时, 跳跃表负责按分数索引, 字典负责按数据索引. 跳跃表按分数来索引, 查找时间复杂度为O(lgn). 字典按数据索引时, 查找时间复杂度为O(1). 设想如果没有字典, 如果想按数据查分数, 就必须进行遍历. 两套底层数据结构均只作为索引使用, 即不直接持有数据本身. 数据被封装在SDS中, 由跳跃表与字典共同持有. 而数据的分数则由跳跃表结点直接持有(double类型数据), 由字典间接持有.

3）编码转换

从上面可以看到，每种数据结构都有至少两种编码，而每个对象之间的不同的编码方式之间可以转换，这就是编码转换。在不满足某一个编码方式的使用情景时，就进行编码转换。

4）类型检查

 为了确保只有指定类型的键可以执行某些特定的命令， 在执行一个类型特定的命令之前， Redis 会先检查输入键的类型是否正确， 然后再决定是否执行给定的命令。

类型特定命令所进行的类型检查是通过 redisObject 结构的 type 属性来实现的：

• 在执行一个类型特定命令之前， 服务器会先检查输入数据库键的值对象是否为执行命令所需的类型， 如果是的话， 服务器就对键执行指定的命令；
• 否则， 服务器将拒绝执行命令， 并向客户端返回一个类型错误。

4）内存回收机制

在redisObject中我门可以看到一个int类型的refcount属性又叫做引用计数器，内存回收机制就是基于该值实现的 。

• 当新建一个对象时，refcount的值被初始化为1.
• 当对象被一个新程序引用时，refcount+1.
• 当对象不再被一个程序引用时，refcount-1.

最终当refcount为0时，对象占的内存被释放。

5）对象共享

除了用于实现引用计数内存回收机制之外， 对象的引用计数属性还带有对象共享的作用。

举个例子， 假设键 A 创建了一个包含整数值 100 的字符串对象作为值对象，

如果这时键 B 也要创建一个同样保存了整数值 100 的字符串对象作为值对象， 那么服务器有以下两种做法：

1. 为键 B 新创建一个包含整数值 100 的字符串对象；
2. 让键 A 和键 B 共享同一个字符串对象；

以上两种方法很明显是第二种方法更节约内存。

在 Redis 中， 让多个键共享同一个值对象需要执行以下两个步骤：

1. 将数据库键的值指针指向一个现有的值对象；
2. 将被共享的值对象的引用计数增一。

目前来说， Redis 会在初始化服务器时， 创建一万个字符串对象， 这些对象包含了从 0 到 9999 的所有整数值， 当服务器需要用到值为 0到 9999 的字符串对象时， 服务器就会使用这些共享对象， 而不是新创建对象。

6）对象的空转时长

从redisObject中可以看到一个 lru 属性 该属性记录了对象最后一次被命令程序访问的时间：

typedef struct redisObject {

    // ...

    unsigned lru:22;// 对象最后一次被命令程序访问的时间

    // ...

} robj;

OBJECT IDLETIME 命令可以打印出给定键的空转时长， 这一空转时长就是通过将当前时间减去键的值对象的 lru 时间计算得出的。

如果服务器打开了 maxmemory 选项， 并且服务器用于回收内存的算法为 volatile-lru 或者 allkeys-lru ， 那么当服务器占用的内存数超过了 maxmemory 选项所设置的上限值时， 空转时长较高的那部分键会优先被服务器释放， 从而回收内存。（淘汰策略）

7)持久化

RDB持久化功能会生成一个压缩了的二进制文件、RDB文件。这个文件保存着生成RDB文件时的数据库状态，当需要时，RDB文件可以被还原为数据库状态。这样就实现了在Redis数据库服务器退出时，只要生成了RDB文件，下一次开启时，仍然能够使用生成RDB文件服务器保存的数据库状态。使用系统多进程 COW(Copy On Write) 机制 | fork 函数

手动触发：使用命令SAVE或者BGSAVE。

自动触发：根据服务器配置选项定期执行。

• RDB是一个紧凑压缩的二进制文件，代表Redis在某个时间点上的数据快照。非常适用于备份，全景复制等场景。Redis 加载RDB恢复数据远远快于AOF的方式。
• RDB没有办法做到实时持久化或秒级持久化。

RDB持久化是将进程数据写入文件，而AOF持久化(即Append Only File持久化)，则是将Redis执行的每次写命令记录到单独的日志文件中（有点像MySQL的binlog）；当Redis重启时再次执行AOF文件中的命令来恢复数据。

- RDB持久化基于内存快照存储二进制文件，AOF持久化基于写命令存储文本文件。 
- RDB文件采用了压缩算法，比较小；AOF文件随着命令的叠加会越来越大，Redis提供了AOF重写来压缩AOF文件。 
- 恢复RDB文件的速度比AOF文件快很多。 
- RDB持久化方式实时性不好，所以AOF持久化更主流。 
- 合理的使用AOF的同步策略，理论上不会丢失大量的数据。

Redis 4.0 为了解决这个问题，带来了一个新的持久化选项——混合持久化。将 rdb 文件的内容和增量的 AOF 日志文件存在一起。这里的 AOF 日志不再是全量的日志，而是 自持久化开始到持久化结束 的这段时间发生的增量 AOF 日志，通常这部分 AOF 日志很小，于是在 Redis 重启的时候，可以先加载 rdb 的内容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重启效率因此大幅得到提升。

8）redis事务

流程

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

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

9）Redis过期键的删除策略

• 定时删除： 在设置键的过期时间的同时，创建一个定时器，让定时器执行对键的删除操作。

目前redis事件处理器对时间事件的处理方式–无序链表，查找一个key的时间复杂度为O(n),所以并不适合用来处理大量的时间事件。立即删除对cpu是最不友好的。

• 惰性删除： 每次取的时候先判断 expires 对象里面的键是否已经过期，如果过期，则删除键，否则，返回该键

dict字典和expires字典都要保存这个键值的信息。惰性删除会浪费内存。

• 定期删除： 每隔一段时间，程序对数据库遍历检查一遍，然后删除过期的键

Redis默认每秒进行10次过期扫描：

1. 从过期字典中随机20个key

2. 删除这20个key中已过期的

3. 如果超过25%的key过期，则重复第一步

定期删除过期键能有效的减少过期键而造成的内存浪费，但是设置的太频繁吧，就又跟定时删除一样，浪费大量CPU，设置得长一点吧，这又可能出现内存大量堆积。

所以Redis实际上使用的是惰性删除和定期删除两种策略，通过配合使用，服务器可以很好的平衡 CPU 和内存。

/*
 * 数据库结构
 */
typedef struct redisDb {
    // key space，包括键值对象
    dict *dict;                 /* The keyspace for this DB */
    // 保存 key 的过期时间
    dict *expires;              /* Timeout of keys with a timeout set */
    // 正因为某个/某些 key 而被阻塞的客户端
    dict *blocking_keys;        /* Keys with clients waiting for data (BLPOP) */
    // 某个/某些接收到 PUSH 命令的阻塞 key
    dict *ready_keys;           /* Blocked keys that received a PUSH */
    // 正在监视某个/某些 key 的所有客户端
    dict *watched_keys;         /* WATCHED keys for MULTI/EXEC CAS */
    // 数据库的号码
    int id;
} redisDb;

可以看到expires字典保存了数据库总所有键的过期时间。在expires里，对象中的键和dict一样，但是它的value是标识过期时间的值，以便在删除过期键的时候使用。

内存释放的策略

1. volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰
2. volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰
3. volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰
4. allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰
5. allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰
6. no-enviction（驱逐）：禁止驱逐数据

先判断是从过期集expires中删除键还是从所有数据集dict中删除键。

如果是随机算法，就直接挑选一个随机键进行删除

如果是LRU算法，就采用局部的LRU。意思是不是从所有数据中找到LRU，而是随机找到若干个键，删除其中的LRU键。

如果是TTL算法，就在expires中随机挑几个数据，找到最近的要过期的键进行删除。

10）布隆过滤器

当我们向布隆过滤器中添加数据时，会使用 多个 hash 函数对 key 进行运算，算得一个证书索引值，然后对位数组长度进行取模运算得到一个位置，每个 hash 函数都会算得一个不同的位置。

向布隆过滤器查查询 key 是否存在时，跟 add 操作一样，会把这个 key 通过相同的多个 hash 函数进行运算，查看 对应的位置 是否 都 为 1，只要有一个位为 0，那么说明布隆过滤器中这个 key 不存在。

所以会出现布隆过滤器判断存在的不一定存在，因为会出现交叉，而判断不存在一定不存在。

11）缓存雪崩

描述：缓存中同一时间大批数据过期，查询数据量巨大，引起数据库压力过大甚至宕机，与缓存击穿的区别，缓存雪崩是不同的数据过期，许多数据查不到才查的数据库

解决方案：

1. 缓存数据的过期时间设置随机，防止同一时间大量数据过期现象发生。
2. 如果缓存数据库是分布式部署，将热点数据均匀分布在不同的缓存数据库中。（redis高可用）
3. 设置热点数据永远不过期。

4. 限流降级：这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对某个key只允许一个线程查询数据和写缓存，其他线程等待。

5. 数据预热：数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让缓存失效的时间点尽量均匀。

缓存预热：

1、直接写个缓存刷新页面，上线时手工操作下；
2、数据量不大，可以在项目启动的时候自动进行加载；
3、定时刷新缓存；

缓存热备：

缓存热备即当一台缓存服务器不可用时能实时切换到备用缓存服务器，不影响缓存使用。集群模式下，每个主节点都会有一个或多个从节点来当备用，一旦主节点挂点，从节点立即充当主节点使用。

12）缓存击穿

描述：缓存中的某条数据到期，由于并发用户过多，同时读缓存没读到的数据又同时去数据库取数据，导致数据库压力瞬间增大。（并发查同一条数据）

解决方案：

1. 设置热点数据永久缓存
2. 加上互斥锁，限制同时访问数据库的用户量，一旦获取数据就更新缓存数据

13）缓存穿透

描述：用户不断发起请求，如id为-1的数据或id为特别大但是不在数据库跟缓存中的数据时，不间断的发就会导致数据库的压力过大

解决方案：

1. 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
2. 从缓存取不到的数据，在数据库中也没有取到，这时也可以将k-v键值对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击
3. 布隆过滤器

这里需要注意和缓存击穿的区别，缓存击穿，是指一个key非常热点，在不停的扛着大并发，大并发集中对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一个屏障上凿开了一个洞。

14）redis和数据库协同使用时怎么解决数据一致性问题

1.延时双删策略

在写库前后都进行redis.del(key)操作，并且设定合理的超时时间。具体步骤是：

1）先删除缓存

2）再写数据库

3）休眠500毫秒（根据具体的业务时间来定）可以将1秒内所造成的缓存脏数据，再次删除。(为何是1秒？需要评估自己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。当然这种策略还要考虑redis和数据库主从同步的耗时

4）再次删除缓存。

那么，这个500毫秒怎么确定的，具体该休眠多久呢？

需要评估自己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。

当然，这种策略还要考虑 redis 和数据库主从同步的耗时。最后的写数据的休眠时间：则在读数据业务逻辑的耗时的基础上，加上几百ms即可。比如：休眠1秒。

mysql的读写分离架构的脏读

（1）请求A进行写操作，删除缓存
（2）请求A将数据写入数据库了，
（3）请求B查询缓存发现，缓存没有值
（4）请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
（5）请求B将旧值写入缓存
（6）数据库完成主从同步，从库变为新值
也可采用延时双删

先更新数据库，再删缓存策略

• 失效：应用程序先从cache取数据，没有得到，则从数据库中取数据，成功后，放到缓存中。

• 命中：应用程序从cache中取数据，取到后返回。

• 更新：先把数据存到数据库中，成功后，再让缓存失效。

脏读现象：

（1）缓存刚好失效
（2）请求A查询数据库，得一个旧值
（3）请求B将新值写入数据库
（4）请求B删除缓存
（5）请求A将查到的旧值写入缓存

也可采用延时双删，但是会出现删除失败的问题

重试机制一：

（1）更新数据库数据；
（2）缓存因为种种问题删除失败
（3）将需要删除的key发送至消息队列
（4）自己消费消息，获得需要删除的key
（5）继续重试删除操作，直到成功

重试机制二：

启动一个订阅程序去订阅数据库的binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作。

（1）更新数据库数据
（2）数据库会将操作信息写入binlog日志当中
（3）订阅程序提取出所需要的数据以及key
（4）另起一段非业务代码，获得该信息
（5）尝试删除缓存操作，发现删除失败
（6）将这些信息发送至消息队列
（7）重新从消息队列中获得该数据，重试操作。

15）单线程的redis为什么这么快

(一)纯内存操作
(二)单线程操作，避免了频繁的上下文切换
(三)采用了非阻塞I/O多路复用机制

16）Redis线程模型

文件事件处理器包括分别是套接字、 I/O 多路复用程序、 文件事件分派器（dispatcher）、 以及事件处理器。使用 I/O 多路复用程序来同时监听多个套接字， 并根据套接字目前执行的任务来为套接字关联不同的事件处理器。当被监听的套接字准备好执行连接应答（accept）、读取（read）、写入（write）、关闭（close）等操作时， 与操作相对应的文件事件就会产生， 这时文件事件处理器就会调用套接字之前关联好的事件处理器来处理这些事件。
I/O 多路复用程序负责监听多个套接字， 并向文件事件分派器传送那些产生了事件的套接字。
工作原理：
1)I/O 多路复用程序负责监听多个套接字， 并向文件事件分派器传送那些产生了事件的套接字。
尽管多个文件事件可能会并发地出现， 但 I/O 多路复用程序总是会将所有产生事件的套接字都入队到一个队列里面， 然后通过这个队列， 以有序（sequentially）、同步（synchronously）、每次一个套接字的方式向文件事件分派器传送套接字： 当上一个套接字产生的事件被处理完毕之后（该套接字为事件所关联的事件处理器执行完毕）， I/O 多路复用程序才会继续向文件事件分派器传送下一个套接字。如果一个套接字又可读又可写的话， 那么服务器将先读套接字， 后写套接字.

17）锁

加锁INCR、SETNX、SET

分布式锁

1. 基于 MySQL 中的锁：MySQL 本身有自带的悲观锁 for update 关键字，也可以自己实现悲观/乐观锁来达到目的；
2. 基于 Zookeeper 有序节点：Zookeeper 允许临时创建有序的子节点，这样客户端获取节点列表时，就能够当前子节点列表中的序号判断是否能够获得锁；
3. 基于 Redis 的单线程：由于 Redis 是单线程，所以命令会以串行的方式执行，并且本身提供了像 SETNX(set if not exists) 这样的指令，本身具有互斥性；

待补

 

18）集群

主从复制

• 主服务器负责接收写请求

• 从服务器负责接收读请求

• 从服务器的数据由主服务器复制过去。主从服务器的数据是一致的

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为 主节点(master)，后者称为 从节点(slave)。且数据的复制是 单向 的，只能由主节点到从节点。Redis 主从复制支持 主从同步 和 从从同步 两种，后者是 Redis 后续版本新增的功能，以减轻主节点的同步负担。

主从复制主要的作用

• 数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
• 故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复 (实际上是一种服务的冗余)。
• 负载均衡： 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务 （即写 Redis 数据时应用连接主节点，读 Redis 数据时应用连接从节点），分担服务器负载。尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高 Redis 服务器的并发量。
• 高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实施的 基础，因此说主从复制是 Redis 高可用的基础

Redis 哨兵 (Sentinel) 

• 哨兵节点： 哨兵系统由一个或多个哨兵节点组成，哨兵节点是特殊的 Redis 节点，不存储数据；

使用了 redis sentinel 之后客户端不再直接连接 redis 节点获取服务，而是使用 sentinel 代理获取 redis 服务，类似 Nginx 的代理模式。那么这里又有一个新问题，就是如果 sentinel 宕机了，那么客户端就找不到 redis 服务了，所以 sentinel 本身也是需要支持高可用。

好在sentinel 本身也支持集群部署，并且各个 sentinel 之间支持自动监控，如此一来 redis 主从服务和 sentinel 服务都可以支持高可用。

• 数据节点： 主节点和从节点都是数据节点；

在复制的基础上，哨兵实现了 自动化的故障恢复 功能，下方是官方对于哨兵功能的描述：

• 监控（Monitoring）： 哨兵会不断地检查主节点和从节点是否运作正常。
• 自动故障转移（Automatic failover）： 当 主节点 不能正常工作时，哨兵会开始 自动故障转移操作，它会将失效主节点的其中一个 从节点升级为新的主节点，并让其他从节点改为复制新的主节点。
• 配置提供者（Configuration provider）： 客户端在初始化时，通过连接哨兵来获得当前 Redis 服务的主节点地址。
• 通知（Notification）： 哨兵可以将故障转移的结果发送给客户端。

Redis 集群化

集群中的每一个 Redis 节点都 互相两两相连，客户端任意 直连 到集群中的 任意一台，就可以对其他 Redis 节点进行 读写 的操作。

Redis 集群中内置了 16384 个哈希槽。当客户端连接到 Redis 集群之后，会同时得到一份关于这个 集群的配置信息，当客户端具体对某一个 key 值进行操作时，会计算出它的一个 Hash 值，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，Redis 会根据节点数量 大致均等 的将哈希槽映射到不同的节点。

再结合集群的配置信息就能够知道这个 key 值应该存储在哪一个具体的 Redis 节点中，如果不属于自己管，那么就会使用一个特殊的 MOVED 命令来进行一个跳转，告诉客户端去连接这个节点以获取数据：

集群的主要作用

1. 数据分区： 数据分区 (或称数据分片) 是集群最核心的功能。集群将数据分散到多个节点，一方面 突破了 Redis 单机内存大小的限制，存储容量大大增加；另一方面 每个主节点都可以对外提供读服务和写服务，大大提高了集群的响应能力。Redis 单机内存大小受限问题，在介绍持久化和主从复制时都有提及，例如，如果单机内存太大，bgsave 和 bgrewriteaof 的 fork 操作可能导致主进程阻塞，主从环境下主机切换时可能导致从节点长时间无法提供服务，全量复制阶段主节点的复制缓冲区可能溢出……
2. 高可用： 集群支持主从复制和主节点的 自动故障转移 （与哨兵类似），当任一节点发生故障时，集群仍然可以对外提供服务。

19）数据分区方案

方案一：哈希值 % 节点数

哈希取余分区思路非常简单：计算 key 的 hash 值，然后对节点数量进行取余，从而决定数据映射到哪个节点上。

不过该方案最大的问题是，当新增或删减节点时，节点数量发生变化，系统中所有的数据都需要 重新计算映射关系，引发大规模数据迁移。

方案二：一致性哈希分区

一致性哈希算法将 整个哈希值空间 组织成一个虚拟的圆环，范围是 [0 , 232-1]，对于每一个数据，根据 key 计算 hash 值，确数据在环上的位置，然后从此位置沿顺时针行走，找到的第一台服务器就是其应该映射到的服务器：

方案三：带有虚拟节点的一致性哈希分区

该方案在 一致性哈希分区的基础上，引入了 虚拟节点 的概念。Redis 集群使用的便是该方案，其中的虚拟节点称为 槽（slot）。槽是介于数据和实际节点之间的虚拟概念，每个实际节点包含一定数量的槽，每个槽包含哈希值在一定范围内的数据。

在使用了槽的一致性哈希分区中，槽是数据管理和迁移的基本单位。槽 解耦 了 数据和实际节点 之间的关系，增加或删除节点对系统的影响很小。

20）RDB和AOF对过期键的策略

RDB持久化对过期键的策略：

• 执行SAVE或者BGSAVE命令创建出的RDB文件，程序会对数据库中的过期键检查，已过期的键不会保存在RDB文件中。

• 载入RDB文件时，程序同样会对RDB文件中的键进行检查，过期的键会被忽略。

AOF持久化对过期键的策略：

• 如果数据库的键已过期，但还没被惰性/定期删除，AOF文件不会因为这个过期键产生任何影响(也就说会保留)，当过期的键被删除了以后，会追加一条DEL命令来显示记录该键被删除了

• 重写AOF文件时，程序会对RDB文件中的键进行检查，过期的键会被忽略。

复制模式：

• 主服务器来控制从服务器统一删除过期键(保证主从服务器数据的一致性)

21）完整重同步（数据一致性

• 从服务器向主服务器发送PSYNC命令

• 收到PSYNC命令的主服务器执行BGSAVE命令，在后台生成一个RDB文件。并用一个缓冲区来记录从现在开始执行的所有写命令。

• 当主服务器的BGSAVE命令执行完后，将生成的RDB文件发送给从服务器，从服务器接收和载入RBD文件。将自己的数据库状态更新至与主服务器执行BGSAVE命令时的状态。

• 主服务器将所有缓冲区的写命令发送给从服务器，从服务器执行这些写命令，达到数据最终一致性。

22）部分重同步

接下来我们来看看部分重同步，部分重同步可以让我们断线后重连只需要同步缺失的数据。

部分重同步功能由以下部分组成：

• 主从服务器的复制偏移量

• 主服务器的复制积压缓冲区

• 服务器运行的ID(run ID)

复制偏移量：执行复制的双方都会分别维护一个复制偏移量

• 主服务器每次传播N个字节，就将自己的复制偏移量加上N

• 从服务器每次收到主服务器的N个字节，就将自己的复制偏移量加上N

通过对比主从复制的偏移量，就很容易知道主从服务器的数据是否处于一致性的状态！

那断线重连以后，从服务器向主服务器发送PSYNC命令，报告现在的偏移量是36，那么主服务器该对从服务器执行完整重同步还是部分重同步呢？？这就交由复制积压缓冲区来决定。

当主服务器进行命令传播时，不仅仅会将写命令发送给所有的从服务器，还会将写命令入队到复制积压缓冲区里面(这个大小可以调的)。如果复制积压缓冲区存在丢失的偏移量的数据，那就执行部分重同步，否则执行完整重同步。

服务器运行的ID(run ID)实际上就是用来比对ID是否相同。如果不相同，则说明从服务器断线之前复制的主服务器和当前连接的主服务器是两台服务器，这就会进行完整重同步。

23）命令传播

当完成了同步之后，主从服务器就会进入命令传播阶段。这时主服务器只要将自己的写命令发送给从服务器，而从服务器接收并执行主服务器发送过来的写命令，就可以保证主从服务器一直保持数据一致了！

24）哨兵模式下判断主服务器是否下线了

• 主观下线

  • Sentinel会以每秒一次的频率向与它创建命令连接的实例(包括主从服务器和其他的Sentinel)发送PING命令，通过PING命令返回的信息判断实例是否在线

  • 如果一个主服务器在down-after-milliseconds毫秒内连续向Sentinel发送无效回复，那么当前Sentinel就会主观认为该主服务器已经下线了。

• 客观下线

  • 当Sentinel将一个主服务器判断为主观下线以后，为了确认该主服务器是否真的下线，它会向同样监视该主服务器的Sentinel询问，看它们是否也认为该主服务器是否下线。

  • 如果足够多的Sentinel认为该主服务器是下线的，那么就判定该主服务为客观下线，并对主服务器执行故障转移操作。

25)数据丢失

• 异步复制导致的数据丢失

  • 有部分数据还没复制到从服务器，主服务器就宕机了，此时这些部分数据就丢失了

• 脑裂导致的数据丢失

  • 有时候主服务器脱离了正常网络，跟其他从服务器不能连接。此时哨兵可能就会认为主服务器下线了(然后开启选举，将某个从服务器切换成了主服务器)，但是实际上主服务器还运行着。这个时候，集群里就会有两个服务器(也就是所谓的脑裂)。

  • 虽然某个从服务器被切换成了主服务器，但是可能客户端还没来得及切换到新的主服务器，客户端还继续写向旧主服务器写数据。旧的服务器重新连接时，会作为从服务器复制新的主服务器(这意味着旧数据丢失)。