Redis基础知识

「爱情、让人受尽委屈。」 2022-09-03 00:12 200阅读 0赞

# Redis 入门 #

## redis 诞生历史 ##

08年的时候有一个意大利西西里岛的小伙子，创建了一个访客信息网站LLOOGG.COM。有的时候我们需要知道网站的访问情况，比如访客的IP、操作系统、浏然器、使用的搜索关键词、所在地区、访问的网页地址等等。  
它可以查看最多10000条最新浏览记录。这样的话，它需要为每个网站创建一个列表（List），不同的网站的访问记录进入到不同的列表。如果列表的长度超过了用户指定的长度，它需要把最早的记录删除（先进先出）。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70]  
当LLOOGG.COM的用户越来越多的时候，他需要维护的列表数量也越来越多，这种记录最新的请求和删除最早的请求的操作也越来越多。LLOOGG.COM最初使用的数据库是MYSQL，可想而知，因为每一次记录和删除多要读写磁盘，因为数据量和并发量太大，在这种情况下无论怎么去优化数据库都不管用了。  
为什么叫Redis呢？它的全称是Remote Dictionary Service，直接翻译过来就是远程字典服务。

## Redis 定位与特性 ##

### sql与NoSQL ###

在绝大部分时候，我们都会首先考虑用关系型数据库来存储我们的数据，比如SQLServer ，Oracle，MySQL等等。

关系型数据库的特点：  
1，它以表格的形式，基于行存储数据，是一个二维的模式  
2，它存储的是结构化的数据，数据存储有固定的模式（schema），数据需要适应表结构。  
3，表与表之间存在关联。  
4，大部分关系型数据库都支持SQL（结构化查询语言）的操作，支持复杂的关联查询。  
5，通过支持事务（ACID）来严格或者实时的数据一致性。

但是使用关系型数据库也存在一些限制，比如：  
1，要实现扩容的话，只能向上（垂直）扩展，比如磁盘限制了数据的存储，就要扩大磁盘容量，通过堆硬件的方式，不支持动态的扩缩容。水平扩容需要复杂的技术来实现，比如分库分表。  
2，表结构修改困难，因此存储的数据格式也受限制。  
3，在高并发和高数据量的情况下，我们的关系型数据库通常会把数据持久化到磁盘，基于磁盘的读写压力比较大。

非关系型数据库的特点：  
1，存储非结构化的数据，比如文本、图片、音频、视频。  
2，表与表之间没有关联，可扩展性强。  
3，保证数据的最终一致性。遵循BASE理论。Basically Available（基本可用）；Soft-state（软状态）；Eventually Consistent（最终一致性）  
4，支持海量数据的存储和高并发的高效读写。  
5，支持分布式，能够对数据进行分片存储，扩缩容简单。

对于不同的存储类型，我们又有各种各样的菲关系型数据库，比如有几种常见的类型：  
1，KV存储，用Key Value的形式来存储数据，比较常见的有Redis和MemcacheDB。  
2，文档存储，MongoDB。  
3，列存储，HBase。  
4，图存储，这个图（Graph）是数据结构，不是文件格式。Neo4j。  
5，对象存储。  
6，XML存储等等等。

## Redis特性 ##

硬件层面有CPU的缓存；浏然器也有缓存；手机的应用也有缓存。我们把数据缓存起来的原因就是从原始位置取数据的代价太大了，放在一个临时位置存储起来，取回就可以快些。  
Redis的特性：  
1）更丰富的数据类型。  
2）进程内与跨进程；单机与分布式。  
3）功能丰富：持久化机制、过期策略  
4）支持多种编程语言  
5）高可用，集群

## Redis基本数据类型 ##

最基本也是最常用的类型就是String。set和get命令就是String的操作命令。

## 存储实现原理 ##

### 数据模型 ###

set hello word为例，因为Redis是KV的数据库，它是通过hashtable实现的（我们把这个叫做外层的哈希）。所以每个键值对都会有一个dictEntry（源码位置：dict.h），里面指向了key和value的指正。next指向下一个dictEntry。

typedef struct dictEntry {
     void *key; /* key 关键字定义 */ 
     union {
          void *val;
          uint64_t u64; /* value 定义 */ 
          int64_t s64; 
          double d; } v; 
          struct dictEntry *next; /* 指向下一个键值对节点 */ } dictEntry;

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 1]  
key是字符串，但是Redis没有直接使用C的字符数组，而是存储在自定义的SDS中。  
value即不是直接作为字符串存储，也不是直接存储在SDS中，而是存储在redisObject中。实际上五种常用的数据类型的任何一种，都是通过redisObject来存储的。

### redisObject ###

redisObject定义在src/server.h文件中

