⭐ 作者简介：码上言


⭐ 代表教程：Spring Boot + vue-element 开发个人博客项目实战教程


⭐专栏内容：个人博客系统


⭐我的文档网站：http://xyhwh-nav.cn/

Redis简介

在学习redis之前，我们先学习一下NoSQL。

1、NoSQL

1.1、什么是NoSQL？

NoSQL概念在2009年被提了出来。NoSQL最常见的解释是“non-relational”，“Not Only SQL”也被很多人接受（“NoSQL”一词最早于1998年被用于一个轻量级的关系数据库的名字）。NoSQL被我们用得最多的当数key-value存储，当然还有其他的文档型的、列存储、图型数据库、xml数据库等。

很多的数据类型用户的个人信息，社交网络，地理位置。这些数据类型的存储不需要一个固定的格式！ 不需要多月的操作就可以横向扩展的 ！ Map<String, Object>使用键值对来控制！

1.2、NoSQL 特点

• 易扩展

NoSQL 数据库种类繁多，但是一个共同的特点都是去掉关系数据库的关系型特性。

数据之间无关系，这样就非常容易扩展，也无形之间，在架构的层面上带来了可扩展的能力。

• 大数据量高性能

NoSQL数据库都具有非常高的读写性能，尤其是在大数据量下，同样表现优秀。这得益于它的非关系 性，数据库的结构简单。

一般MySQL使用Query Cache，每次表的更新Cache就失效，是一种大力度的Cache，在针对Web2.0的 交互频繁应用，Cache性能不高，而NoSQL的Cache是记录级的，是一种细粒度的Cache，所以NoSQL 在这个层面上来说就要性能高很多了。

官方记录：Redis 一秒可以写8万次，读11万次！

• 多样灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式，而在关系数据库里，增删字段是一件非常麻烦的事情。如果是非常大数据量的表，增加字段简直就是噩梦。

1.3、分类

分类	例子	应用场景	数据结构	优点	缺点
键值（key - value）	Tokyo Cabinet/Tyrant，Redis，Oracle	内存缓存，主要用于处理大量数据的高访问负载，也用于一些日志系统等等。	key指向value的键值对，通常用hash table来实现	查找速度快	数据无结构化，通常只被当作字符串或者二进制数。
列存储数据库	Cassandra，HBase，Riak	分布式的文件系统	以列簇式存储，将同一列数据存在一起	查找速度快，可扩展性强，更容易进行分布式扩展。	功能相对局限
文档型数据库	CouchDB，MongoDb	Web应用（与Key-Value类似，Value是结构化的，不同的是数据库能够了解Value的内容）	Key-Value对应的键值对，Value为结构化数据	数据结构要求不严格，表结构可变，不需要想关系型数据库一样需要预先定义表结构	查询性能不高，而且缺乏统一的查询语法。
图形数据库	Neo4J，InfoGrid，Graph	社交网络，推荐系统等，专注于构建关系图谱	图结构	利用图结构相关算法。比如最短路径寻址，N度关系查找。	这种结构不太好做分布式的集群方案

1.4、CAP理论

CAP即：

• Consistency（一致性）
• Availability（可用性）
• Partition tolerance（分区容忍性）

这三个性质对应了分布式系统的三个指标：
而CAP理论说的就是：一个分布式系统，不可能同时做到这三点，最多只能实现上面的两点。如下图：

而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容错性是我们必须需要实现的。

所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

注意：分布式架构的时候必须做出取舍。

一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。

因此牺牲C换取P，这是目前分布式数据库产品的方向

1.4.1、含义

