Redis概述与常用命令

桃扇骨 2022-02-13 11:47 219阅读 0赞

### 1. NoSQL概念 ###

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL，泛指非关系型的数据库。  
随着互联网的兴起，传统的关系数据库在应付超大规模和高并发的纯动态网站已经显得力不从心，NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。

### 2. NoSQL数据库的四大分类 ###

##### 键值(Key-Value)存储数据库 #####

这一类数据库主要会使用到一个哈希表，这个表中有一个特定的键和一个指针指向特定的数据。如：Redis

##### 列存储数据库 #####

通常是用来应对分布式存储的海量数据。键仍然存在，但是它们的特点是指向了多个列。如：Cassandra, HBase, Riak.

##### 文档型数据库 #####

文档型数据库可以看作是键值数据库的升级版，允许嵌套键值对。而且文档型数据库比键值数据库的查询效率更高。如：CouchDB, MongoDb。国内也有文档型数据库SequoiaDB，已经开源。

##### 图形(Graph)数据库 #####

图形结构的数据库同其他行列以及刚性结构的SQL数据库不同，它是使用灵活的图形模型，并且能够扩展到多个服务器上。

SQL: 结构化查询语言，它是一种统一的语言，所有的关系型数据库都支持SQL语句

NoSQL数据库没有标准的查询语言(SQL)，因此进行数据库查询需要制定数据模型。

### 3. 关系型数据库与非关系型数据库对比 ###

#### 关系型数据库 ####

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

关系型数据库最典型的数据结构是表，由二维表及其之间的联系所组成的一个数据组织

##### 优点： #####

1.  易于维护：都是使用表结构，格式一致；
2.  使用方便：SQL语言通用，可用于复杂查询；
3.  复杂操作：支持SQL，可用于一个表以及多个表之间非常复杂的查询。

##### 缺点： #####

1.  读写性能比较差，尤其是海量数据的高效率读写；
2.  固定的表结构，灵活度不佳；
3.  高并发读写需求，传统关系型数据库来说，硬盘I/O是一个很大的瓶颈。

#### 非关系型数据库 ####

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 1]

非关系型数据库严格上不是一种数据库，应该是一种数据结构化存储方法的集合，可以是文档或者键值对等。

##### 优点 #####

1.  格式灵活：存储数据的格式可以是key,value形式、文档形式、图片形式等等，文档形式、图片形式等等，使用灵活，应用场景广泛，而关系型数据库则只支持基础类型。
2.  速度快：nosql可以使用硬盘或者随机存储器作为载体，而关系型数据库只能使用硬盘；
3.  高扩展性；
4.  成本低：nosql数据库部署简单，基本都是开源软件。

##### 缺点 #####

1.  不提供sql支持，学习和使用成本较高；
2.  无事务处理；
3.  数据结构相对复杂，复杂查询方面不方便。

##### 疑问：非关系数据库存储什么样的数据呢？ #####

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

### 4. 使用NOSQL解决三高的问题： ###

#### High Performance - 数据库高并发访问 ####

在同一个时间点，同时有海量的用户并发访问。往往要达到每秒上万次读写请求。关系数据库应付上万次SQL查询还勉强顶得住，但是应付上万次SQL写数据请求，硬盘IO就已经无法承受了。

*  如天猫的双11，从凌晨0点到2点这段时间，每秒达到上千万次的访问量。
 *  12306春运期间，过年回家买火车抢票的时间，用户不断查询有没有剩余票。
 *  对于普通的BBS网站，往往也存在对高并发写请求的需求，例如网站的实时统计在线用户状态，记录热门帖子的点击次数，投票计数等，因此这是一个相当普遍的需求。

#### Huge Storage - 海量数据的存储 ####

数据库中数据量特别大，数据库表中每天产生海量的数据。

类似QQ，微信，微博，每天用户产生海量的用户动态，每天产生几千万条记录。对于关系数据库来说，在一张几亿条记录的表里面进行SQL查询，效率是极其低下乃至不可忍受的。

#### High Scalability && High Availability- 高可扩展性和高可用性的需求 ####

关系型数据库进行扩展和升级是比较麻烦的一样事，对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移。

非关系型数据库可以通过不断的添加服务器节点来实现扩展，而不需对原有的数据库进行维护。

### 5. redis是一种高级的key-value的存储系统，其中value支持五种数据类型 ###

##### ①字符串类型string #####