typedef struct redisObject { 
    	unsigned type:4; /* 对象的类型，包括：OBJ_STRING、OBJ_LIST、OBJ_HASH、OBJ_SET、OBJ_ZSET */ 
    	unsigned encoding:4; /* 具体的数据结构 */ 
    	unsigned lru:LRU_BITS; /* 24 位，对象最后一次被命令程序访问的时间，与内存回收有关 */ 
    	int refcount; /* 引用计数。当 refcount 为 0 的时候，表示该对象已经不被任何对象引用，则可以进行垃圾回收了 */
    	void *ptr; /* 指向对象实际的数据结构 */ 
    } robj;

**可以用type命令来查看对外的类型**  
![在这里插入图片描述][c1613a4e875947d9871c7ac9d1af0005.png]

### 内部编码 ###

![在这里插入图片描述][aae968bac1ea4ea9ae38d16def833ff4.png]  
字符串类型的内部编码有三种：  
1，int，存储8个字节的长整形（long，2^63-1）  
2，embstr，代表embstr格式的SDS（Simple Dynamic String简单动态字符串），存储小于44个字节的字符串。  
3，raw，存储大于44个字节的字符串（3.2版本之前是39字节）

## 疑问 ##

### 什么是SDS？ ###

redis中字符串的实现。  
在3.2以后的版本中，SDS又有多种结构（sds.h）：sdshdr5、sdshdr8、sdshdr16、sdshdr32、sdshdr64，用于存储不同的长度的字符串，分别代表25=32byte，28=256byte，216=65536byte=64KB，232byte=4GB。

### 为什么Redis要用SDS实现字符串？ ###

我们知道，C语言本身没有字符串类型（只能用字符串数据char\[\]实现）。  
1，使用字符串数组必须先给目标变量分配足够的空间，否者可能溢出。  
2，如果要获取字符长度，必须遍历字符数组，时间复杂度是O（n）。  
3，C字符串长度变更会对字符数组做内存分配。  
4，通过从字符串开始到结尾碰到的第一个‘\\0’来标记字符串的结束，因此不能保存图片、音频、视频、压缩文件等二进制（bytes）保存的内容，而进制不安全。

SDS的特点：  
1，不用担心内存溢出问题，如果需要会对SDS进行扩容  
2，获取字符串长度时间复杂度为O(1)，因为定义了len属性。  
3，通过“空间预分配”（sdsMakeRoomFor）和“惰性空间释放”，防止多次分配内存。  
4，判断是否结束的标志是len属性（它同样以‘\\0’结尾是因为这样就可以使用C语言中函数库操作字符串的函数了），可以包含‘\\0’

### embstr和raw的区别？ ###

embstr的使用只分配一次内存空间（因为RedisObject和SDS是连续的），而raw需要分配两次内存空间（分别为RedisObject和SDS分配空间）。

因此与raw相比，embstr的好处在于创建时少分配一次空间，删除时少释放一次  
空间，以及对象所有的数据连在一起，寻找方便。

而embstr的坏处也很明显，如果字符串的长度增加需要重新分配内存时，整个RedisObject和SDS都需要重新分配空间，因此redis中embstr实现为只读。

## Hash 哈希 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 2]

### 存储类型 ###

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

同样是字符串，hash与string的主要区别？  
1，把所有相关的值聚集到一个key中，节省内存空间  
2，只使用一个key，减少key冲突  
3，当需要批量获取值的时候，只需要使用一个命令，减少内存/IO/CPU的消耗

Hash不适合的场景：  
1，Field不能单独设置过期时间  
2，没有bit操作  
3，需要考虑数据量分布的问题（value值非常大的时候，无法分布到过个节点）

**操作命令**

hset h1 a 1
    hmset h1 b 2 c 3
    hget h1 a
    hmget h1 a b  c 
    hkeys h1
    hvals h1
    hgetall h1

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 3]

### 存储实现原理 ###

redis的hash 本身也是一个kv的结构，类似于java中的hashMap。  
外层的哈希（Redis KV的实现）只用到了hashtable。当存储hash数据类型时，我们把它叫做内层的哈希。内层的hash底层可以使用两种数据结构实现：  
ziplist：OBJ\_ENCODING\_ZIPLIST(压缩列表)  
hashtable：OBJ\_ENCODING\_HT(哈希表)

hset h2 f aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
    
    hset h3 f aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 4]

### ziplist压缩列表 ###

The ziplist is a specially encoded dually linked list that is designed to be very memory efficient. It stores both strings and integer values, where integers are encoded as actual integers instead of a series of characters. It allows push and pop operations on either side of the list in O(1) time. However, because every operation requires a reallocation of the memory used by the ziplist, the actual complexity is related to the amount of memory used by the ziplist.

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

## List列表 ##

存储有序的字符串（从左到右），元素可以重复。可以充当队列和栈的角色。  
![在这里插入图片描述][f75a1cc3b52c4d4ea41f5a075db1cb38.png]

