讨伐Redis

02/04 10:31
阅读数 35

本文是学习Redis时做的知识点整理,原视频链接:

https://www.bilibili.com/video/BV1oW411u75R

目录

Redis核心

1 Redis是什么?

1.1 Redis是分布式数据库

1.1.1 数据库事务的ACID

1.1.2 CAP定理

1.1.3 BASE理论

1.2 Redis是内存数据库

1.2.1 RDB

1.2.2 AOF

1.2.3 RDB和AOF

1.3 Redis是NoSQL数据库

Redis的数据格式

2 Redis能做什么?

2.1 数据操作

2.1.1 基本操作命令

2.1.2 string的相关操作

2.1.3 hash的相关操作

2.1.4 list的相关操作

2.1.5 set的相关操作

2.1.6 zset的相关操作

2.2 支持事务

2.2.1 Redis事务命令

2.2.2 Redis事务的特性

2.3 消息的订阅和发布

2.4 主从复制

2.4.1 多节点搭建

2.4.2 主从复制命令

2.4.3 主从复制原理

2.4.4 主从复制策略

2.4.5 哨兵模式

3.Redis的安装、使用和调优

3.1 Redis的安装

3.2 Redis的使用

3.3 Redis调优


Redis核心

学习Redis,核心在于两个问题:

  1. Redis是什么?
  2. Redis能做什么?

知道了Redis是什么,就很好理解Redis为什么要提供它提供的那些功能;

知道了Redis能做什么,以后遇到想用Redis的场合,你总能通过各种方式做到。

 

1 Redis是什么?

Redis:Remote Dictionary Server,远程字典服务器。

是完全开源免费的,用C语言编写的,遵守BSD协议,是一个高性能的(key/value)分布式内存数据库,基于内存运行并支持持久化的NoSQL数据库,是当前最热门的NoSQL数据库之一,也被人们称为数据结构服务器。

关键信息:

  1. Redis是分布式数据库
  2. Redis是内存数据库
  3. Redis是NoSQL数据库

 

1.1 Redis是分布式数据库

分布式数据库:位于不同地点的许多计算机通过网络互相连接,共同组成的一个逻辑上集中、物理上分布的大型数据库。

分布式数据库有两个要点:

  • CAP定理
  • BASE理论

1.1.1 数据库事务的ACID

A:Atomicity,原子性:

整个事务中的所有操作,要么全部完成,要么全部不完成,不可能停滞在中间某个环节。事务在执行过程中发生错误,会被回滚到事务开始前的状态,就像这个事务从来没有执行过一样。

C:Consistency,一致性:

事务必须始终保持系统处于一致的状态,不管在任何给定的时间并发事务有多少。

I:Isolation,隔离性:

隔离状态执行事务,使它们好像是系统在给定时间内执行的唯一操作。如果有两个事务,运行在相同的时间内,执行相同的功能,事务的隔离性将确保每一事务在系统中认为只有该事务在使用系统。

D:Durability,持久性:

在事务完成以后,该事务对数据库所作的更改便持久的保存在数据库之中,并不会被回滚。

1.1.2 CAP定理

CAP定理:一个分布式系统不可能同时满足一致性[Consistency],可用性[Availability],和分区容错性[Partition tolerance]这三个基本要求,最多只能同时满足其中的两项。

C:Consistency,一致性:

数据在多个副本之间是否能够保持一致的特性。

系统的一个数据更新成功之后,如果所有用户都能够读取到最新的值,该系统就被认为具有强一致性。

A:Availability,可用性:

系统提供的服务必须一直处于可用的状态,对于用户的每一个操作请求总是能够在有限的时间内返回结果。

P:Partition tolerance,分区容错性:

分布式系统在遇到任何网络分区故障的时候,仍然对外提供满足一致性和可用性的服务。

在分布式系统中,分区容错性是必须实现的,所以我们只能在一致性和可用性之间进行权衡。

