Redis基础入门知识

 

Redis是非关系型的数据库

1、关系型数据库SQL与非关系型数据库NoSQL的区别：

SQL的特点：

1、以表格的形式存储格式化的数据，是一个二维表的数据结构

2、严格遵循数据格式和长度的规范

3、表与表之间存在关联关系（主键、外键【都是相对的关系】）

4、数据以行为单位，一行数据表示一个实体类，每一行的数据属性是相同的

优点：易理解、操作方便、数据一致性、数据稳定、服务稳定。

缺点：高并发下IO压力大、为维护索引付出的代价大、为维护数据的一致性付出的代价大、水平扩展困难、表结构扩展不方便、全文搜索功能弱

 

KV型的NoSQL（Not Only SQL，这里主要讲解的就是redis）的特点：

1、以键值对进行存储

优点：数据基于内存，读写的效率高；KV型数据，时间复杂度为O(1)，查询速度快

缺点：只能根据K查询V，查询方式单一，内存有限，无法支持海量的数据存储，由于是基于内存进行存储，会有丢失数据的风险。

这种搜索型的NoSQL最适合的场景就是：有条件搜索尤其是全文的搜索。

 

  

2、Redis的特性

相关的网站：

中文网站：https://www.redis.net.cn/

官方网站：https://redis.io/

1、基于内存存储，读写速度快

2、支持数据的持久化，过期策略；持久化：可以将内存中的数据保存到磁盘中，重启时进行加载使用；过期策略：在保存数据的时候设置数据的过期时间，一旦数据过期就会从内存中删除掉。

3、支持存储多种的数据类型：List、Set、ZSet、Hash.........

4、支持数据的备份，即master-slave模式

5、支持事务，redis中的所有操作都是原子性的，同时Redis支持对几个操作合并之后的原子性操作【单线程的】。

6、支持多种编程语言。

7、高可用，集群操作配置简单。

 

3、redis中常用的数据类型

默认有16个库【0=15】

String字符串，List集合 、Set集合、HSet、Hash

参考命令：http://redisdoc.com/index.html

存储原理：redis 是KV键值对存储的数据库，通过hashtable 实现，所以每个键值对都会有一个dictEntry，里面指向了key 和 value的指针。next指向的是下一个dictEntry键值对节点.

对应的dictEntry源码：

typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;
} dictEntry;

typedef struct redisObject {
    unsigned type:4;     //对象的类型，OBJ_STRING/OBJ_LIST/OBJ_HASH/OBJ_SET/OBJ_ZSET
    unsigned encoding:4;   //具体的数据结构编码
    unsigned lru:LRU_BITS; /* 内存淘汰策略：
                              LRU time 最近被使用 (relative to global lru_clock) or
                            * LFU data 最近的使用频率(least significant 8 bits frequency
                            * and most significant 16 bits access time). */
    int refcount;     /*引用计数，当refcount为0 时，表示该对象已经不被任何对象引用，可以进行垃圾回收*/
    void *ptr;     /*指向对象实际的数据结构*/
} robj;

dictEntry的结构图：

对应的redisObject 源码：

3.1 String字符串类型

用来存储字符串，整型、浮点型。

内部编码有三种：

1、int类型，存储8个字节的长度（long，2^63-1）

2、embstr，代表embstr格式的SDS（Simple Dynamic String简单动态字符串）,存储小于44个字节的字符串。

3、raw，存储大于44个字节的字符串

 

SDS（Simple Dynamic String）是什么？ 

是redis中使用最多的一个基础字符串数据结构，

Redis中的字符串的实现

为什么Redis要用SDS实例？

在C语言中本身是没有字符串类型的，只能使用字符数组char[]来实现。

     1、使用字符数组必须给目标变量分配足够的空间，否则会出现溢出的现象。

     2、如果要获取字符的长度，必须遍历字符数组，时间的复杂度就是O(n)。

     3、字符串长度的变更会对字符数组重新进行内存分配。

     4、通过从字符串开始到结束碰到的第一个'\0'来标记字符串的结束，因此不能保存图片，音频，视频，压缩文件等二进制bytes保存的内容，二进制不安全。

 

SDS的特点：

1、可以动态扩展内存，SDS表示的字符串内容可以进行修改，也可以追加，不用担心内存溢出的问题，如果需要SDS会自动进行扩容。

2、二进制安全（Binary Safe）的数据结构，sds 可以存储任意的二进制数据，而不仅仅是可打印的字符。

3、获取字符串长度的时间复杂度为O(1)，因为其中有len属性，用来存储当前字符数组的长度。