### 操作命令 ###

lpush queue a
    lpush queue b c
    rpush queue d e
    lpop queue
    rpop queue

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 5]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 6]

### 存储（实现）原理 ###

在早期的版本中，数据量较小的时候用ziplist存储，达到 临界值时转换为linkedlist进行存储，分别对应OBJ\_ENCODING\_ZIPLIST 和OBJ\_ENCODING\_LINKEDLIST。  
3.2版本之后，统一用quicklist来存储。quicklist存储了一个双向链表，每个节点都是一个ziplist。

![在这里插入图片描述][eecfe77fdb154ba0a331e5c9206b86b9.png]

### quicklist ###

quicklist（快速列表）是ziplist和linkedlist的结合体。  
quicklist.h，head和tail指向双向列表的表头和表尾  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 7]  
quicklistNode中的\*zl指向一个ziplist，一个ziplist可以存放多个元素  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 8]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 9]

### 应用场景 ###

用户消息时间线timeline  
因为list是有序的，可以用来做用户时间线

消息队列  
list提供了两个阻塞的弹出操作：BLPOP、BRPOP,可以设置超时时间。  
BLPOP：BLPOP key1 timeout 移出并获取列表的第一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹出元素为止。

BRPOP：BRPOP key1 timeout移出并获取列表的最后一个元素，如果列表没有元素会阻塞列表直到等待超时或发现可弹起元素为止。

队列：先进先出： rpush blpop

## Set 集合 ##

### 存储类型 ###

string 类型的无序集合，最大存储数量是2^32-1（40亿左右）。  
![在这里插入图片描述][882d970241fa4c7eb194453d04e61bfd.png]

## 操作命令 ##

//添加一个或者多个元素
    sadd setEvan  a b c d 
    //随机获取一个元素
    smembers setEvan
    //统计元素
    scard setEvan
    //随机获取一个元素
    srandmember setEvan
    移出一个或者多个元素
    spop setEvan
    查看元素是否存在
    sismember setEvan a

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 10]

### 存储原理 ###

Redis用intset或hashtable存储set。如果元素都是整数类型，就用inset存储。如果不是整数类型，就用hashtable（数组+链表的结构存储）  
如果元素超过512个，也会用hashtable来存储。

### 应用场景 ###

随机获取元素、抽奖  
点赞、签到、打卡

## ZSet 有序集合 ##

### 存储类型 ###

![在这里插入图片描述][9f6cbf0de2d94d6bbb27b16cb67cb685.png]

sorted set，有序的set，每个元素都有个score  
score相同时，按照key的ASCII排序。  
结构数据对比：  
![在这里插入图片描述][baa567f31bf045c7b8815f62cdcf998d.png]

### 操作命令 ###

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70]: /images/20220829/75985fe4f94b46bd9c1157bc530fda61.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 1]: /images/20220829/03fbe9409d594cd4a756dac44181150a.png
[c1613a4e875947d9871c7ac9d1af0005.png]: /images/20220829/079869ac95c34b7e9955fa547bc5dc9b.png
[aae968bac1ea4ea9ae38d16def833ff4.png]: /images/20220829/c18c083e126642d182b8549c9d63bb2a.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 2]: /images/20220829/814e1a6b73da45d6b1eb42381ee510d3.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 3]: /images/20220829/af30c5907ae340e6aca7fccf048b8474.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 4]: /images/20220829/337f66cf468f4568a797f219ab48cc40.png
[f75a1cc3b52c4d4ea41f5a075db1cb38.png]: /images/20220829/5651d7cfded24b0386e0938dbb11a30c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 5]: /images/20220829/458f3171d4d84ab59dfd1e0fd9effe96.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 6]: /images/20220829/411b56c06b2f45508adac69d8c4d64e6.png
[eecfe77fdb154ba0a331e5c9206b86b9.png]: /images/20220829/934bb172a6a64ef58d2a7ae19c7336a4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 7]: /images/20220829/4ef130375e7946ccaf47dd665ec83953.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 8]: /images/20220829/8e04defd016240e3ac54315486dbdf1c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 9]: /images/20220829/a8e40e5845294d0ea9f65651c2a9c7b5.png
[882d970241fa4c7eb194453d04e61bfd.png]: /images/20220829/89ff32b0a4324cad84e972b75b29302e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl8zMDQwOTkyNw_size_16_color_FFFFFF_t_70 10]: /images/20220829/183907b06a8740feb2369383f871e645.png
[9f6cbf0de2d94d6bbb27b16cb67cb685.png]: /images/20220829/689e25eb88384d048f3573d9ffaff1f5.png
[baa567f31bf045c7b8815f62cdcf998d.png]: /images/20220829/948e2f5370cd46748d35d6721aae6595.png