和面试官从NoSql谈起【Redis】

àì夳堔傛蜴生んèń 2021-09-04 05:10 381阅读 0赞

> 秋招的经验,越来越多的企业对于校招生有Redis的要求，不是企业要求变高了，而是当今大数据时代，信息量很大，我们需要处理的数据并不可能都是简单的数据类型，可能会设计到社交关系图、推荐系统等等，另外数据量的增大，关系型数据库在处理大数据时可能效率是比较低的。因此对于Redis的要求就变高了！

因为学习Redis是一个很好的契机和选择，而本篇文章将会详细讲解数据库的发展历程。以及学习Redis之前需要了解的知识。

推荐阅读  
我的下一篇文章会详解Redis的五大基本数据类型的使用（附详细示例）  
[【Redis】5大基本数据类型详解][Redis_5]

### 文章目录 ###

*  先谈谈关系型数据库的发展历程
 *   *  最开始的时候：单机版数据库
     *  进一步发展：数据量变大，效率有一定要求
     *  进一步发展：出现缓存，实现可垂直拆分
     *  分库分表+水平拆分
     *  总结
 *  为什么出现了NoSQL？
 *  如今的互联网对于数据访问的要求
 *  什么是NoSQL?
 *   *  NoSQL的特点：
     *  传统的关系型数据库和非关系型数据库的区别
     *  了解大数据时代的3V和3高
 *  NoSQL的四大分类
 *  Redis入门
 *   *  概述
 *  下载Redis(Windows)
 *  Redis的使用
 *  Redis基础知识
 *  Redis是单线程的
 *  从官网的角度看Redis的作用
 *  Redis的Key

# 先谈谈关系型数据库的发展历程 #

`万事万物都是因为有相应的需求才会产生,而数据库的发展和NoSQL的出现也有因为有相应的需求。`

## 最开始的时候：单机版数据库 ##

==数据量小，对于查询的效率要求不高，使用单机的MySQL就完全能解决相应的需求。==为帮助理解，我画一张简图。

![image-20201226182644604][]

## 进一步发展：数据量变大，效率有一定要求 ##

采用读写分离的思想（同一个数据库创建多个“副本”，有的负责写，有的负责读数据，实现读写分离）。这样可以提升访问的效率。

简单示意图：先看这个示意图，然后我根据示意图讲解这样设计的原因。

![image-20201226183449658][]

如上图，我们将应用程序需要用到的数据分在了三个数据库中（一个写数据库和两个读数据库）。

*  因为我们发现`数据库中大量的操作都是读操作,其实写的操作是少数`那么如果能够实现读写分离，那么在读的时候不需要事务管（也就是没有锁机制的话）是能够提升数据库效率的。
 *  但是由于需要将写的数据同步到读的数据库中因为也有部分的效率消耗

## 进一步发展：出现缓存，实现可垂直拆分 ##

出现缓存的原因：因为发现在实际的开发工程中，不仅是写的操作是少数，而且很可能是连续多次都是查询的相同的热点内容。如果能够将查询的结果保存起来，下次查询的时候就可以避免数据库再次执行SQL语句，那么是可以减少应用程序和数据库的交互时可以提高效率的。

*  核心思想就是创建缓存，将热点数据存储起来。

![image-20201226184304453][]

这里大家可以联系一下MyBatis的一级缓存和二级缓存。

其实就是对于查询结果的复用，然后可以避免数据库和应用程序的频繁交互，从而提高效率。

## 分库分表+水平拆分 ##

思想:既然数据库要求存储的数据量不断变大，那么一个数据库可能就存不下需要的数据，那么就将数据库分为多个数据库（也就是说多个数据库来共同存储原本一个数据应该存储的数据）。

*  分库分表的主要作用就是能够增大数据库的存储量
 *  其次，原本需要一个数据库来存储的数据现在由多个较小的数据库来存放，那么查询速率也会有相应的提示。

![21900b7c89c94ba7838fdc18614f994d.png][]

我们发现我们数据的结构原来越复杂，给应用程序提供了更加高效的数据访问服务。

## 总结 ##

数据库在发展方面出现的新的问题：

1.  数据量在激增
2.  数据库的访问效率要求更高

数据库在调优方面做出的改变：

*  对于数据库激增
    
    1.  采用了分库分表的策略，将原本需要存放在一个数据库的数据存放在了不同的数据库和表中。
 *  对于数据库的访问效率：
    
    1.  对于热点数据，数据库要求建立热点数据的缓存，避免应用程序和数据库多次的交互而导致的数据库访问效率降低。
    2.  对于数据库数据的访问，提出了读写分离的思想，因为大部分的操作都是读数据的操作。实现读写分离，读的效率会更快。
    3.  对于读写分离方面，不同的执行引擎也有优化，比如在MYISAM，执行引擎中，只支持表锁，每次操作的时候都是锁定整个表，这样的访问效率是低下的。而在Innodb执行引擎中，是支持行锁的。
    4.  另外，为了访问的效率，添加了索引，使用的思想是用空间换时间的思想来增加数据库访问的效率。

# 为什么出现了NoSQL？ #

