一文搞懂redis

一  什么是NoSQL？

RDBMS - 组织化结构 - 固定SQL - 数据和关系都存在单独的表中（行列） - DML（数据操作语言）、DDL（数据定义语言）等 - 严格的一致性（ACID): 原子性、一致性、隔离性、持久性 - 基础的事务

NoSQL - 不仅仅是数据 - 没有固定查询语言 - 键值对存储（redis）、列存储（HBase）、文档存储（MongoDB）、图形数据库（不是存图形，放的是关系）（Neo4j） - 最终一致性（BASE）：基本可用、软状态/柔性事务、最终一致性

二  redis是什么？

三  redis五大基本类型

1  String（字符串）

1.String类型是redis的最基础的数据结构，也是最经常使用到的类型。  而且其他的四种类型多多少少都是在字符串类型的基础上构建的，所以String类型是redis的基础。2.String 类型的值最大能存储 512MB，这里的String类型可以是简单字符串、  复杂的xml/json的字符串、二进制图像或者音频的字符串、以及可以是数字的字符串

应用场景

2  List（列表）

list类型是用来存储多个有序的字符串的，列表当中的每一个字符看做一个元素2.一个列表当中可以存储有一个或者多个元素，redis的list支持存储2^32次方-1个元素。3.redis可以从列表的两端进行插入（pubsh）和弹出（pop）元素，支持读取指定范围的元素集，  或者读取指定下标的元素等操作。redis列表是一种比较灵活的链表数据结构，它可以充当队列或者栈的角色。4.redis列表是链表型的数据结构，所以它的元素是有序的，而且列表内的元素是可以重复的。  意味着它可以根据链表的下标获取指定的元素和某个范围内的元素集。

应用场景

3  Set（集合）

1.redis集合（set）类型和list列表类型类似，都可以用来存储多个字符串元素的集合。2.但是和list不同的是set集合当中不允许重复的元素。而且set集合当中元素是没有顺序的，不存在元素下标。3.redis的set类型是使用哈希表构造的，因此复杂度是O(1)，它支持集合内的增删改查，  并且支持多个集合间的交集、并集、差集操作。可以利用这些集合操作，解决程序开发过程当中很多数据集合间的问题。

应用场景

4  sorted set（有序集合）

redis有序集合也是集合类型的一部分，所以它保留了集合中元素不能重复的特性，但是不同的是，有序集合给每个元素多设置了一个分数，利用该分数作为排序的依据。

应用场景

5  hash（哈希）

  Redis hash数据结构 是一个键值对（key-value）集合,它是一个 string 类型的 field 和 value 的映射表，redis本身就是一个key-value型数据库，因此hash数据结构相当于在value中又套了一层key-value型数据。所以redis中hash数据结构特别适合存储关系型对象

应用场景

四  五大基本类型底层数据存储结构