4、通过空间预分配和惰性空间释放，防止多次重新分配内存。

5、判断是否结束的标志是len属性。

 

embstr和raw的区别？

embstr是只读的，使用只分配一次内存空间，删除只释放一次空间，（RedisObject和SDS是连续的）寻找方便，而raw需要分配两次内存空间（分别为RedisObject和SDS分配空间）。

int与embstr什么时候转化为raw？

当int数据不再是整数，或者大小超过了long的范围时，自动转换成embstr。 只要对embstr类型的数据进行修改都会转化为raw，无论是否超过44个字节。因为embstr是只读，只会对它分配一次内存。

 

String的应用场景

缓存、分布式Session、实现分布式锁、incr  全局ID、计数器、限流、位操作

 

3.2 Hash哈希类型

存储类型：包含键值对的无序散列表，value只能是字符串，不能嵌套其他的类型

hash 与 String的主要区别？

将所有的相关的值聚集到一个key中，节省空间，减少key冲突，获取值时只需要使用一个命令，减少内存、IO、CPU的消耗。

但是不能单独设置过期时间，不能进行位操作，需要考虑数据量分布的问题。

 

hash的存储结构

1、ziplist压缩列表：OBJ_ENCODING_ZIPLIST

2、hash哈希表：OBJ_ENCODING_HT

ziplist 是一个经过特殊编码的双向链表，不存储指向上一个链表节点和下一个链表节点的指针，而是存储上一个节点和当前节点的长度，牺牲了部分的读写性能，来换取高效的内存空间利用率，是一种时间 欢空间的思想。只用在字段个数少，字段值小的场景。

hashtable被称为数据字段dictionary，是一个数组+链表的结构。

从最高层到最底层分别为：

OBJ_ENCODING_HT--->dict--->dictht--->dictEntry

typedef struct dictEntry {
    void *key;
    union {
        void *val;
        uint64_t u64;
        int64_t s64;
        double d;
    } v;
    struct dictEntry *next;
} dictEntry;
 
typedef struct dictType {
    uint64_t (*hashFunction)(const void *key);
    void *(*keyDup)(void *privdata, const void *key);
    void *(*valDup)(void *privdata, const void *obj);
    int (*keyCompare)(void *privdata, const void *key1, const void *key2);
    void (*keyDestructor)(void *privdata, void *key);
    void (*valDestructor)(void *privdata, void *obj);
} dictType;
 
/* This is our hash table structure. Every dictionary has two of this as we
 * implement incremental rehashing, for the old to the new table. */
typedef struct dictht {
    dictEntry **table;
    unsigned long size;
    unsigned long sizemask;
    unsigned long used;
} dictht;
 
typedef struct dict {
    dictType *type;
    void *privdata;
    dictht ht[2];
    long rehashidx; /* rehashing not in progress if rehashidx == -1 */
    unsigned long iterators; /* number of iterators currently running */
} dict;

 

什么时候使用ziplist存储？

当所有的键值对的键和值的字符串长度都小于或等于64byte；哈希 对象保存的键值对数量小于512个。

 

何时触发扩容？

static int dict_can_resize = 1;
static unsigned int dict_force_resize_ratio = 5;

dict_force_resize_ratio = used/size  已经使用的节点/字典大小，当比例大小超过5并且dict_can_resize = 1 的时候就会触发扩容操作。

扩容判断：

static int _dictExpandIfNeeded(dict *d)
{
    /* Incremental rehashing already in progress. Return. */
    if (dictIsRehashing(d)) return DICT_OK;
 
    /* If the hash table is empty expand it to the initial size. */
    if (d->ht[0].size == 0) return dictExpand(d, DICT_HT_INITIAL_SIZE);
 
    /* If we reached the 1:1 ratio, and we are allowed to resize the hash
     * table (global setting) or we should avoid it but the ratio between
     * elements/buckets is over the "safe" threshold, we resize doubling
     * the number of buckets. */
    if (d->ht[0].used >= d->ht[0].size &&
        (dict_can_resize ||
         d->ht[0].used/d->ht[0].size > dict_force_resize_ratio))
    {
        return dictExpand(d, d->ht[0].used*2);
    }
    return DICT_OK;
}

扩容操作：