在上面的部分，我们发现由于需求的更新,数据库在一点点的更新迭代已满足需求。那么为什么出现了NoSQL?

由于现在的时代是一个数据爆炸的时代，`数据量极大，而且数据的类型和关系复杂，对于访问的效率要求更高`

*  MySQL存储的数据量是有限的
 *  MySQL的数据类型不能满足在现实生活中的数据类型
 *  大数据时代的数据访问效率要求高
 *  MySQL在处理大数据时效率不高,比如现在有1亿条记录,我们需要在这1亿的数据记录都加1列,这时对于MySQL来说就是效率较低的了

# 如今的互联网对于数据访问的要求 #

![image-20201226191607967][]

# 什么是NoSQL? #

> NoSQL

NoSQL = Not Only SQL(不仅仅是SQL)泛指非关系型数据库。随着Web2.0时代的来临，关系型数据库不能满足超大规模的高并发的社区。

## NoSQL的特点： ##

1.  方便扩展（数据之间不像关系型数据那样是有关系的，非关系型数据库的数据是没有关系的，因此很好扩展,在关系型数据库中,我们要在一开始就设计好表的结构,不然那会在后续的程序编写中出现问题,而Redis很容易扩展,因此可以在后续在对表结构进行扩展）
2.  大数据量高性能（Redis一秒可以写8W次，读11W次，并且NoSQL的缓存是记录级别的，粒度很小，因此性能高）
3.  数据类型多样
    
     *  5大基本数据类型
        
         *  String
         *  List
         *  Zset
         *  Hash
         *  Set
     *  三种特殊的数据类型
        
         *  geo
         *  hyperloglog
         *  bitmap

## 传统的关系型数据库和非关系型数据库的区别 ##

传统的关系型数据

*  结构化组织
 *  SQL
 *  数据和关系都存在于独立的表中
 *  数据库操作和数据定义语言
 *  严格的一致性
 *  基础的事务

NoSQL数据

*  不仅仅是数据
 *  没有固定的查询语言
 *  多种存储方式:键值对存储,列存储,文档存储,图形化存储等
 *  最终一致性
 *  CAP定理和BASE理论
 *  高性能和高扩展性

## 了解大数据时代的3V和3高 ##

大数据时代的3V:

*  海量Volume
 *  多样Variety
 *  实时Velocity

互联网需求的3高:

*  高并发
 *  高可拓展
 *  高性能

# NoSQL的四大分类 #

![image-20201226194001166][]

了解了MySQL的发展历程和NoSQL的基本知识，可以对于我们需要学习的Redis有一个大致的认知。之后的博客会详细更新Redis的学习内容。

> 最近两天有点懈怠，一直在等offer的结果，因此稍有懈怠。其实不论结果如何，只要有所收获就是满足的结果，另外不要停下脚步，要持续的学习！！加油，雷雨佳。

# Redis入门 #

## 概述 ##

> 什么是Redis?

Redis(Remote Dictionary Server),即远程字典服务。

是一个开源的支持网络、可基于内存亦可持久化的Key-Value的数据库，并提供多种语言的API。

Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,并且再次基础上实现master-slave(主从)同步。

> Redis能干嘛?

1.  内存存储（保证效率）、持久化，（我们知道在内存中存储的话，可以减少应用程序和磁盘之间的IO次数，那么就可以提升效率，而Redis也可以实现持久化，实现的方式是通过RDB或者AOF策略）。
2.  效率高，能够用于高速缓存。
3.  发布订阅系统
4.  能够用于地图信息分析
5.  可以用于计数器、计数器（比如说浏览量）

> 特性

1.  多样的数据类型
2.  持久化、集群
3.  事务

# 下载Redis(Windows) #

[Redis下载地址][Redis]

![image-20201226202631644][]

下载完毕之后要解压,解压之后出现文件夹

![image-20201226202759185][]

# Redis的使用 #

*  第一步:打开Redis的服务

![image-20201226202901683][]

*  这里我下载了一个Redis的客户端桌面管理程序,用其连接Redis的服务器

![image-20201226203203350][]

*  测试一下简单的使用(使用set 命令写入数据 使用get命令得到数据)

![image-20201226203334932][]

这里发现其实Redis很像 我们的Key-Value键值对

其实在Redis的官网,推荐Redis是在Linux上使用,但是为了学习方便,我是在Windows上使用的演示的

# Redis基础知识 #

Redis默认有16个数据库(默认使用的是第0个数据库)

![image-20201226204617454][]

**切换数据库和查看数据库大小**

local:0>select 2
    "OK"
    local:2>set name leiyu
    "OK"
    local:2>get name
    "leiyu"
    local:2>DBSIZE
    "1"
    local:2>keys *
     1)  "name"

*  select 数据库的数字表示: 切换数据库
 *  查看数据库大小: DBSIZE
 *  查看数据库中的所有的key: keys \*

**清空当前数据库**

local:2>flushdb

**清空所有的数据库**

local:2>flushALL

# Redis是单线程的 #

Redis是很快的，官方表示Redis是基于内存操作的，CPU不是性能的瓶颈，Redis的瓶颈是根据`机器的内存`和`网络的带宽(Redis需要网络通讯)`,既然可以使用单线程来实现,那么就使用单线程了。