字符串类型是Redis中最为基础的数据存储类型，它在Redis中以二进制保存，没有字符编码和字符解码的过程。无论存入的是字符串、整数、浮点类型都会以字符串写入。在Redis中字符串类型的值最多可以容纳的数据长度是512M，这是以后最常用的数据类型。

**图解：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 3]

**常用命令：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 4]

##### ②Hash类型 #####

Hash类型可以看成是键和值都是String类型的Map容器，每一个Hash可以存储4G个键值对。  
该类型非常适合于存储对象的信息。如一个用户有姓名，密码，年龄等信息，则可以有username、password和age等键。它的存储结构如下：

**图解：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 5]  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 6]

**常用命令：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 7]

##### ③list类型 #####

在Redis中，List类型是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其左部(left)和右部(right)添加新的元素。在插入时，如果该键并不存在，Redis将为该键创建一个新的链表。与此相反，如果链表中所有的元素均被移除，那么该键也将会被从数据库中删除。List中可以包含的最大元素数量是4G个。

**图解：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 8]

**常用命令：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 9]

##### ④set类型 #####

在Redis中，我们可以将Set类型看作为没有排序的字符集合，和List类型一样，我们也可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。Set可包含的最大元素数量是4G，和List类型不同的是，Set集合中不允许出现重复的元素。

**图解：**![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 10]

**常用命令：**  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 11]

### 6. Redis的通用命令 ###

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 12]

### 6. Redis的持久化的两种方式：RDB、AOF ###

Redis持久化就是将内存中的数据写到硬盘文件中。

两种方式：

1.  RDB：Redis DataBase 以二进制的文件格式保存，这是它默认的格式。
2.  AOF：Append Only File，以文本文件保存的，记录用户的操作步骤。

### 7. RDB持久化机制优点 ###

1.  方便备份与恢复

整个Redis数据库将只包含一个文件，默认是dump.rdb，这对于文件备份和恢复而言是非常完美的。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。一旦系统出现灾难性故障，我们可以非常容易的进行恢复。

1.  性能最大化

对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是分叉出子进程，由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。

1.  启动效率更高

相比于AOF机制，如果数据集很大，RDB的启动效率会更高

### RDB持久化机制缺点 ###

1.  不能完全避免数据丢失

因为RDB是每隔一段时间写入数据，所以系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。

1.  会导致服务器暂停的现象

由于RDB是通过子进程来协助完成数据持久化工作的，因此当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。

### RDB持久化机制的配置 ###

在redis.windows.conf配置文件中的SNAPSHOTTING中有如下说明：

<table> 
 <thead> 
  <tr> 
   <th><strong>语法</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>save &lt;时间间隔&gt; &lt;修改键数&gt;</strong></td> 
   <td>同时满足这2个条件<br>在指定的时间内(单位是秒)，修改(增删改)了多少个键<br>就持久化写到硬盘文件中</td> 
  </tr> 
 </tbody> 
</table>

如下面配置的是RDB方式数据持久化时机，必须两个条件都满足的情况下才进行持久化的操作：

<table> 
 <thead> 
  <tr> 
   <th><strong>关键字</strong></th> 
   <th><strong>时间(秒)</strong></th> 
   <th><strong>修改键数</strong></th> 
   <th><strong>解释</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>save</strong></td> 
   <td><strong>900</strong></td> 
   <td><strong>1</strong></td> 
   <td>每过15分钟，修改了1个键就持久化</td> 
  </tr> 
  <tr> 
   <td><strong>save</strong></td> 
   <td><strong>300</strong></td> 
   <td><strong>10</strong></td> 
   <td>每过5分钟，修改了10个键就持久化</td> 
  </tr> 
  <tr> 
   <td><strong>save</strong></td> 
   <td><strong>60</strong></td> 
   <td><strong>10000</strong></td> 
   <td>每过1分钟，修改了1万个键就持久化</td> 
  </tr> 
 </tbody> 
</table>

### 演示：RDB持久化 ###

1.  修改redis.windows.conf 文件的101行  
    添加1行：save 20 3 (表示20秒内修改3个键，则写入到dump.rdb文件中)
2.  使用指定的配置文件启动服务器：redis-server redis.windows.conf
3.  向数据库中添加2个键，直接关闭服务器窗口。再开启服务器，查看所有的keys，刚才添加的数据丢失。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 13]
4.  在客户端添加3个键，发现服务器端有如下输出信息，表示写入到数据库dump.rdb文件中  
    ![在这里插入图片描述][20190427233737663.png]
