目录
6.2.8 dbsize命令——查看当前数据库中key的数目
(1)数据存储方式不同
关系型和非关系型数据库的主要差异是数据存储的方式。
关系型:依赖于关系模型E-R图,同时以表格式的方式存储数据 非关系型:除了以表格形式存储之外,通常会以大块的形式组合在一一起进行存储数据
(2)扩展方式不同
SQL和NoSQL数据库最大的差别可能是在扩展方式上,要支持日益增长的需求当然要扩展。
关系:纵向(天然表格式) 非关:横向(天然分布式)
(3) 对事务性的支持不同
关系型数据库: 实例->数据库->表(table)->记录行(row)、数据字段(column)
关系型数据库:1.安全性高(持久化)2.事务处理能力强 3.任务控制能力强 4.可以做日志备份、恢复、容灾的能力更强一点。
非关系型数据库:1.数据保存在缓存中,利于读取速度/查询数据 2.架构中位置灵活 3.分布式、扩展性高
非关系型数据库: 实例->数据库->集合(collection)–>键值对(key-value) 非关系型数据库不需要手动建数据库和集合(表)。
Redis作为基于内存运行的数据库,缓存是其最常应用的场景之一。除此之外,Redis常见应用场景还包括获取最新N个数据的操作、排行榜类应用、计数器应用、存储关系、实时分析系统、日志记录。
Redis 6.0版本前一直是单线程方式处理用户的请求,在Redis 6.0 中新增的多线程也只是针对处理网络请求过程采用了多线程,而数据的读写命令,仍然是单线程处理的。
单线程为何如此快?
纯内存
非阻塞
避免线程切换和竞态消耗
- 1)# 关闭防火墙和SElinux
- systemctl stop firewalld
- systemctl disable firewalld
- setenforce 0
-
- 2)#安装gcc gcc-c++ 编译器
- yum install -y gcc gcc-c++ make
-
- 3)#切换至/opt目录,把下载好的安装包上传进来并解压
- cd /opt/
- tar zxvf redis-5.0.7.tar.gz
-
- 4)#进入目录然后编译安装
- cd /opt/redis-5.0.7/
- make
- make PREFIX=/usr/local/redis install
-
- #由于Redis源码包中直接提供了Makefile 文件,所以在解压完软件包后,不用先执行./configure 进行配置,可直接执行make与make install命令进行安装
-
- 5)#执行install_server.sh脚本
- cd /opt/redis-5.0.7/utils
- ./install_server.sh #一路回车,指导让你输入路径这一步
- #路径需要手动输入
- Please select the redis executable path [] /usr/local/redis/bin/ redis-server
-
- Selected config:
- Port : 6379 #默认侦听端口为6379
- Config file : /etc/redis/6379.conf #配置文件路径
- Log file : /var/log/redis_6379.log #日志文件路径
- Data dir : /var/lib/ redis/6379 #数据文件路径
- Executable : /usr/local/redis/bin/redis-server #可执行文件路径
- Cli Executable : /usr/local/redis/bin/redis-cli #客户端命令工具
-
- 6)#优化路径并查端口是否打开
- #把redis的可执行程序文件放入路径环境变量的目录中便于系统识别
- ln -s /usr/local/redis/bin/* /usr/local/bin/
-
- #当install_server.sh 脚本运行完毕,Redis 服务就已经启动,默认侦听端口为6379
- netstat -natp | grep redis
-
- 7)#修改配置文件
- vim /etc/redis/6379.conf
- bind 127.0.0.1 192.168.10.8 #70行,添加监听的主机地址
- port 6379 #93行,Redis默认的监听端口
- daemonize yes #137行,启用守护进程
- pidfile /var/run/redis_6379.pid #159行,指定PID文件
- loglevel notice #167行,日志级别
- logfile /var/log/redis_6379.log #172行,指定日志文
-
- 8) #重启redis查看监听的地址
- /etc/init.d/redis_6379 restart #重启
- ss -antp|grep redis
-
- 9)##Redis服务控制
- /etc/init.d/redis_6379 stop #停止
- /etc/init.d/redis_6379 start #启动
- /etc/init.d/redis_6379 restart #重启
- /etc/init.d/redis_6379 status #状态
(1)#关闭防火墙和增强

(2)#安装gcc gcc-c++ 编译器

(3)#切换至/opt目录,把下载好的安装包上传进来并解压 
(4)#进入目录然后编译安装

(5)#执行install_server.sh脚本

(6)#优化路径并查端口是否打开

(7)#修改配置文件
(8)#重启redis查看监听的地址

- rdb 和 aof 是redis服务中持久化功能的两种形式
- redis-cli常用于登陆至redis数据库

- #语法:
- redis-cli -h host -p port -a password
-
- #选项:
- -h :指定远程主机
- -p :指定Redis 服务的端口号
- -a :指定密码,未设置数据库密码可以省略-a选项
- -n :指定进入库的序列号
- 若不添加任何选项表示,则使用127.0.0.1:6379 连接本机上的 Redis 数据库,
-
- #示例
- redis-cli -h 192.168.10.8 -p 6379


redis-benchmark 是官方自带的 Redis 性能测试工具,可以有效的测试 Redis 服务的性能。
- #语法
- redis-benchmark [选项] [选项值]

示例1: 向IP地址为192.168.10.8、端口为6379的Redis服务器发送100个并发连接与100000个请求测试性能。
redis-benchmark -h 192.168.10.8 -p 6379 -c 100 -n 100000


示例2:测试存取大小为100字节的数据包的性能。
redis-benchmark -h 192.168.10.8 -p 6379 -q -d 100

示例3:测试本机上Redis 服务在进行set与lpush操作时的性能。
- set: 存放数据,命令格式为 set key value
- get: 获取数据,命令格式为 get key






- #命令格式:
- rename 源key 目标key
-
- 使用rename命令进行重命名时,无论目标key是否存在都进行重命名,且源key的值会覆盖目标key的值。在实际使用过程中,建议先用 exists命令查看目标key是否存在,然后再决定是否执行rename命令,以避免覆盖重要数据。


- #命令格式:
- renamenx 源key 目标key
-
- # renamenx 命令的作用是对已有key进行重命名,并检测新名是否存在,如果目标key存在则不进行重命名。 (不覆盖)



- #使用config set requi repass yourpassword 命令设置密码
- 127.0.0.1:6379> config set requirepass 123456
- #使用config get requi repass命令查看密码(一旦设置密码,必须先验证通过密码,否则所有操作不可用)
- 127.0.0.1:6379> config get requirepass
- (error) NOAUTH Authentication required.
- 127.0.0.1:6379> auth 123456
- OK
- 127.0.0.1:6379> config get requirepass
- 1) "requirepass"
- 2) "123456"

- 127.0.0.1:6379> config set requirepass ''
- #以上不设置,无法重启redis

Redis支持多数据库,Redis 默认情况下包含16个数据库,数据库名称是用数字0-15 来依次命名的。 多数据库相互独立,互不干扰。
- 命令格式: select 序号
- 使用redis-cli连接Redis数据库后,默认使用的是序号为0的数据库。
- select 1 #切换至序号为10的数据库
- select 15 #切换至序号为15的数据库
- select 0 #切换至序号为0的数据库

- 格式:move 键值 序号
- 127.0.0.1:6379> set yy 100
- OK
- 127.0.0.1:6379> get yy
- "100"
- 127 .0.0.1:6379> select 1
- OK
- 127 .0.0.1:6379[1]> get yy
- (nil)
- 127.0.0.1:6379[1]> select 0 #切换至目标数据库0
- OK
- 127 .0.0.1:6379> move yy 1 #将数据库0中A移动到数据库1中
- (integer) 1
- 127.0.0.1:6379> get yy #在数据库0中无法查看到A的值
- (nil)
- 127.0.0.1:6379> select 1 #切换至目标数据库1
- OK
- 127.0.0.1:6379[1]> get yy #查看被移动数据
- "100"


- FLUSHDB:清空当前数据库数据
- FLUSHALL :清空所有数据库的数据,慎用!


Redis是内存数据库,数据都是存储在内存中,为了避免服务器断电等原因导致Redis进程异常退出后数据的永久丢失,需要定期将Redis中的数据以某种形式(数据或命令)从内存保存到硬盘;当下次Redis重启时,利用持久化文件实现数据恢复。除此之外,为了进行灾难备份,可以将持久化文件拷贝到一个远程位置。
总结:由于AOF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AOF是目前主流的持久化方式,不过RDB持久化仍然有其用武之地 。
RDB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化),用二进制压缩存储,保存的文件后缀是rdb;当Redis重新启动时,可以读取快照文件恢复数据。
RDB持久化的触发分为:手动触发和自动触发两种。
①手动触发
②自动触发
在自动触发RDB持久化时,Redis也会选择bgsave而不是save来进行持久化。
- #通过配置设置触发
- save m n
- #自动触发最常见的情况是在配置文件中通过save m n,指定当m秒内发生n次变化时,会触发bgsave。
- vim /etc/redis/6379.conf
-
- -----219行--以下三个save条件满足任意一个时,都会引起bgsave的调用
- save 900 1 :当时间到900秒时,如果redis数据发生了至少1次变化,则执行bgsave
- save 300 10 :当时间到300秒时, 如果redis数据发生了至少10次变化,则执行bgsave
- save 60 10000 :当时间到60秒时,如果redis数据发生了至少10000次变化, 则执行bgsave
-
- -----242行--是否开启RDB文件压缩
- rdbcompression yes
-
- -----254行--指定RDB文件名
- dbfilename dump.rdb
-
- -----264行--指定RDB文件和AOF文件所在目录
- dir /var/lib/redis/6379



③ 其他自动触发机制
除了 savemn 以外,还有一些其他情况会触发bgsave:
在主从复制场景下,如果从节点执行全量复制操作,则主节点会执行bgsave命令,并将rdb文件发送给从节点。
执行shutdown命令时,自动执行rdb持久化。
与RDB相比,AOF的实时性更好,因此已成为主流的持久化方案。
Redis服务器默认开启RDB,关闭AOF的, 要开启AOF,需要在/etc/redis/6379.conf配置文件中配置。
- vim /etc/redis/6379.conf
- --700行--修改,开启AOF
- appendonly yes
- --704行--指定A0F文件名称
- appendfilename "appendonly.aof"
- --796行--是否忽略最后一条可能存在问题的指令
- aof-load-truncated yes
-
- /etc/init.d/redis_6379 restart 重启服务



由于需要记录Redis的每条写命令,因此A0F不需要触发,AOF的执行流程如下:
命令追加(append): 将Redis的写命令追加到缓冲区aof_ buf;
文件写入(write)和文件同步(sync):根据不同的同步策略将aof_buf中的内容同步到硬盘;
文件重写(rewrite): 定期重写AOF文件,达到压缩的目的。
- vim /etc/redis/6379.conf
-
- ---729---
- ● appendfsync always:
- 解释:命令写入aof_ buf后立即调用系统fsync操作同步到AOF文件,fsync完成后线程返回。
- 这种情况下,每次有写命令都要同步到AOF文件,硬盘IO成为性能瓶颈,Redis只能支持大约几百TPS写入,
- 严重降低了Redis的性能;即便是使用固态硬盘(SSD),每秒大约也只能处理几万个命令,而且会大大降低SSD的寿命。
-
- ● appendfsync no:
- 解释:命令写入aof_ buf后调用系统write操作,不对AOF文件做fsync同步;
- 同步由操作系统负责,通常同步周期为30秒。这种情况下,文件同步的时间不可控,
- 且缓冲区中堆积的数据会很多,数据安全性无法保证。
-
- ● appendfsynceverysec:
- 解释:命令写入aof_ buf后调用系统write操作,write完成后线程返回;
- fsync同步文件操作由专门的线程每秒调用一次。
- everysec是前述两种策略的折中,是性能和数据安全性的平衡,
- 因此是Redis的默认配置,也是我们推荐的配置。
文件重写能压缩AOF文件的原因
通过上述内容可以看出,由于重写后AOF执行的命令减少了,文件重写既可以减少文件占用的空间,也可以加快恢复速度。
文件重写的触发,分为手动触发和自动触发
①手动触发:直接调用bgrewriteaof命令,该命令的执行与bgsave有些类似:都是fork子进程进行具体的工作,且都只有在fork时阻塞。 ②自动触发:通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEAOF。只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个选项同时满足时,才会自动触发AOF重写,即bgrewriteaof操作。
- vim /etc/redis/6379.conf
- ----771----
- auto-aof-rewrite-percentage 100
- #当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时,发生BGREWRITEAOF操作
- auto-aof-rewrite-min-size 64mb
- #当前A0F文件执行BGREWRITEAOF命令的最小值,避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWR ITEAOF
Redis父进程首先判断当前是否存在正在执行bgsave/bgrewriteaof的子进程,如果存在则bgrewriteaof命令直接返回,如果存在bgsave命令则等bgsave执行完成后再执行
父进程执行fork操作创建子进程,这个过程中父进程是阻塞的。
父进程fork后,bgrewriteaof 命令返回"Background append only file rewrite started" 信息并不再阻塞父进程,并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区,并根据appendfsync策略同步到硬盘,保证原有A0F机制的正确。
由于fork操作使用写时复制技术,子进程只能共享fork操作时的内存数据。由于父进程依然在响应命令,因此Redis使用AOF重写缓冲区(aof_ rewrite_buf) 保存这部分数据,防止新AOF文件生成期间丢失这部分数据。也就是说,bgrewriteaof执行 期间,Redis的写 命令同时追加到aof_ buf和aof_ rewirte_ buf两个缓冲区。
子进程根据内存快照,按照命令合并规则写入到新的AOF文件。
子进程写完新的AOF文件后,向父进程发信号,父进程更新统计信息,具体可以通过info persistence查看。
父进程把AOF重写缓冲区的数据写入到新的AOF文件,这样就保证了新AOF文件所保存的数据库状态和服务器当前状态一致。
使用新的AOF文件替换老文件,完成AOF重写。
重写期间Redis执行的写命令,需要追加到新的AOF文件中,为此Redis引入了aof_ rewrite_buf缓存
1.数据库
关系型数据库:实例–>数据库–>表(table)–>记录行(row)、数据字段(column)
非关系型数据库:实例–>数据库–>集合(collection) -->键值对(key-value)
非关系型数据库不需要手动建数据库和集合(表)
2.redis测试工具
Redis命令工具中的 RDB 和 AOF 是redis服务中持久化功能的两种形式
redis-cli命令行工具(远程登录)
redis-benchmark 测试工具(有效的测试 Redis 服务的性能)
3.redis数据库命令
set 、get和del :存放、获取和删除数据
keys:获取key,可以结合通配符 * 和 ?
exists和type:判断key是否存在和判断类型
rename和renamenx:重命名的两种,后者会进行判断,存在则不改
dbsize:查看当前数据库中key的数目
4.Redis多数据库常用命令
select 序号 :切换库名(16个数据库,数据库名称是用数字0-15)
move 键值 序号:多数据库间移动数据
FLUSHDB :清空当前数据库数据
FLUSHALL :清空所有数据库的数据
5.Redis 高可用
含义:高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常服务。
组成:实现高可用的技术主要包括持久化、主从复制、哨兵和集群。
6.高可用中的持久化:RDB与AOF
(1) 持久化方式:
RDB:周期性的快照
AOF:接近实时的持久化(以everysec方式)
(2) redis启用的优先级 AOF > RDB 同时仅当AOF功能关闭的情况下,redis才会再重新启动时使用RDB的方式进行恢复
(3) RDB和AOF中的持久化模式
RDB:由redis主进程(周期性)fork派生出子进程对redis内存中的数据进行持久化,生成到.rdb文件中.
AOF:根据持久化策略(alawys、no、everysec(默认)),先将redis中的语句保存在缓存区中,再从缓冲区同步到.aof文件中.
7.redis的恢复策略/优势 redis与其他常用非关数据库类似,都是将数据保存在内存中 而保存在内存中时,当redis重启,内存数据丢失,但redis通过RDB或AOF的持久化功能可以在redis进行重启之后,优先读取AOF文件,基于AOF文件进行数据恢复这种方式来“持久化保存”数据。