/* Expand or create the hash table */
int dictExpand(dict *d, unsigned long size)
{
    /* the size is invalid if it is smaller than the number of
     * elements already inside the hash table */
    if (dictIsRehashing(d) || d->ht[0].used > size)
        return DICT_ERR;
 
    dictht n; /* the new hash table */
    unsigned long realsize = _dictNextPower(size);
 
    /* Rehashing to the same table size is not useful. */
    if (realsize == d->ht[0].size) return DICT_ERR;
 
    /* Allocate the new hash table and initialize all pointers to NULL */
    n.size = realsize;
    n.sizemask = realsize-1;
    n.table = zcalloc(realsize*sizeof(dictEntry*));
    n.used = 0;
 
    /* Is this the first initialization? If so it's not really a rehashing
     * we just set the first hash table so that it can accept keys. */
    if (d->ht[0].table == NULL) {
        d->ht[0] = n;
        return DICT_OK;
    }
 
    /* Prepare a second hash table for incremental rehashing */
    d->ht[1] = n;
    d->rehashidx = 0;
    return DICT_OK;
}

 

应用场景：

存储对象类型或者表数据，例如收藏夹，购物车，

 

 

3.3 List列表

存储类型：有序的字符串，可以重复，从左到右，左边是列表头；

3.2版本之后 就使用quicklist来存储（链表+ziplist），是一个双向的链表，每个节点都是一个ziplist。

typedef struct quicklist {
    quicklistNode *head;
    quicklistNode *tail;
    unsigned long count;        /* total count of all entries in all ziplists */
    unsigned long len;          /* number of quicklistNodes */
    int fill : 16;              /* fill factor for individual nodes */
    unsigned int compress : 16; /* depth of end nodes not to compress;0=off */
} quicklist;