对一致性的让步:

很多web实时系统对读一致性的要求很低,有些场合对写一致性的要求也不高,允许实现最终一致性。

对可用性的让步:

对很多web应用来说,并不需要特别高的实时性。比如发布者发布一条消息后,过几秒甚至十几秒,订阅者才看到这条动态,也是完全可以接受的。

BASE理论是对CAP中一致性和可用性的权衡的结果。

1.1.3 BASE理论

BASE 核心思想是:即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。

BASE是基本可用[Basically Available]、软状态[Soft state]、最终一致[Eventually consistent]三个术语的缩写。

 

1.2 Redis是内存数据库

内存数据库:顾名思义,就是将数据保存在内存中的数据库。因为内存读写数据的速度要远大于磁盘,所以内存数据库的性能远高于传统的磁盘数据库。

内存有一个特性就是,一旦断电,所有的数据都会被清空,所以数据持久化对内存数据库而言非常重要。

Redis支持数据的持久化,可以将内存中的数据保留在磁盘中,系统重启时再次加载使用。

Redis提供了两种持久化策略:RDB和AOF。

1.2.1 RDB

RDB,Redis DataBase:在指定的时间间隔下,将内存中的数据集快照(Snapshot快照)写入磁盘。恢复数据时,将快照文件直接读到内存中。

Redis复制一个与当前进程完全一样的进程,作为当前进程的子进程,这个过程称为fork。

Redis会fork一个子进程来进行数据持久化,这个子进程会先将数据写入一个临时文件,待持久化过程结束后,再用这个临时文件替换上一次的持久化文件。

持久化文件的默认名称为:dump.rdb。

整个过程中,主进程不进行任何IO操作,这就确保了极高的性能。

RDB持久化的触发机制:

  • 条件触发
  • 指令触发

条件触发:

在以下三件事 任一件发生时,RDB持久化触发:

  • 900秒以内,至少有1个key被改动;
  • 300秒以内,至少有10个key被改动;
  • 60秒以内,至少有10000个key被改动。

以上参数均可以在配置文件中进行修改。

指令触发:

save:阻塞其它进程,进行RDB持久化。

bgsave:在后台异步进行RDB持久化。

RDB策略的优势在于:适合大规模的数据恢复,对数据完整性和一致性的要求不高。

劣势在于:如果Redis意外宕机,会丢失最后一次快照后的所有修改。

1.2.2 AOF

AOF,Append Only File:以日志的形式,将Redis执行过的所有写指令记录下来,只允许追加新文件但不可以对已保存的文件进行修改。恢复数据时,Redis会读取日志文件重新构建数据。

AOF持久化文件的默认名称为:appendonly.aof。

AOF策略在Redis中是默认不启用的,需要通过修改配置文件开启。

AOF持久化的触发机制:

默认每秒执行一次,如果在一秒内宕机,数据丢失。

通过修改配置文件,可以设置三种不同的AOF策略:

  • always:同步持久化,即每次发生数据变更 都会被立即记录到磁盘。
  • everysec:出厂默认设置,异步操作,每秒记录一次。
  • no:从不。

如果AOF持久化进行时发生系统错误,导致aof文件被写入了异常数据,进一步导致恢复数据时报IO异常,可以通过修复指令对损坏的aof文件进行修复。

修复命令:

redis-check-aof --fix 文件名

AOF采用文件追加的方式,产生的文件会越来越大,为了避免产生的aof文件占用太多存储空间,Redis增加了Rewrite机制。

Rewrite:重写,当aof文件的大小超过了设定的阈值时,Redis会对aof文件的内容进行压缩,只保留可以恢复数据的最小指令集。

重写过程中Redis并没有读取旧的aof文件,而是fork出一条子进程,将内存中当前数据集用命令的方式重写,类似于快照。

Rewrite的触发机制:

  • 条件触发
  • 指令触发

