NoSQL之Redis配置

安装

[root@redis01 ~]# yum -y install gcc gcc-c++ make

在这里插入图片描述

[root@redis01 ~]# tar zxvf redis-5.0.7.tar.gz -C /opt/

在这里插入图片描述

[root@redis01 opt]# cd /opt/redis-5.0.7/
[root@redis01 redis-5.0.7]# make
[root@redis01 redis-5.0.7]# make PREFIX=/usr/local/redis install

在这里插入图片描述

执行软件包提供install.sh脚本文件设置Redis服务所需要的相关配置文件

[root@redis01 redis-5.0.7]# cd /opt/redis-5.0.7/utils
[root@redis01 utils]# ./install_server.sh
…………
Please select the redis executable path [] /usr/local/redis/bin/redis-server 需要手动修改为/usr/local/redis/bin/redis-server要一次性正确输入

在这里插入图片描述

Redis设置环境变量

[root@redis01 utils]# ln -s /usr/local/redis/bin/* /usr/local/bin/

修改配置文件

[root@redis01 utils]# vim /etc/redis/6379.conf

bind 127.0.0.1 192.168.235.179   #70行,添加监听的主机地址
port 6379   #93行,Redis默认的监听端口
daemonize yes #137行,启用守护进程
pidfile /var/ run/redis_6379.pid  #159行,指定PID文件
loglevel notice    #167行,日志级别
logfile lvar/ log/ redis_6379.log   #172行,指定日志文件

[root@redis01 utils]# /etc/init.d/redis_6379 restart

在这里插入图片描述

###  Redis命令工具
redis-server:用于启动Redis 的工具
redis-benchmark:用于检测Redis在本机的运行效率
redis-check-aof:修复AOF持久化文件
redis-check-rdb :修复RDB持久化文件
redis-cli: Redis 命令行工具.
rdb和aof是redis服务中持久化功能的两种形式RDB AOF
redis-cli 常用于登陆至redis数据库

### redis-cli 命令行工具(远程登陆)
语法: redis-cli -h host -p port -a password
-h:指定远程主机
-p :指定Redis 服务的端口号
-a :指定密码,未设置数据库密码可以省略-a选项
若不添加任何选项表示,则使用127.0.0.1:6379连接本机上的 Redis 数据库,
redis-cli -h 192.168.235.179 -p 6379

###  redis-benchmark 测试工具
redis-benchmark 是官方自带的Redis 性能测试工具,可以有效的测试Redis 服务的性能。
基本的测试语法:redis-benchmark[选项] [选项值]
-h:指定服务器主机名。
-p :指定服务器端口
-s :指定服务器socket (套接宁)
-c :指定并发连接数
-n :指定请求数。
-d :以字节的形式指定SET/GET值的数据大小
-k : 1=keep alive0=reconnect
-r : SET/GET /INCR使用随机key,SADD使用随机值。
-P :通过管道传输<numreq>请求。
-q:强制退出redis。仅显示query/sec值
--csv :以csv格式输出。.
-l :生成循环,永久执行测试。
-t:仅运行以逗号分隔的测试命令列表。
-I : Idle模式。仅打开N个idle连接并等待

测试存取大小为100字节的数据的性能

[root@redis01 utils]# redis-benchmark -h 192.168.235.179 -p 6379 -q -d 100

在这里插入图片描述

测试本机Redis 服务在进行set与lpush操作时性能

[root@redis01 utils]# redis-benchmark -t set,lpush -n 10000 -q

在这里插入图片描述

Redis数据库常用命令

set:存放数据,命令格式为set key value
get:获取数据,命令格式为get key

127.0.0.1:6379> set teacher lisi
OK
127.0.0.1:6379> get teacher
"lisi"

keys命令可以取符合规则的键值列表,通常情况可以结合*、?等选项来使用。

在这里插入图片描述

127.0.0.1:6379> keys *  查看当前数据中所有键