为什么Redis是单线程的还那么快？

1.  误区1：高性能的服务器一定是多线程的
2.  误区2：多线程（多线程的瓶颈是CPU，会存在上下文切换）一定比单线程的效率高（在Redis是单线程的，但是Redis是基于内存和网络的，因此CPU不是Redis的瓶颈）上下文的切换是消耗性能的
    
     *  首先要明确(速度)：CPU—>内存---->磁盘
     *  Redis是将所有的数据全部放在内存中的,所以说使用单线程操作效率是最高的。
     *  对于内存系统来说,如果没有上下文切换效率就是最高的。多次读写都是在一个CPU上的，在内存情况下，这个就是最佳的方案。

# 从官网的角度看Redis的作用 #

![image-20201226211215832][]

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它可以用作数据库、缓存和消息中间件。 它支持多种类型的数据结构，如 [字符串（strings）][strings]， [散列（hashes）][hashes]， [列表（lists）][lists]， [集合（sets）][sets]， [有序集合（sorted sets）][sorted sets] 与范围查询， [bitmaps][]， [hyperloglogs][] 和 [地理空间（geospatial）][geospatial] 索引半径查询。 Redis 内置了 [复制（replication）][replication]，[LUA脚本（Lua scripting）][LUA_Lua scripting]， [LRU驱动事件（LRU eviction）][LRU_LRU eviction]，[事务（transactions）][transactions] 和不同级别的 [磁盘持久化（persistence）][persistence]， 并通过 [Redis哨兵（Sentinel）][Redis_Sentinel]和自动 [分区（Cluster）][Cluster]提供高可用性（high availability）。

*  Redis的作用是很强大的，可以作为数据库，也可以作为缓存，同时可以作为消息中间件。

# Redis的Key #

*  判断一个Key是否存在

local:2>set name leiyujia
    "OK"
    local:2>exists name
    "1"

如果存在,那么就会返回1,不存在返回0

*  移除当前数据库的一个key

local:2>move name 1      # 1代表的是当前是数据库
    "1"

*  设置Key过期时间(以秒计时)

local:2>EXPIRE name 10  # 设置name的过期时间是10s
    "1"

*  查看key的类型

local:2>TYPE name
    string

温馨提示:如果后期遇到自己不会的命令可以去Redis查看，但是还是最好还是记住。

![image-20201226212722039][]

[Redis_5]: https://blog.csdn.net/qq_40742223/article/details/111828279
[image-20201226182644604]: /images/20210724/cae42f2f39f14b3eb73e63f000b2f3bb.png
[image-20201226183449658]: /images/20210724/6afe1de53a4a45d6ba871f4cca993422.png
[image-20201226184304453]: /images/20210724/edbe6857c37f475a923ef22c1969ae7d.png
[21900b7c89c94ba7838fdc18614f994d.png]: /images/20210724/df8beaa34fb6451bbc79beef282dadcb.png
[image-20201226191607967]: /images/20210724/15c9445ddb2140fab926fc2fdde30f0d.png
[image-20201226194001166]: /images/20210724/7121a9b2ffbf4836b3f503e78dd3ec65.png
[Redis]: https://redis.io/
[image-20201226202631644]: /images/20210724/701f66acef994b1f9478dbd8265dffd1.png
[image-20201226202759185]: /images/20210724/8bfe0900680745d9bf8f7d8fe84c0dac.png
[image-20201226202901683]: /images/20210724/69ef05eabf5d4ea09b7696042c24bffb.png
[image-20201226203203350]: /images/20210724/7c588063cf0b43628b9eda71057dfd00.png
[image-20201226203334932]: /images/20210724/5d1c9e0e2a8340698f08a0396f8ae0db.png
[image-20201226204617454]: /images/20210724/bdcff97bab1042b7aab901595416c4aa.png
[image-20201226211215832]: /images/20210724/c013382792d842078fa78bf056d73cd2.png
[strings]: http://redis.cn/topics/data-types-intro.html#strings
[hashes]: http://redis.cn/topics/data-types-intro.html#hashes
[lists]: http://redis.cn/topics/data-types-intro.html#lists
[sets]: http://redis.cn/topics/data-types-intro.html#sets
[sorted sets]: http://redis.cn/topics/data-types-intro.html#sorted-sets
[bitmaps]: http://redis.cn/topics/data-types-intro.html#bitmaps
[hyperloglogs]: http://redis.cn/topics/data-types-intro.html#hyperloglogs
[geospatial]: http://redis.cn/commands/geoadd.html
[replication]: http://redis.cn/topics/replication.html
[LUA_Lua scripting]: http://redis.cn/commands/eval.html
[LRU_LRU eviction]: http://redis.cn/topics/lru-cache.html
[transactions]: http://redis.cn/topics/transactions.html
[persistence]: http://redis.cn/topics/persistence.html
[Redis_Sentinel]: http://redis.cn/topics/sentinel.html
[Cluster]: http://redis.cn/topics/cluster-tutorial.html
[image-20201226212722039]: /images/20210724/0ec5e3eb41b84166a774b89ace884826.png