/* * 字典 */typedef struct dictEntry {    // 键    void *key;    // 值    union {        // 指向具体redisObject        void *val;        //         uint64_t u64;        int64_t s64;    } v;    // 指向下个哈希表节点，形成链表    struct dictEntry *next;} dictEntry;

1  redisObject

/* * Redis 对象 */typedef struct redisObject {    // 类型 4bits    unsigned type:4;    // 编码方式 4bits    unsigned encoding:4;    // LRU 时间（相对于 server.lruclock） 24bits    unsigned lru:22;    // 引用计数 Redis里面的数据可以通过引用计数进行共享 32bits    int refcount;    // 指向对象的值 64-bit    void *ptr;} robj;

 REDIS_ENCODING_INT（long 类型的整数） REDIS_ENCODING_EMBSTR embstr （编码的简单动态字符串） REDIS_ENCODING_RAW （简单动态字符串） REDIS_ENCODING_HT （字典） REDIS_ENCODING_LINKEDLIST （双端链表） REDIS_ENCODING_ZIPLIST （压缩列表） REDIS_ENCODING_INTSET （整数集合） REDIS_ENCODING_SKIPLIST （跳跃表和字典）

2  String数据结构

• 当保存的值为整数且值的大小不超过long的范围，使用整数存储

• 当字符串长度不超过44字节时，使用EMBSTR 编码

• 大于44字符时，使用raw编码

SDS

/* 针对不同长度整形做了相应的数据结构 * Note: sdshdr5 is never used, we just access the flags byte directly. * However is here to document the layout of type 5 SDS strings.  */struct __attribute__ ((__packed__)) sdshdr5 {    unsigned char flags; /* 3 lsb of type, and 5 msb of string length */    char buf[];};
struct __attribute__ ((__packed__)) sdshdr8 {    uint8_t len; /* used */    uint8_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};
struct __attribute__ ((__packed__)) sdshdr16 {    uint16_t len; /* used */    uint16_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};
struct __attribute__ ((__packed__)) sdshdr32 {    uint32_t len; /* used */    uint32_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};
struct __attribute__ ((__packed__)) sdshdr64 {    uint64_t len; /* used */    uint64_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};

typedef struct redisObject {    // 类型 4bits    unsigned type:4;    // 编码方式 4bits    unsigned encoding:4;    // LRU 时间（相对于 server.lruclock） 24bits    unsigned lru:22;    // 引用计数 Redis里面的数据可以通过引用计数进行共享 32bits    int refcount;    // 指向对象的值 64-bit    void *ptr;} robj;

struct __attribute__ ((__packed__)) sdshdr8 {    uint8_t len; /* used */    uint8_t alloc; /* excluding the header and null terminator */    unsigned char flags; /* 3 lsb of type, 5 unused bits */    char buf[];};

3  List存储结构

1. Redis3.2之前的底层实现方式：压缩列表ziplist 或者 双向循环链表linkedlist
   
   

• list中保存的每个元素的长度小于 64 字节；
• 列表中数据个数少于512个

ziplist

快速列表（quickList）

typedef struct quicklist {    // 指向quicklist的头部    quicklistNode *head;    // 指向quicklist的尾部    quicklistNode *tail;    unsigned long count;    unsigned int len;    // ziplist大小限定，由list-max-ziplist-size给定    int fill : 16;    // 节点压缩深度设置，由list-compress-depth给定    unsigned int compress : 16;} quicklist;
typedef struct quicklistNode {    // 指向上一个ziplist节点    struct quicklistNode *prev;    // 指向下一个ziplist节点    struct quicklistNode *next;    // 数据指针，如果没有被压缩，就指向ziplist结构，反之指向quicklistLZF结构    unsigned char *zl;    // 表示指向ziplist结构的总长度(内存占用长度)    unsigned int sz;    // ziplist数量    unsigned int count : 16;     /* count of items in ziplist */    unsigned int encoding : 2;   /* RAW==1 or LZF==2 */    // 预留字段，存放数据的方式，1--NONE，2--ziplist    unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */    // 解压标记，当查看一个被压缩的数据时，需要暂时解压，标记此参数为1，之后再重新进行压缩    unsigned int recompress : 1; /* was this node previous compressed? */    unsigned int attempted_compress : 1; /* node can't compress; too small */    // 扩展字段    unsigned int extra : 10; /* more bits to steal for future usage */} quicklistNode;
typedef struct quicklistLZF {    // LZF压缩后占用的字节数    unsigned int sz; /* LZF size in bytes*/    // 柔性数组，存放压缩后的ziplist字节数组    char compressed[];} quicklistLZF;

4  Hash类型

hash-max-ziplist-entries 512hash-max-ziplist-value 64

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;
typedef struct dictht {    //指针数组，这个hash的桶    dictEntry **table;    //元素个数    unsigned long size;    unsigned long sizemask;    unsigned long used;} dictht;
dictEntry大家应该熟悉，在上面有讲，使用来真正存储key->value的地方typedef struct dictEntry {    // 键    void *key;    // 值    union {        // 指向具体redisObject        void *val;        //         uint64_t u64;        int64_t s64;    } v;    // 指向下个哈希表节点，形成链表    struct dictEntry *next;} dictEntry;

5  渐进式rehash

6  set数据结构

• 存储的数据都是整数
• 存储的数据元素个数小于512个

inset结构体

typedef struct intset {    uint32_t encoding;    // length就是数组的实际长度    uint32_t length;    // contents 数组是实际保存元素的地方，数组中的元素有以下两个特性：    // 1.没有重复元素    // 2.元素在数组中从小到大排列    int8_t contents[];} intset;
// encoding 的值可以是以下三个常量的其中一个#define INTSET_ENC_INT16 (sizeof(int16_t))#define INTSET_ENC_INT32 (sizeof(int32_t))#define INTSET_ENC_INT64 (sizeof(int64_t))

7  Zset数据结构

ziplist做排序

skiplist跳表

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

redis跳跃表

• header:指向跳跃表的表头节点，通过这个指针程序定位表头节点的时间复杂度就为O(1)；

• tail:指向跳跃表的表尾节点,通过这个指针程序定位表尾节点的时间复杂度就为O(1)；

• level:记录目前跳跃表内,层数最大的那个节点的层数(表头节点的层数不计算在内)，通过这个属性可以再O(1)的时间复杂度内获取层高最好的节点的层数；

• length:记录跳跃表的长度,也即是,跳跃表目前包含节点的数量(表头节点不计算在内)，通过这个属性，程序可以再O(1)的时间复杂度内返回跳跃表的长度。

• 层(level):

• 后退(backward)指针：

• 分值(score):

• 成员对象(oj):

五  三大特殊数据类型

1  geospatial（地理位置）

1.geospatial将指定的地理空间位置（纬度、经度、名称）添加到指定的key中。  这些数据将会存储到sorted set这样的目的是为了方便使用GEORADIUS或者GEORADIUSBYMEMBER命令对数据进行半径查询等操作。2.sorted set使用一种称为Geohash的技术进行填充。经度和纬度的位是交错的，以形成一个独特的52位整数。  sorted set的double score可以代表一个52位的整数，而不会失去精度。（有兴趣的同学可以学习一下Geohash技术，使用二分法构建唯一的二进制串）3.有效的经度是-180度到180度  有效的纬度是-85.05112878度到85.05112878度

应用场景

1. 查看附近的人
2. 微信位置共享
3. 地图上直线距离的展示

2  Hyperloglog（基数）

hyperloglog 是用来做基数统计的，其优点是：输入的提及无论多么大，hyperloglog使用的空间总是固定的12KB ，利用12KB，它可以计算2^64个不同元素的基数！非常节省空间！但缺点是估算的值，可能存在误差

应用场景

1. 网页统计UV （浏览用户数量，同一天同一个ip多次访问算一次访问，目的是计数，而不是保存用户）

3  Bitmaps（位存储）

Redis提供的Bitmaps这个“数据结构”可以实现对位的操作。Bitmaps本身不是一种数据结构，实际上就是字符串，但是它可以对字符串的位进行操作。可以把Bitmaps想象成一个以位为单位数组，数组中的每个单元只能存0或者1，数组的下标在bitmaps中叫做偏移量。单个bitmaps的最大长度是512MB，即2^32个比特位。

应用场景

六  Redis事务

1  数据库事务与redis事务

数据库的事务

redis事务

• Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。

• 因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

事务监控

七  Redis持久化

• RDB持久化方式会在一个特定的间隔保存那个时间点的数据快照。

• AOF持久化方式则会记录每一个服务器收到的写操作。在服务启动时，这些记录的操作会逐条执行从而重建出原来的数据。写操作命令记录的格式跟Redis协议一致，以追加的方式进行保存。

• Redis的持久化是可以禁用的，就是说你可以让数据的生命周期只存在于服务器的运行时间里。

• 两种方式的持久化是可以同时存在的，但是当Redis重启时，AOF文件会被优先用于重建数据。

1  RDB持久化

工作原理

1. Redis 调用forks。同时拥有父进程和子进程。
   
   
2. 子进程将数据集写入到一个临时 RDB 文件中。
   
   
3. 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
   
   

触发机制

1. save命令是同步的命令，会占用主进程，会造成阻塞，阻塞所有客户端的请求

2. bgsave
   
   

1. save自动触发配置，见下面配置，满足m秒内修改n次key，触发rdb
   
   

# 时间策略   save m n m秒内修改n次key，触发rdbsave 900 1save 300 10save 60 10000
# 文件名称dbfilename dump.rdb
# 文件保存路径dir /home/work/app/redis/data/
# 如果持久化出错，主进程是否停止写入stop-writes-on-bgsave-error yes
# 是否压缩rdbcompression yes
# 导入时是否检查rdbchecksum yes

2. 从节点全量复制时，主节点发送rdb文件给从节点完成复制操作，主节点会触发bgsave命令；
   
   
3. 执行flushall命令，会触发rdb
   
   
4. 退出redis，且没有开启aof时

1. RDB 的内容为二进制的数据，占用内存更小，更紧凑，更适合做为备份文件；
   
   
2. RDB 对灾难恢复非常有用，它是一个紧凑的文件，可以更快的传输到远程服务器进行 Redis 服务恢复；
   
   
3. RDB 可以更大程度的提高 Redis 的运行速度，因为每次持久化时 Redis 主进程都会 fork() 一个子进程，进行数据持久化到磁盘，Redis 主进程并不会执行磁盘 I/O 等操作；
   
   
4. 与 AOF 格式的文件相比，RDB 文件可以更快的重启。
   
   

1. 因为 RDB 只能保存某个时间间隔的数据，如果中途 Redis 服务被意外终止了，则会丢失一段时间内的 Redis 数据。
   
   
2. RDB 需要经常 fork() 才能使用子进程将其持久化在磁盘上。如果数据集很大，fork() 可能很耗时，并且如果数据集很大且 CPU 性能不佳，则可能导致 Redis 停止为客户端服务几毫秒甚至一秒钟。

2  AOF（Append Only File）

AOF配置项

# 默认不开启aof  而是使用rdb的方式appendonly no
# 默认文件名appendfilename "appendonly.aof"
# 每次修改都会sync 消耗性能# appendfsync always# 每秒执行一次 sync 可能会丢失这一秒的数据appendfsync everysec# 不执行 sync ,这时候操作系统自己同步数据，速度最快# appendfsync no

AOF 重写机制

触发方式

1. 手动触发：bgrewriteaof  
   
   
2. 自动触发 就是根据配置规则来触发，当然自动触发的整体时间还跟Redis的定时任务频率有关系。

3  rdb与aof对比

八  发布与订阅

1  频道（channel）

订阅

发布

完整流程

127.0.0.1:6379> publish channel:1 hi(integer) 1

127.0.0.1:6379> subscribe channel:1Reading messages... (press Ctrl-C to quit)1) "subscribe" // 消息类型2) "channel:1" // 频道3) "hi" // 消息内容

• subscribe。表示订阅成功的反馈信息。第二个值是订阅成功的频道名称，第三个是当前客户端订阅的频道数量。

• message。表示接收到的消息，第二个值表示产生消息的频道名称，第三个值是消息的内容。

• unsubscribe。表示成功取消订阅某个频道。第二个值是对应的频道名称，第三个值是当前客户端订阅的频道数量，当此值为0时客户端会退出订阅状态，之后就可以执行其他非"发布/订阅"模式的命令了。

数据结构

struct redisServer {    // ...    dict *pubsub_channels;    // ...};

2  模式（pattern）

订阅发布完整流程

127.0.0.1:6379> publish b m1(integer) 1127.0.0.1:6379> publish b1 m1(integer) 1127.0.0.1:6379> publish b11 m1(integer) 1

127.0.0.1:6379> psubscribe b*Reading messages... (press Ctrl-C to quit)1) "psubscribe"2) "b*"3) (integer) 31) "pmessage"2) "b*"3) "b"4) "m1"1) "pmessage"2) "b*"3) "b1"4) "m1"1) "pmessage"2) "b*"3) "b11"4) "m1"
 