在这里插入图片描述

127.0.0.1:6379> keys k*  查看当前数据中以k开头的数据

在这里插入图片描述

exists命令可以判断键值是否存在

127.0.0.1:6379> exists teacher  判断teacher键是否存在
(integer) 1                     1表示teacher键是存在
127.0.0.1:6379> exists tea     
(integer) 0                     0表示tea键不存在

del命令可以删除当前数据库的指定key

127.0.0.1:6379> del v1

在这里插入图片描述

rename命令是对已有key进行重名

在这里插入图片描述

rename n不进行修改 x进行修改

127.0.0.1:6379> get teacher
"lisi"
127.0.0.1:6379> get v5
"5"
127.0.0.1:6379> renamenx v5 teacher
(integer) 0

dbsize命令的作用是查看当前数据库中key的数目

127.0.0.1:6379> dbsize
(integer) 10

设置密码

127.0.0.1:6379> config set requirepass 123

删除密码

127.0.0.1:6379> auth 123
OK
127.0.0.1:6379> config set requirepass ''
OK
[root@redis01 utils]# redis-cli -h 192.168.235.179 -p 6379
192.168.235.179:6379> keys *

在这里插入图片描述

Redis 多数据库常用命令

Redis支持多数据库,Redis默认情况下包含16个数据库,数据库名称是用数字0-15来依次命名的。多数据库相互独立,互不干扰。

多数据库间切换

在这里插入图片描述

多数据库间移动数据

在这里插入图片描述

清除数据库内数据(rm -rf)

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

关系型数据库

关系型数据库是一个结构化的数据库,创建在关系模型〈二维表格模型〉基础上(E-R图),一般面向于记录。
SQL语句(标准数据查询语言)就是一种基于关系型数据库的语言,用于执行对关系型数据库中数据的检索和操作。
主流的关系型数据库包括Oracle、MysQL、sQL Server、Microsoft Access、DB2等。

非关系型数据库( nosql)

NosQL(NoSQL=Not only sQL),意思是"不仅仅是sQI",是非关系型数据库的总称。12除了主流的关系型数据库外的数据库,都认为是非关系型。
主流的 NoSQL数据库有Redis、MongBD、 Hbase、Memcached Postgresql (pg)等。
TSDB 时序数据:起步不是IT

1. 数据存储方式不同

关系型和非关系型数据库的主要差异是数据存储的方式。关系型数据天然就是表格式的,因此存储在数据表的行和列中。数据表可以彼此关联协作存储,也很容易提取数据。
与其相反,非关系型数据不适合存储在数据表的行和列中,而是大块组合在一起。非关系型数据通常存储在数据集中,就像文档、键值对或者图结构。你的数据及其特性是选择数据存储和提取方式的首要影响因素。

  1. 关系型:依赖于关系模型E-R图,同时以表格式的方式存储数据
  2. 非关系型:除了以表格形式存储之外,通常会以大块的形式组合在一起进行存储数据
2.扩展方式不同

SQL和INosQL,数据库最大的差别可能是在扩展方式上,要支持日益增长的需求当然要扩展.
要支持更多并发量,SQL数据库是纵向扩展,也就是说提高处理能力,使用速度更快速的计算机,这样处理相同的数据集就更快了。因为数据存储在关系表中,操作的性能瓶颈可能涉及很多个表,这都需要通过提高计算机性能来克服。虽然SQL数据库有很大扩展空间,但最终肯定会达到纵向扩展的上限。
而NoSQL数据库是横向扩展的。因为非关系型数据存储天然就是分布式的,NoSQL数据库的扩展可以通过给资源池添加更多普通的数据库服务器(节点)来分担负载。
1)关系:纵向(天然表格式)
2)非关:横向(天然分布式)

3.对事务性的支持不同