5.  直接关闭服务器窗口，再开启服务器，查看所有的keys，数据没有丢失。  
    ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 14]

### 8. Redis的持久化：AOF的存储方式 ###

### AOF持久化机制优点 ###

AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。也可以通过该文件完成数据的重建。该机制可以带来更高的数据安全性，所有的操作都是异步完成的。

<table> 
 <thead> 
  <tr> 
   <th><strong>Redis中提供了3种同步策略</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>每秒同步</strong></td> 
   <td>每过1秒钟就保存1次</td> 
  </tr> 
  <tr> 
   <td><strong>每修改同步</strong></td> 
   <td>每修改1个键就保存1次</td> 
  </tr> 
  <tr> 
   <td><strong>不同步</strong></td> 
   <td>不保存</td> 
  </tr> 
 </tbody> 
</table>

### AOF持久化机制缺点 ###

1.  文件比RDB更大：对于相同数量的数据集而言，AOF文件通常要大于RDB文件。
2.  运行效率比RDB更慢：根据同步策略的不同，AOF在运行效率上往往会慢于RDB。

### AOF持久化机制配置 ###

#### 开启AOF持久化 ####

AOF默认是关闭的，首先需要开启AOF模式。如果打开会创建appendonly.aof文件

<table> 
 <thead> 
  <tr> 
   <th><strong>参数配置</strong></th> 
   <th><strong>说明</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>appendonly no/yes</strong></td> 
   <td>默认是关闭的，设置成yes就打开。如果开启了AOF，则rdb中数据会清除。</td> 
  </tr> 
 </tbody> 
</table>

#### AOF持久化时机 ####

<table> 
 <thead> 
  <tr> 
   <th><strong>关键字</strong></th> 
   <th><strong>持久化时机</strong></th> 
   <th><strong>解释</strong></th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td><strong>appendfsync</strong></td> 
   <td><strong>everysec</strong></td> 
   <td>每秒</td> 
  </tr> 
  <tr> 
   <td><strong>appendfsync</strong></td> 
   <td><strong>always</strong></td> 
   <td>每次修改</td> 
  </tr> 
  <tr> 
   <td><strong>appendfsync</strong></td> 
   <td><strong>no</strong></td> 
   <td>不保存</td> 
  </tr> 
 </tbody> 
</table>

### 演示：AOF的持久化 ###

1.  打开AOF的配置，找到APPEND ONLY MODE配置块，392行。设置appendonly yes
2.  通过redis-server redis.windows.conf 启动服务器，在服务器目录下出现appendonly.aof文件。大小是0个字节。
3.  添加3个键和值  
    ![在这里插入图片描述][20190427233900927.png]
4.  打开appendonly.aof文件，查看文件的变化。会发现文件记录了所有操作的过程。

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70]: /images/20220213/60917db16abf4e39863e159f6d0bc2b4.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 1]: /images/20220213/32dd0d7929c74333bc668a74480e99fb.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 2]: /images/20220213/fca7d64676cd4f308242dad36d47a88b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 3]: /images/20220213/a85c40e4656a4cae8d2b0859a3be979f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 4]: /images/20220213/cc494166e03d4a5dafe81e9360c3cbb1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 5]: /images/20220213/3ef3c5393bd944ebb97b167fb37d0b5b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 6]: /images/20220213/c1cb75a895a7417d903ecce04350c417.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 7]: /images/20220213/c536138e1d274897afb8e984a1781516.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 8]: /images/20220213/4f814a2461da4cbdaa68c6509b468af2.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 9]: /images/20220213/0078d2326f4445378cc7d61517e0b55b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 10]: /images/20220213/21f7048223444bfa8e957add2348c3b1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 11]: /images/20220213/7caec67925ca4dfc8cf655969ca0a3d8.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 12]: /images/20220213/b0b12f4d8a7b482eafa70667a81691c9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 13]: /images/20220213/b4efa0564f9143239959b096543583a1.png
[20190427233737663.png]: /images/20220213/7938c25325b2478aada15a8fbfd61af9.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L1Jvb2tpZXhpYW9NdV9h_size_16_color_FFFFFF_t_70 14]: /images/20220213/c12eb8474402406a94bf521a10c7dd1f.png
[20190427233900927.png]: /images/20220213/5b0e2bb824cb4795b7e827aabc410b39.png