条件触发:

当aof文件的大小超过了设定的阈值时,Rewrite发生。

Rewrite的阈值默认为以下两个条件同时满足:

  • [aof文件的大小]超出[上一次rewrite后的文件大小]的大小,达到[上一次rewrite后的文件大小]的100%
  • aof文件大于64M

以上参数均可以在配置文件中进行修改。

指令触发:

bgrewriteaof:在后台异步进行重写。

1.2.3 RDB和AOF

RDB和AOF两种策略可以同时存在。

在同时开启了RDB和AOF的情况下,当Redis重启时会优先载入aof文件来恢复数据,因为通常aof文件保存的数据集要比rdb文件更完整。

性能建议:

因为rdb文件只用作后备用途,建议只在slave上持久化rdb文件,而且只保留“15分钟备份一次”的规则就够了。

如果启用了AOF,好处是在最恶劣的情况下丢失的数据也不会超过两秒,恢复数据时只需要载入aof文件即可,代价是带来了持续的IO。AOF rewrite过程中产生的新数据写入新文件造成的阻塞几乎是不可避免的,所以只要硬盘许可,应尽量减少AOF rewrite的频率。另外AOF rewrite的默认阈值64M太小了,可以设到5G以上。

如果不启用AOF,仅靠Master-Slave Replication实现高可用性也可以,能省掉一大笔IO开销,同时也减少了AOF rewrite带来的系统波动,但如果Master和Slave同时倒掉,会丢失十几分钟的数据,在这种情况下启动脚本时,要比较Master和Slave中的rdb文件,载入较新的那个。

 

1.3 Redis是NoSQL数据库

NoSQL数据库:Not Only SQL,泛指非关系型数据库,区别于关系型数据库,它们不保证关系数据的ACID特性。

NoSQL有如下优点:

  • 易扩展。NoSQL数据库的种类繁多,但它们都有一个共同点:去掉了关系型数据库的关系型特性。因为数据之间无关系,所以非常容易扩展,因此NoSQL数据库在架构的层面上可扩展性很强。
  • 高性能。NoSQL数据库都具有非常高的读写性能,在大数据量下同样表现优秀,这得益于它的无关系性,数据库结构简单。

Redis是NoSQL数据库,它的数据格式符合NoSQL数据库数据格式的特征:

NoSQL数据库无需事先为要存储的数据建立字段,随时可以存储自定义的数据格式。

Redis的数据格式

Redis的基本数据格式是键值对:key-value。

Redis的五大数据类型:string、hash、list、set、zset。

  • string:字符串。Redis中所有的key都是string类型的数据。string类型是二进制安全的,意思是Redis的string可以包含任何数据,比如jpg图片或者序列化的对象。
  • hash:哈希。hash是一个键值对集合,适合用于存储对象。
  • list:列表。list的底层实际上是链表。
  • set:set集合。set是string类型的无序集合,不允许重复的成员,通过HashTable实现。
  • zset:sorted set,有序集合。zset和set一样也是string类型元素的集合,且不允许重复的成员,不同的是每个元素都会关联一个double类型的分数,Redis通过分数来为集合中的成员进行从小到大的排序。zset的成员是唯一的,但分数可以重复。

 

https://www.php.cn/faq/420209.html

2 Redis能做什么?

Redis的所有操作都是通过指令完成的。由此我们很容易想到:Redis提供了什么命令,就能够实现什么功能。

根据命令集,Redis能够完成的比较重要的功能有:

  • 数据操作
  • 支持事务
  • 消息的订阅和发布
  • 主从复制

 

2.1 数据操作

2.1.1 基本操作命令

keys *        查看当前所有key

set        设值

get        取值(当value不为string类型时报错)

mset        批量设值

mget        批量取值

setnx        不覆盖设值

exists        判断key是否存在

del        删除key

type        查看数据类型(因为key的数据类型一定是string,所以返回的是value的数据类型)