• 一致性 C：对于客户端的每次读操作，要么读到的是最新的数据，要么读取失败。换句话说，一致性是站在分布式系统的角度，对访问本系统的客户端的一种承诺：要么我给您返回一个错误，要么我给你返回绝对一致的最新数据，不难看出，其强调的是数据正确。
• 可用性 A：任何客户端的请求都能得到响应数据，不会出现响应错误。换句话说，可用性是站在分布式系统的角度，对访问本系统的客户的另一种承诺：我一定会给您返回数据，不会给你返回错误，但不保证数据最新，强调的是不出错。
• 分区容忍性 P：由于分布式系统通过网络进行通信，网络是不可靠的。当任意数量的消息丢失或延迟到达时，系统仍会继续提供服务，不会挂掉。换句话说，分区容忍性是站在分布式系统的角度，对访问本系统的客户端的再一种承诺：我会一直运行，不管我的内部出现何种数据同步问题，强调的是不挂掉。

1.4.2、权衡C、A

对于一个分布式系统而言，P是前提，必须保证，因为只要有网络交互就一定会有延迟和数据丢失，这种状况我们必须接受，必须保证系统不能挂掉。所以只剩下C、A可以选择。要么保证数据一致性（保证数据绝对正确），要么保证可用性（保证系统不出错）。

当选择了C（一致性）时，如果由于网络分区而无法保证特定信息是最新的，则系统将返回错误或超时。

当选择了A（可用性）时，系统将始终处理客户端的查询并尝试返回最新的可用的信息版本，即使由于网络分区而无法保证其是最新的。

1.4.3、部分问题

• 一致性与可用性的决择

对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地

• 数据库事务一致性需求

很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低， 有些场合对写一致性要求并不 高。允许实现最终一致性。

• 数据库的写实时性和读实时性需求

对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的，但是对于很多web应 用来说，并不要求这么高的实时性，比方说发一条消息之 后，过几秒乃至十几秒之后，我的订阅者才看 到这条动态是完全可以接受的。

• 对复杂的SQL查询，特别是多表关联查询的需求

任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的报表查询，特 别是SNS类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主 键查询，以及单表的简单条件分页查询，SQL的功能被极大的弱化了。

1.4.4、核心

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求， 最多只能同时较好的满足两个。因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。

AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

1.5、BASE理论

BASE模型与ACID模型截然不同，满足CAP理论，通过牺牲强一致性，获得可用性，一般应用在服务化系统的应用层或者大数据处理系统，通过达到最终一致性来尽量满足业务的绝大部分需求。

BASE模型包含个三个元素：

• BA：Basically Available，基本可用

系统出现了不可预知的故障，但还是能用，相比较正常的系统而言会有响应时间上的损失和功能上的损失。

• S：Soft State，软状态，状态可以有一段时间不同步

什么是软状态呢？相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。

软状态指的是：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。

• E：Eventually Consistent，最终一致，最终数据是一致的就可以了，而不是时时保持强一致。

最终一致性是指系统中的所有数据副本经过一定时间后，最 终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。为什么 这么说呢，缘由就在于大型系统往往由于地域分布和极高性能的要求，不可能采用分布式事务来完成这 些指标，要想获得这些指标，我们必须采用另外一种方式来完成，这里BASE就是解决这个问题的办法！

注：

1、分布式：不同的多台服务器上面部署不同的服务模块（工程），他们之间通过Rpc通信和调用，对外 提供服务和组内协作。

2、集群：不同的多台服务器上面部署相同的服务模块，通过分布式调度软件进行统一的调度，对外提供 服务和访问。

1.6、总结

对于分布式系统的项目，使用中没有强制要求一定是CAP中要达到某几种，具体根据各自业务场景所需来制定相应的策略而选择适合的产品服务等。

例如：支付订单场景中，由于分布式本身就在数据一致性上面很难保证，从A服务到B服务的订单数据有可能由于服务宕机或其他原因而造成数据不一致性。因此此类场景会酌情考虑：AP，不强制保证数据一致性，但保证数据最终一致性。

2、认识Redis

2.1、Redis是什么?