如果数据操作需要①高事务性或者②复杂数据查询③需要控制执行计划,那么传统的scL数据库从性能和稳定性方面考虑是最佳选择。SQL数据库支持对事务ACID原子性细粒度控制,并且易于回滚事务。
虽然NosQL数据库也可以使用事务操作,但稳定性方面没法和关系型数据库比较,所以它们真正闪亮的价值是在操作的扩展性和大数据量处理方面。
①关系型:特别适合高事务性要求和需要控制执行计划的任务
②非关系:此处会稍显弱势,其价值点在于高扩展性和大数据量处理方面

可用于应对web2.0纯动态网站类型的三高问题。

(1) High performance-------对数据库高并发读写需求
(2) Hugestorage--------------对海量数据高效存储与访问需求
(3) High scalability && High Availability-------^对数据库高可扩展性与高可用性需求
关系型数据库和非关系型数据库都有各自的特点与应用场景,两者的紧密结合将会给web2.0的数据库发展带来新的思路。让关系数据库关注在关系上,非关系型数据库关注在存储上。例如,在读写分离的MysSQL数据库环境中,可以把经常访问的数据存储在非关系型数据库中,提升访问速度。
关系数据库:保存位置 磁盘
非关数据库(内存/缓存数据库):保存的位置是缓存/内存〈效率、速度块)特殊的是redis,因为redis 可以将内存中的51数据保存在磁盘中

Redis具有以下几个优点(比较对象 ①sql数据库 ②其他nosql数据库)

(1)、具有极高的数据读写速度:数据读取的速度最高可达到110000次/s,数据写入速度最高可达到81000 次/s。
(2)、支持丰富的数据类型:支持key-value、Strings、Lists、Hashes(散列值)、Sets 及ordered Sets等数据类型操作。
string字符串(可以为整形、浮点和字符型,统称为元素)
list列表:(实现队列,元素不唯一,先入先出原则)
set集合:(各不相同的元素)
hash hash散列值: (hash的key必须是唯一的)
set /ordered sets 集合/有序集合
(3)支持数据的持久化:可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。
(4)原子性:Redis所有操作都是原子性的。
(5)支持数据备份:即master-salve模式的数据备份。
Redis作为基于内存运行的数据库,缓存是其最常应用的场景之一。除此之外,Redis常见应用场景还包括获取最新t个数据的操作、排行榜类应用、计数器应用、存储关系、实时分析系统、日志记录。

Redis高可用

在web服务器中,高可用是指服务器可以正常访问的时间,衡量的标准是在多长时间内可以提供正常服务(99.98、99.998、99.999%等等)。
但是在Redis语境中,高可用的含义似乎要宽泛一些,除了保证提供正常服务(如主从分离、快速容灾技术),还需要考虑数据容量的扩展,数据安全不会丢失等。
在Redis中,实现高可用的技术主要包括持久化、主从复制、哨兵和集群,下面分别说明它们的作用,以及解决了什么样的问题。

持久化

持久化是最简单的高可用方法(有时甚至不被归为高可用的手段),主要作用是数据备份,即将数据存储在硬盘,保证数据不会因进程退出而丢失。

主从复制

主从复制是高可用Redis的基础,哨兵和集群(cluster)都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份,以及对于读操作的负载均衡和简单的故障恢复。缺陷:故障恢复无法自动化;写操作无法负载均衡;存储能力受到单机的限制(吃资源)
哨兵:在主从复制的基础上,哨兵实现了自动化的故障恢复。缺陷:写操作无法负载均衡;存储能力受到单机的限制。
集群(cluster):通过集群
Redis解决了写操作无法负载均衡,以及存储能力受到单机限制的问题,实现了较为完善的高可用方案

Redis持久化

持久化的功能:

Redis是内存数据库,数据都是存储在内存中,为了避免服务器断电等原因导致Redis进程异常退出后数据的永久丢失,需要定期将Redis中的数据以某种形式(或命数据令)从内存保存到硬盘;当下次Redis重启时,利用持久化文件实现数据恢复。除此之外,为了进行灾难备份,可以将持久化文件拷贝到一个远程位置(NFS)。