ttl        查看key的剩余存活时间(-1永久存活,-2不存在的key)

expire        设置key的存活时间(单位:秒)

setex        设值时设置key的存活时间

select        切换到其它库(默认0)

move        移动key到其它库

flushall        清空所有库(慎用)

2.1.2 string的相关操作

strlen        获取字符串长度

append        增补字符串

getrange        截取字符串

setrange        从某个坐标开始部分替换字符串

incr        自增

incrby        等差递增

decrby        等差递减

2.1.3 hash的相关操作

hset        设值

hget        取值

hmset        批量设值

hmget        批量取值

hgetall        获取全部信息

hkeys        获取所有key

hvals        获取所有value

hexists        判断是否存在key

hdel        删除

hincrby        自增

2.1.4 list的相关操作

lpush        左侧入栈

rpush        右侧入栈

lrange        从某个坐标开始查看list(-1表示全部)

lindex        查看某个坐标的值

lset        设置某个坐标的值

lpop        左侧出栈

rpop        右侧出栈

llen        查看list长度

linsert        插入

lrem        删除(1个3,2个3,3个1)

ltrim        截取

2.1.5 set的相关操作

sadd        添加元素(自动去重)

smembers        展示set中所有成员

sismember        判断是否为set成员

scard        查看set集合成员个数

spop        随机弹出成员

srem        删除成员

srandmember        随机取出n个值

两set集合关系:

sunion        并集

sinter        交集

sdiff        差集

smove        移动成员

2.1.6 zset的相关操作

zadd        添加成员

zrange        查看zset中的成员

 zrangebyscore        按分数筛选(加括号表示不包括)

zscore        获取分数

zrem        删除成员(不演示)

zrevrange        按分数排名

zrevrank        获取某个成员的分数排名

 

2.2 支持事务

事务本质是一组命令的集合。把一组命令放入一个队列中,一次性、顺序性、排他性地执行。

2.2.1 Redis事务命令

multi        事务开始

exec        执行事务

discard        事务取消

事务在编译时遇到错误:(整个事务失败)

事务在运行时遇到错误:(事务成功)

watch        监视key(如果在事务执行之前监视的key被其它命令改动,事务取消)

执行exec会将之前加的监控锁全部取消。

unwatch        取消对所有key的监视

2.2.2 Redis事务的特性

1.单独的隔离操作

事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的请求打断。

2.没有隔离级别的概念(因为是NoSQL)

因为事务提交前任何指令都不会被实际执行,也就不存在“事务内的查询要看到事务里的更新,事务外的查询不能看到事务里的更新”的问题。

3.不保证原子性

Redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚。

 

2.3 消息的订阅和发布

消息的订阅和发布:进程间的一种通信模式,发送者(pub)发送消息,订阅者(sub)接收消息。

假如三个客户端client1、client2、client3 订阅了频道channel1。

当有新消息发送给频道channel1时,这条消息会被分别发送给订阅它的三个客户端client1、client2、client3。

subscribe        订阅频道

unsubscribe        退订频道

publish        将消息发送到指定的频道

psubscribe        订阅符合条件的多个频道(通配符*)

punsubscribe        退订符合条件的所有频道

 

2.4 主从复制

主从复制:即master/slaver机制,主机数据更新后根据配置和策略,自动同步到备机,master以写为主,slave以读为主。

主从复制可以用来实现读写分离、容灾恢复等。

2.4.1 多节点搭建

在一台虚拟机上搭建3个节点:

1.拷贝多个redis.conf文件

每个节点需要一个配置文件。为搭建3个节点,这里我把redis.conf文件复制了3份:

2.依次修改每个配置文件

配置文件修改细节:

指定端口(3个配置文件依次设为6379、6380、6381)

开启daemonize yes

pidfile名称(与端口号对应)

log文件名字(与端口号对应)

dump.rdb名字(与端口号对应)