typedef struct quicklistNode {
    struct quicklistNode *prev;
    struct quicklistNode *next;
    unsigned char *zl;
    unsigned int sz;             /* ziplist size in bytes */
    unsigned int count : 16;     /* count of items in ziplist */
    unsigned int encoding : 2;   /* RAW==1 or LZF==2 */
    unsigned int container : 2;  /* NONE==1 or ZIPLIST==2 */
    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;

 

使用场景

用来存储有序可重复的数据，例如用户的消息请求

 

3.4 set无序集合

存储结构：intset、hashtable存储无序，不可重复的String类型数据集合，如果元素都是整数类型的就使用inset类型存储，否则 使用hashtable类型数组+链表的存储结构。

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

应用场景：用户关注，推荐模型，点赞，商品标签

 

3.5 zset有序集合

存储结构：ziplist、 skiplist+dict

ziplist使用条件：元素的数量小于128个，所有的元素的长度都小于64个字节

否则就是：skiplist+dict来存储

typedef struct zlentry {
    unsigned int prevrawlensize; /* Bytes used to encode the previous entry len*/
    unsigned int prevrawlen;     /* Previous entry len. */
    unsigned int lensize;        /* Bytes used to encode this entry type/len.
                                    For example strings have a 1, 2 or 5 bytes
                                    header. Integers always use a single byte.*/
    unsigned int len;            /* Bytes used to represent the actual entry.
                                    For strings this is just the string length
                                    while for integers it is 1, 2, 3, 4, 8 or
                                    0 (for 4 bit immediate) depending on the
                                    number range. */
    unsigned int headersize;     /* prevrawlensize + lensize. */
    unsigned char encoding;      /* Set to ZIP_STR_* or ZIP_INT_* depending on
                                    the entry encoding. However for 4 bits
                                    immediate integers this can assume a range
                                    of values and must be range-checked. */
    unsigned char *p;            /* Pointer to the very start of the entry, that
                                    is, this points to prev-entry-len field. */
} zlentry;

/* ZSETs use a specialized version of Skiplists */
typedef struct zskiplistNode {
    sds ele;
    double score;
    struct zskiplistNode *backward;
    struct zskiplistLevel {
        struct zskiplistNode *forward;
        unsigned long span;
    } level[];
} zskiplistNode;
 
typedef struct zskiplist {
    struct zskiplistNode *header, *tail;
    unsigned long length;
    int level;
} zskiplist;
 
typedef struct zset {
    dict *dict;
    zskiplist *zsl;
} zset;

应用的场景：排序---排行榜

 

 

redis新加的数据类型

保存地理位置的信息：经度和纬度  geo的数据信息

geospatial

hyperloglogs ：用于奇数统计 

 

4、redis的发布订阅

1、传统的List类型的数据队列可以使用rpush和lpop来实现消息队列，但是不支持一对多的消息分发。

2、redis中提供了发布订阅模式，实现消息的发送接收。

A、消息订阅者可以订阅多个频道（channel）

subscribe  channel_name_1  channel_name_2  channel_name_3

消息发布者一次只能向一个频道发送消息

publish  channel_name_1  message

与rabbitMQ中的routing路由模式相似，但是rabbitMQ可以一次向多个队列发送消息

 

B、同时也提供使用占位符规则来订阅频道

？代表一个字符，*代表0个字符或多个字符

与rabbiyMQ中的topic模式类似。

 

5、redis的事务

redis中的命令是原子性的，涉及到多个命令的时候，需要将多个命令作为一个处理序列来执行，就需要使用事务；

redis中有两种方式执行事务

A、使用setnx实现分布式 锁，先set设置数据，指定过期时间，防止del发生的时候不会释放锁，业务完成后再del数据。

B、使用multi（开启事务），exec（执行事务），discard（取消事务），watch（监事）来执行事务。

set  key  value ----> watch  key---->multi---->相关的业务操作---->exec

 

watch命令为事务提供了CAS（Check and Set / Compare and Swap）乐观锁，多个线程在更新变量的时候，会与原值做比较，只有其他线程没有修改该变量的时候，才更新数据。可以同时监视多个key，开启事务之后，如果有一个key在exec执行之前被 修改了，整个事务都会被取消。可以使用unwatch来取消。

事务可能会遇到两种问题

A、在执行exec之前发生错误，队列中的所有的命令都得不到执行。

B、在执行exec之后发生错误，只有错误的命令得不到执行，其他的命令不受影响，并且该事务是不能进行回滚操作的。

 

 

6、使用Lua脚本调用redis命令

2.6版本之后就可以使用lua脚本中执行redis命令

1、一次发送多个命令，减少网络的开销

2、原子性

3、组合的复杂命令可以使用file存储，重复使用

执行命令：eval  "脚本名称"   参数与参数值   （eval  "test"  "value"）

lua脚本中执行redis命令

redis.call(command,key[param1\param2.....])

command：命令包括：set  get  del登

key：是被操作的键

param  代表给key的参数

eval  "returm redis.call('set', key[1],ARGV[1])"

 

7、Redis为什么会这么快？

A、KV结构的内存数据库，时间复杂度为O(1)

B、单线程：没有创建线程，销毁线程带来的消耗；避免了上下线文本切换带来的CPU消耗；避免了线程之间带来的竞争问题（加锁，释放锁，死锁）；

C、异步非阻塞I/O，多路复用处理并发连接

 

8、内存回收策略

redis中的所有数据都是存储在内存中的，需要对占用的内存空间进行回收。

有两种情况需要对内存进行回收：

A、key过期进行内存淘汰

B、内存达到上限触发内存淘汰

 

8.1、过期策略（针对Key值过期）

定时过期（主动淘汰），惰性过期（被动淘汰），定期过期

定时过期：设置了过期时间的key，到了过期的时间就会立即清除，对内存友好，但是会占用大量的CPU资源清除过期的数据，影响缓存的响应时间和吞吐量。

惰性过期：当访问一个key的时候才会判断这个key是否过期，对内存不友好，但是可以大量节省CPU的资源。

定期过期：每个一段时间，会扫描一定数量的expires中的key，并清除过期的key，是以上两种策略的折中方案。

 

8.2 淘汰策略（针对达到内存上限）

在redis.conf中进行参数配置：maxmemory   bytes，也可以进行动态的修改：config set maxmemory 4GB

# volatile-lru -> Evict using approximated LRU among the keys with an expire set.
# allkeys-lru -> Evict any key using approximated LRU.
# volatile-lfu -> Evict using approximated LFU among the keys with an expire set.
# allkeys-lfu -> Evict any key using approximated LFU.
# volatile-random -> Remove a random key among the ones with an expire set.
# allkeys-random -> Remove a random key, any key.
# volatile-ttl -> Remove the key with the nearest expire time (minor TTL)
# noeviction -> Don't evict anything, just return an error on write operations.
#
# LRU means Least Recently Used
# LFU means Least Frequently Used

LRU（Least Recently Used）最近最少使用，

    volatile-lru：删除设置了超时属性的键，直到腾出了足够的内存；

    allkeys-lru：不管有没有设置了超时属性，直到腾出足够的内存为止。

LFU（Least Frequently Used）最近最不常用

    volatile-lfu：在带有过期时间的键中选择最不常用的；

    allkeys-lfu：在所有的键中删除最不常用的，不管有没有设置超时属性。

random 随机

    volatile-random：随机删除设置了超时属性的键；

    allkeys-random：随机删除所有的键，直到腾出足够的内存为止；

volatile-ttl：删除最近将要过期的数据

noeviction：不会删除任何的数据，当进行写操作的时候返回一个错误提示。

 

9、持久化机制

由于reids的数据是存储在内存中的，如果宕机或者断点，内存中的数据就会丢失；

reids中有两种持久话的方案：RDB（默认）、AOF

9.1 RDB

RDB可以手动触发（执行save，bgsave）和自动触发（需要配置触发方案；showdown服务），将内存中的数据写入磁盘，生成一个快照文件dump.rdb。redis在重启的时候就会加载dump.rdb文件进行数据的恢复。

#以下配置不冲突，只需要满足一个就会触发
save 900 1   #900秒内至少有一个key被修改（包括添加）
save 300 10   #300秒内至少有10个key被修改
save 60 10000   #60秒内至少有10000个key被修改
 
# Compress string objects using LZF when dump .rdb databases?
# For default that's set to 'yes' as it's almost always a win.
# If you want to save some CPU in the saving child set it to 'no' but
# the dataset will likely be bigger if you have compressible values or keys.
 
#是否是LZF压缩rdb文件
rdbcompression yes
 
# Since version 5 of RDB a CRC64 checksum is placed at the end of the file.
# This makes the format more resistant to corruption but there is a performance
# hit to pay (around 10%) when saving and loading RDB files, so you can disable it
# for maximum performances.
#
# RDB files created with checksum disabled have a checksum of zero that will
# tell the loading code to skip the check.
 
#开启数据校验
rdbchecksum yes
 
# The filename where to dump the DB
dbfilename dump.rdb
 
# The working directory.
#
# The DB will be written inside this directory, with the filename specified
# above using the 'dbfilename' configuration directive.
#
# The Append Only File will also be created inside this directory.
#
# Note that you must specify a directory here, not a file name.
dir ./

 

手动触发中save与bgsave的区别：

save：在生成快照的时候会阻塞当前redis服务器，redis不能处理其他的命令。如果内存中的数据比较多的时候，就会造成redis长期的阻塞。

bgsave：reids会在后台进行异步快照操作，同时还可以响应客户端的请求。进程会fork操作，创建子进程，rdb的持久化操作就交给了子进程进行。阻塞只发生在fork阶段，一般时间都比较的短。

 

优点：数据紧凑，保存了在某个时间点上的数据；在生成rdb文件的时候，交给了子进程，主进程不需要进行任何的磁盘IO操作；在有大量的数据时，恢复速度快；

劣势：不是实时持久化，需要间隔一段时间进行备份（期间数据可能会丢失），因为每次bgsave保存数据时，都会fork创建子进程，频繁的执行，成本太高。

 

9.2 AOF

开启AOF方式之后，在执行redis数据更改的时候，就会把命令写入到AOF文件中，重启redis的时候，会执行所有的操作来完成数据的恢复。

#默认不开启
appendonly no
 
# The name of the append only file (default: "appendonly.aof")
 
#存储的文件名称
appendfilename "appendonly.aof"

由于操作系统是缓存机制的，AOF数据并没有真正的写入到硬盘，而是进入到了系统的硬盘缓存。

#no  表示不执行 fsync，由操作系统保证数据同步到磁盘，速度最快，但是不安全
#always  表示每次写入都执行fsync，以保证数据同步到磁盘，效率很低
#everysec  表示每秒执行一次fsync，可能导致丢失这一秒的数据，通常选择everysec，兼顾安全性和效率
 
# appendfsync always
appendfsync everysec
# appendfsync no   

当AOF文件的大小超过了设定的阀值时，就会启动AOF文件的内容压缩，只保留恢复数据的最小指令集。

# Automatic rewrite of the append only file.
# Redis is able to automatically rewrite the log file implicitly calling
# BGREWRITEAOF when the AOF log size grows by the specified percentage.
#
# This is how it works: Redis remembers the size of the AOF file after the
# latest rewrite (if no rewrite has happened since the restart, the size of
# the AOF at startup is used).
#
# This base size is compared to the current size. If the current size is
# bigger than the specified percentage, the rewrite is triggered. Also
# you need to specify a minimal size for the AOF file to be rewritten, this
# is useful to avoid rewriting the AOF file even if the percentage increase
# is reached but it is still pretty small.
#
# Specify a percentage of zero in order to disable the automatic AOF
# rewrite feature.
 
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

可以使用bgrewriteaof命令来重写，AOF重写并不是对原文的重新整理，而是拂去服务器中的键值对，然后用一条命令代替之前记录这个键值对的多条命令，生成一个新的文件去替换原来的AOF文件。

优点：AOF中提供了多种的同步频率，即使使用的是同步的频率每秒同步一次，redis最多也只丢失1秒的数据。

缺点：AOF文件就会比较大；在高并发的情况下，RDB比AOF具有更好的性能保障。