Redis提供两种方式进行持久化:

RDB持久化:原理是将Reids在内存中的数据库记录定时保存到磁盘上。(类似快照)
AOF持久化(append only file)
:原理是将Reids的操作日志以追加的方式写入文件,类似于MysQL的binlog。(基于日志持久化方式)
由于AoF持久化的实时性更好,即当进程意外退出时丢失的数据更少,因此AoF是目前主流的持久化方式,Rhe持久化基木都会开启(用于集群)

RDB持久化

RDB持久化是指在指定的时间间隔内将内存中当前进程中的数据生成快照保存到硬盘(因此也称作快照持久化),用二进制压缩存储,保存的文件后缀是rdb;当Redis重新启动时,可以读取快照文件恢复数据。

RDB:

周期性1-10秒(会进行一定的限制,第二周期过于短暂会导致数据同步冗余的情况)
保存形式:二进制压缩存储( .rdb )
可用于恢复,redis重启后,缓存中的数据会清空,此时redis 中的数据就是基于, rdb文件进行恢复的

触发条件

RDB持久化的触发分为手动触发和自动触发两种

(1)、手动触发
save命令和bgsave命令都可以生成RDB文件。
save命令会阻塞Redis服务器进程,直到RDB文件创建完毕为止,在Redis服务器阻塞期间,服务器不能处理任何命令请求。
而ibgsave命令会创建一个子进程,由子进程来负责创建RDB文件,父进程(即Redis主进程)则继续处理请求。
bgsave命令执行过程中,只有fork
子进程时会阻塞服务器,而对于save命令,整个过程都会阻塞服务器,因此save已基本被废弃,线上环境要杜绝save的使用
往往生产环境bgsave依然不允许轻易使用
( 2)、自动触发
在自动触发RDB持久化时,Redis也会选择bgsave而不是save来进行持久化
save m n
自动触发最常见的情况是在配置文件中通过save m n,指定当m秒内发生n次变化时,会触发bgsave。

[root@redis01 ~]# vim /etc/redis/6379.conf
save 900 1 :当时间到90o秒时,如果redis数据发生了至少1次变化,则执行bgsave
save 300 10 :当时间到30o秒时,如果redis数据发生了至少10次变化,则执行bgsave
save 60 10000 :当时间到60秒时,如果redis数据发生了至少10000次变化,则执行bgsave
rdbcompression yes   是否开启RDB文件压缩
dbfilename dump.rdb   指定RDB文件名
dir /var/ lib/redis/6379  指定RDB文件和AOF文件所在目录

其他自动触发机制

除了save m n以外,还有一些其他情况会触发bgsave
在主从复制场景下,如果从节点执行全量复制操作,则主节点会执行bgsave命令,并将rdb文件发送给从节点。
执行shutdown命令时,自动执行rdb持久化。

执行流程