3.依次启动3个节点

2.4.2 主从复制命令

主从复制原则:配从不配主。

slaveof        成为某节点的从节点

slaveof no one        不再是任何节点的从节点

info replication        查看节点信息

读写分离的体现:主写从读。

成为其它节点的从节点后,该节点不能再写入:

shutdown        节点关闭

主节点关闭后,从节点原地待命,主节点重启后与其它节点的主从关系不变。

从节点关闭并重启后,不再是其它节点的从节点。

2.4.3 主从复制原理

slave每次连接master时都全量复制master的数据,之后master对数据进行修改时,slave对改动进行增量复制。

slave变更master时(除非自己成为master),之前的数据会被清空,然后全量复制新master的数据。

主从复制的缺点在于复制延时。由于所有的写操作都是先在master上操作,然后同步更新到slave,所以从master同步到slave会有一定的延迟,当系统繁忙时,延迟问题会更加严重。

2.4.4 主从复制策略

常见的主从复制策略有:

  • 一主二仆
  • 薪火相传
  • 反客为主

一主二仆:一个master对应两个slave。

薪火相传:一个master的slave同样可以接收其它节点的连接和同步请求,成为其它节点的master。这么做可以减轻第一个master的写压力。

反客为主:即slaveof no one,使当前节点不再是其它节点的slave,自己成为master。

2.4.5 哨兵模式

哨兵模式:后台监控master。当master发生故障时,所有slave会进行投票选举,从slave中选出新的master。

1.配置哨兵

在redis.conf所在目录下新建sentinel.conf文件(文件名称不能出错)。

sentinel.conf文件内容:

sentinel monitor 自定义的被监控数据库名称 127.0.0.1 6379 1

    最后的数字1表示master挂掉后slave选举时得到1票的slave成为主机。

示例:

一组sentinel能同时监控多个master。

2.启动哨兵

3.关闭master,选举出新的master

(127.0.0.1:6381成为新的master)

4.重启之前的master,之前的master自动成为新master的slave

 

3.Redis的安装、使用和调优

3.1 Redis的安装

Redis官网:https://redis.io/

Redis基本上都是在Linux操作系统中安装和应用。

Linux安装:

1.从官网下载Redis,把压缩包(我下载到的版本是redis-6.0.10.tar.gz)放到Linux系统的/opt/目录下。

如果你是在电脑上安装了Linux系统的虚拟机,并且把压缩包下载到了Windows系统的主机上,可以参考下面链接文章将压缩包上传到虚拟机。

https://blog.csdn.net/fengbingchun/article/details/81035861

如果无法连接本地主机网络和虚拟机网络,可以参考下面链接文章。

https://www.cnblogs.com/shireenlee4testing/p/9469650.html

2.进入/opt/目录,解压Redis压缩包redis-6.0.10.tar.gz,解压完成后/opt/目录下出现目录redis-6.0.10

tar -zxvf redis-6.0.10.tar.gz

3.进入redis-6.0.10目录,执行make命令(输入make,回车),安装Redis

如果此时报错:structredisServer没有名为XXXX的成员,可以参考下面链接文章。

https://blog.csdn.net/qq_43527936/article/details/109447519

4.make完成后执行make install命令(输入make install,回车)

5.查看默认安装目录/usr/local/bin/

3.2 Redis的使用

1.在Redis的安装路径下,可以找到Redis配置文件redis.conf(建议备份这个文件):

2.修改redis.conf:

vi redis.conf

找到如图所示的内容,将daemonize(守护进程)改为yes。

按i键进入编辑模式,修改完成后按Esc键退出编辑模式,输入:wq保存退出。

3.启用redis服务

redis-server

4.启用redis客户端

redis-cli

5.ping

3.3 Redis调优

 

加油!(ง •_•)ง

展开阅读全文
打赏
0
0 收藏
分享
加载中
更多评论
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部