Redis 是完全开源的，遵守 BSD 协议，是一个高性能的 key-value 数据库，基于内存运行，并支持持久化的NoSQL数据库，是当前最热门的NoSQL数据库之一，也被人们称为 数据结构服务器。

Redis 与其他 key - value 缓存产品有以下三个特点：

• Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
• Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
• Redis支持数据的备份，即master-slave模式的数据备份。

2.2、Redis 优势

• 性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
• 丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets数据类型操作。
• 原子 – Redis的所有操作都是原子性的，意思就是要么成功执行要么失败完全不执行。单个操作是原子性的。多个操作也支持事务，即原子性，通过MULTI和EXEC指令包起来。
• 丰富的特性 – Redis还支持 publish/subscribe, 通知key 过期等等特性。

2.3、特性

• 键值（key-value）型，value支持多种不同数据结构，功能丰富
• 单线程，每个命令具备原子性
• 低延迟，速度快（基于内存、IO多路复用、良好的编码）。
• 支持数据持久化
• 支持主从集群、分片集群
• 支持多语言客户端

2.4、官方网址

官网 ：https://redis.io/

中文网： http://www.redis.cn

3、Windows安装

windows安装很简单的。Redis 支持 32 位和 64 位。这个需要根据你系统平台的实际情况选择

下载地址：https://github.com/tporadowski/redis/releases

下载完后，解压文件，然后打开文件夹，内容如下：

我们直接双击redis-server.exe即可启动。

这时候另启一个 cmd 窗口，原来的不要关闭，不然就无法访问服务端了。

通过客户端去访问 redis-cli.exe

设置键值对:

set myKey abc

取出键值对:

get myKey

windows我们自己平时练习一下就行了，Redis主要是放在Linux上使用。

4、压力测试

4.1、压力测试

1、redis压力测试工具-----Redis-benchmark

Redis-benchmark是官方自带的Redis性能测试工具，可以有效的测试Redis服务的性能。

2、redis-benchmark工具存放在Redis的src目录下

使用 redis-benchmark -h 命令来查看使用参数

redis-benchmark [-h <host>] [-p <port>] [-c <clients>] [-n <requests]> [-k <boolean>]
 
 -h <hostname> 指定服务器主机名 (默认 127.0.0.1)
 -p <port> 指定服务器端口 (默认 6379)
 -s <socket> 指定服务器 socket
 -a <password> Redis 认证密码
 -c <clients> 指定并发连接数 (默认 50)
 -n <requests> 指定请求数 (默认 100000)
 -d <size> 以字节的形式指定 SET/GET 值的数据大小 (默认 2)
 --dbnum <db> 选择指定的数据库号 (默认 0)
 -k <boolean> 1=keep alive 0=reconnect (默认 1)
 -r <keyspacelen> SET/GET/INCR 使用随机 key, SADD 使用随机值
 -P <numreq> 通过管道传输 <numreq> 请求 (no pipeline)
 -q 退出，仅显示 query/sec 值
 --csv 以 CSV 格式输出
 -l 生成循环，永久执行测试
 -t <tests> 仅运行以逗号分隔的测试命令列表
 -I Idle 模式，仅打开 N 个 idle 连接并等待

3、压力测试

对127.0.0.1使用20个并行客户端，总共10万个请求

./redis-benchmark -h 127.0.0.1 -p 6379 -n 100000 -c 20 -q

4.2、基础面试知识

默认16个数据库，类似数组下标从零开始，初始默认使用零号库。

查看 redis.conf ，里面有默认的配置

# Set the number of databases. The default database is DB 0, you can select
# a different one on a per-connection basis using SELECT <dbid> where
# dbid is a number between 0 and 'databases'-1
databases 16

1、Select命令切换数据库

127.0.0.1:6379> select 7
OK
127.0.0.1:6379[7]>

# 不同的库可以存不同的数据

2、Dbsize查看当前数据库的key的数量

127.0.0.1:6379> select 1
OK