(1) Redis父进程首先判断 :当前是否在执行save,或bgsave/bgrewriteaof的子进程,如果在执行则bgsave命令直接返回.
bgsave/bgrewriteaof 的子进程不能同时执行,主要是基于性能方面的考虑:两个并发的子进程同时执行大量的磁盘写操作,可能引起严重的性能问题。
(2〉父进程执行fork操作创建子进程,这个过程中父进程是阻塞的,Redis不能执行来自客户端的任何命令
(3)父进程fork后,bgsave命令返回"Background saving started"信息并不再阻塞父进程,并可以响应其他命令445
(4)子进程创建RDB文件,根据父进程内存快照生成临时快照文件,完成后对原有文件进行原子替换
(5)子进程发送信号给父进程表示完成,父进程更新统计信息

启动时加载

RDB文件的载入工作是在服务器启动时自动执行的,并没有专门的命令。但是由于AoF的优先级更高,因此当AoF开启时,Redis会优先载入AOF文件来恢复数据;仅当AOF关闭时,才会在Redis服务器启动时检测RDB文件,并自动载入。服务器载入RDB文件期间处于阻塞状态,直到载入完成为止。
Redis载入RDB文件时,会对RDB文件进行校验,如果文件损坏,则日志中会打印错误,Redis启动失败。451 RDB 和AOF 以优先级而言AOF 》RDB
在服务器时,r仅档AoF功能关闭,才会载入RDB文件
启动过程中进行持久化文件的检测校验,若损坏,则打印错误,启动失败。

开启AOF

[root@redis01 ~]# vim /etc/redis/6379.conf
appendonly yes   开启AOF
appendfilename "appendonly.aof"  指定A0F文件名称
aof-load-truncated yes  是否忽略最后一条可能存在问题的指令
[root@redis01 ~]# /etc/init.d/redis_6379 restart

在这里插入图片描述

执行流程

由于需要记录Redis的每条写命令,因此AOF不需要触发,下面介绍AoF的执行流程

AOF的执行流程包括:

命令追加(append):将Redis的写命令追加到缓冲区aof_buf;(为了尽量不因为持久化而影响redis性能)
文件写入(rite)和文件同步(sync):根据不同的同步策略将aof_buf中的内容同步到硬盘;
文件重写(rewrite):定期重写AoF文件,达到压缩的目的。

(1)命令追加(append)

Redis先将写命令追加到缓冲区,而不是直接写入文件,主要是为了避免每次有写命令都直接写入硬盘,导致硬盘To成为Bedis负载的瓶颈。
命令追加的格式是Redis命令请求的协议格式,它是一种纯文本格式,具有兼容性好、可读性强、容易处理、操作简单避免二次开销等优点。在AOF文件中,除了用于指定数据库的select命令(如select 0为选中0号数据库)是由Redis添加的,其他都是客户端发送来的写备令。

(2)文件写入(write)和文件同步(sync)

Redis提供了多种AoF缓存区的同步文件策略,策略涉及到操作系统的write函数和fsync函数,说明如下:
为了提高文件写入效率,在现代操作系统中,当用户调用write函数将数据写入文件时,操作系统通常会将数据哲存到一个内存缓冲区里,当缓冲区被填满或超过了指定时限后,才真正将缓冲区的数据写入到硬盘里。这样的操作虽然提高了效率,但也带来了安全问题;如果计算机停机,内存缓冲区中的数据会丢失;因此系统同时提供了fsync、fdatasync等同步函数,可以强制操作系统立刻将缓冲区中的数据写入到硬盘里,从而尽可能确保数据的安全性

RDB和AOF的优缺点

(一) 、RDB持久化(以二进制压缩的方式保存的文件)

优点:RDB文件紧凑,体积小,网络传输快,适合全量复制;恢复速度比AoF快很多。当然,与AOF相比,RDB最重要的优点之一是对性能的影响相对较小。(和aof同步阻塞)
缺点:RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化,而在数据越来越重要的今天,数据的大量丢失很多时候是无法接受的,因此AoE持久化成为主流。此外,RDB文件需要满足特定格式,兼容性差(如老版本的Redis不兼容新版本的RDB文件)。
对于RDB持久化,一方面是bgsave在进行fork操作时Redis主进程会阻塞,另一方面,子进程向硬盘写数据也会带来To压力

(二) 、 AOF持久化

与RDB持久化相对应,AoF的优点在于支持秒级持久化、兼容性好,缺点是文件大、恢复速度慢、对性能影响大。
对于AOF持久化,向硬盘写数据的频率大大提高(everysec策略下为秒级),To压力更大,甚至可能造成AOF追加阻塞问题。587 AOF文件的重写与RDB的bgsave类似,会有fork时的阻塞和子进程的To压力问题。相对来说,由于ROF向硬盘中写数据的频率更高,国此对Redis主进程性能的影响会更大。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值