数据结构

pattern属性是一个链表，链表中保存着所有和模式相关的信息。

struct redisServer {    // ...    list *pubsub_patterns;    // ...};// 链表中的每一个节点结构如下，保存着客户端与模式信息typedef struct pubsubPattern {    redisClient *client;    robj *pattern;} pubsubPattern;

def PUBLISH(channel, message):    # 遍历所有订阅频道 channel 的客户端    for client in server.pubsub_channels[channel]:        # 将信息发送给它们        send_message(client, message)    # 取出所有模式，以及订阅模式的客户端    for pattern, client in server.pubsub_patterns:        # 如果 channel 和模式匹配        if match(channel, pattern):            # 那么也将信息发给订阅这个模式的客户端            send_message(client, message)

九  主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。2.前者称为主节点(master)，后者称为从节点(slave)；数据的复制是单向的，只能由主节点到从节点默认情况下，每台redis服务器都是主节点；且一个主节点可以有多个从节点（或者没有），但一个从节点只有一个主

• 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

• 故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

• 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

• 高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

1  原理

2  全量复制的三个阶段

十  哨兵机制

1. 对于节点的故障判断是由多个Sentinel节点共同完成，这样可以有效地防止误判
   
   
2. 即使个别Sentinel节点不可用，整个Sentinel集群依然是可用的。

1. 监控：每个Sentinel节点会对数据节点（Redis master/slave 节点）和其余Sentinel节点进行监控
   
   
2. 通知：Sentinel节点会将故障转移的结果通知给应用方
   
   
3. 故障转移：实现slave晋升为master，并维护后续正确的主从关系
   
   
4. 配置中心：在Redis Sentinel模式中，客户端在初始化的时候连接的是Sentinel节点集合，从中获取主节点信息
   
   

1  原理

监控

1. 监控主从拓扑信息：每隔10秒，每个Sentinel节点，会向master和slave发送INFO命令获取最新的拓扑结构
   
   
2. Sentinel节点信息交换：每隔2秒，每个Sentinel节点，会向Redis数据节点的__sentinel__:hello频道上，发送自身的信息，以及对主节点的判断信息。这样，Sentinel节点之间就可以交换信息
   
   
3. 节点状态监控：每隔1秒，每个Sentinel节点，会向master、slave、其余Sentinel节点发送PING命令做心跳检测，来确认这些节点当前是否可达
   
   

主观/客观下线

哨兵选举

1. 每个Sentinel节点都有资格成为领导者，当它主观认为某个数据节点宕机后，会向其他Sentinel节点发送sentinel is-master-down-by-addr命令，要求自己成为领导者；
   
   
2. 收到命令的Sentinel节点，如果没有同意过其他Sentinel节点的sentinelis-master-down-by-addr命令，将同意该请求，否则拒绝（每个Sentinel节点只有1票）；
   
   
3. 如果该Sentinel节点发现自己的票数已经大于等于MAX(quorum, num(sentinels)/2+1)，那么它将成为领导者；
   
   
4. 如果此过程没有选举出领导者，将进入下一次选举。

故障转移

1. 跟master断开连接的时长：如果一个slave跟master的断开连接时长已经超过了down-after-milliseconds的10倍，外加master宕机的时长，那么该slave就被认为不适合选举为master；
   
   
2. slave的优先级配置：slave priority参数值越小，优先级就越高；
   
   
3. 复制offset：当优先级相同时，哪个slave复制了越多的数据（offset越靠后），优先级越高；
   
   
4. run id：如果offset和优先级都相同，则哪个slave的run id越小，优先级越高。
   
   

十一  缓存穿透、击穿、雪崩

1  缓存穿透

• 问题来源

• 解决方案
  
  

1. 接口层增加校验，如用户鉴权校验，id做基础校验，id<=0的直接拦截；
   
   
2. 从缓存取不到的数据，在数据库中也没有取到，这时也可以将key-value对写为key-null，缓存有效时间可以设置短点，如30秒（设置太长会导致正常情况也没法使用）。这样可以防止攻击用户反复用同一个id暴力攻击。
   
   
3. 布隆过滤器。类似于一个hash set，用于快速判某个元素是否存在于集合中，其典型的应用场景就是快速判断一个key是否存在于某容器，不存在就直接返回。布隆过滤器的关键就在于hash算法和容器大小。

2  缓存击穿

• 问题来源

• 解决方案

3  缓存雪崩

• 问题来源

• 解决方案

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

推荐专栏

------------------ END ------------------

关注公众号，获取更多精彩内容