127.0.0.1:6379[1]> DBSIZE
(integer) 0

127.0.0.1:6379[1]> select 0
OK

127.0.0.1:6379> DBSIZE
(integer) 5

127.0.0.1:6379> keys * # 查看具体的key
1) "counter:__rand_int__"
2) "mylist"
3) "k1"
4) "myset:__rand_int__"
5) "key:__rand_int__"

3、Flushdb：清空当前库

4、Flushall：清空全部的库

127.0.0.1:6379> FLUSHDB
OK

127.0.0.1:6379> DBSIZE
(integer) 0

4.2.1、为什么Redis是单线程

官方解释：因为Redis是基于内存的操作，CPU不是Redis的瓶颈，Redis 的瓶颈最有可能是机器内存的大小或者网络带宽。既然单线程容易实现，而且CPU不会成为瓶颈，那就 顺理成章地采用单线程的方案了！

我们所说的Redis的单线程，不是指Redis程序真的只会有一个线程。这里所说的单线程，指的是Redis处理客户端发来的数据操作请求（增删改查），只会使用一个线程去执行。但是实际上，Redis在执行其他操作的时候，可能会开启多个进程或线程，比如说持久化。Redis执行BGSAVE指令，进行快照持久化时，就会fork出一个子进程，然后子进程去创建快照，完成持久化操作。

4.2.2、Redis为什么那么快

多线程 一定比 单线程 效率高，其实不然！

redis 核心就是 如果我的数据全都在内存里，我单线程的去操作 就是效率最高的，为什么呢，因为 多线程的本质就是 CPU 模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切 换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。redis 用 单个CPU 绑定一块内存 的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处 理这个事。在内存的情况下，这个方案就是最佳方案。

因为一次CPU上下文的切换大概在 1500ns 左右。从内存中读取 1MB 的连续数据，耗时大约为 250us， 假设1MB的数据由多个线程读取了1000次，那么就有1000次时间上下文的切换，那么就有1500ns * 1000 = 1500us ，我单线程的读完1MB数据才250us ,你光时间上下文的切换就用了1500us了，我还不 算你每次读一点数据 的时间。

4.2.3、Redis如何提高CPU利用率

现在的CPU一般都有多个核心，每个核心可以单独执行。Redis处理客户端请求使用单线程，那么自然而然，无法将CPU的所有核心都占用，也就造成了资源的浪费。而解决的方式也比较简单，我们可以在同一个服务器上开启多个Redis程序，每个Redis程序使用不同的端口，相互独立，以此提高CPU的使用率。而这多个Redis程序可以配置成主从节点，共同为一个程序服务，也可以相互独立，服务于多个程序。

5、Redis桌面客户端

下载地址：https://github.com/uglide/RedisDesktopManager，该仓库提供的是RedisDesktopManager的源码，并未提供windows安装包。

在下面这个仓库可以找到安装包：https://github.com/lework/RedisDesktopManager-Windows/releases

既然是学习使用，我们就是使用最新的版本即可。

1、安装

下载完成之后，我们解压一下，然后看到文件夹中一个exe文件，我们双击安装。

安装完成之后，打开安装的目录，找到这个resp.exe文件。

双击运行即可：

2、建立连接

点击左上角的连接到Redis服务器按钮：

这里启动可以在本地装一个redis，然后启动起来，我们这里默认地址即可，填写一个名字，其余的可为空，如果你连接的是服务器上的，可能设置密码，再填写密码即可。

填写完之后，先别着急点确定，点击左下角的测试连接，先测试一下连接是否通，然后再确定

测试成功之后，再点击确定，然后打开我们新添加的test，就会看到16个数据库了。

Redis默认有16个仓库，编号从0至15. 通过配置文件可以设置仓库数量，但是不超过16，并且不能自定义仓库名称。

以上就是学习Redis入门需要了解的知识，我是一步一步的操作的，接下来进入redis实际的应用。