一.数据库类型：

除了“关系型数据库”，其它类型的数据库统称为 NoSQL 数据库。NoSQL = Not Only SQL ，也即“不仅仅是 SQL”。不需要先建库建表记录不同数据类型数据.

1.两者区别:

（1）存储方式

关系:

行（记录对象信息）

列（对象属性）存储在二维表格

非关系：

存储在数据集，表现形式：文档，键值，数据结构方式。

（2）扩展方式不同

关系型数据库，通常纵向扩展，扩展硬件资源提高计算能力。

非关系型数据库：

横向扩展（扩展节点的数量）

（3）事务支持

关系型数据库：事务控制的细粒度极高，更稳定，更易回滚事务

非系型数据库：支持事务稳定性没关系型数据库优良，扩展和处理大数据上更好

用于应对三高（高并发，高性能，高可用）

两者区别：

库 ———— 表------行----数据字段

实例--数据库----集合---键值对

2.redis简介

开源，c语言编写存储方式为key-value（键值对）存储形式
基于内存运行：数据放在内存中的
单进程单线程运行

3.redis优点

1s 110000次读取速度数据写入速度可高达81000次。

丰富数据类型：

支持数据持久化：内存保存在磁盘中，下次开启时直接加载使用

支持五大数据类型：

key-value（键值对） , string （字符串）, hash（散列）sets(无序)sorted sets（有序）

4.使用场景

给关系型数据库作缓存加速，提高访问速度

session会话保持缓存

redis应用在缓存，队列，排行榜，热点，弱一致性，逻辑简单的场景。。访问量大，数据短时间不会更新

5.redis为什么快？

基于内存运行，避免磁盘耗时操作
采用单线程处理数据读写，减少了锁竞争，以及避免创建线程和销毁线程的资源消耗。
采用IO多路复用机制，非阻塞，大大提升并发效率（epoll模式）

6.redis安装部署

 #关闭防火墙systemctl stop firewalldsetenforce 0#安装环境依赖包yum install -y gcc gcc-c++ make#上传软件包并解压cd /opt/tar zxvf redis-5.0.7.tar.gz -C /opt/cd /opt/redis-5.0.7/#开2核编译安装，指定安装路径为/usr/local/redistar zxvf redis-5.0.7.tar.gz -C /opt/#由于Redis源码包中直接提供了Makefile 文件，所以在解压完软件包后，不用先执行./configure 进行配置，可直接执行make与make install命令进行安装。#执行软件包提供的install_server.sh 脚本文件，设置Redis服务所需要的相关配置文件cd /opt/redis-5.0.7/utils./install_server.sh.......#一直回车Please select the redis executable path [] /usr/local/redis/bin/redis-server#这里默认为/usr/local/bin/redis-server，需要手动修改为/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/bin/redis-cli #客户端命令工具 --------------------------------------------

#当install_server.sh 脚本运行完毕，Redis 服务就已经启动，默认监听端口为6379

netstat -natp | grep redis

#把redis的可执行程序文件放入路径环境变量的目录中便于系统识别 ln -s /usr/local/redis/bin/* /usr/local/bin/

vim /etc/redis/6379.conf

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 #查看状态

---------------------- #编辑配置文件，参数 vim /etc/redis/6379.conf ------------------------

bind 127.0.0.1 192.168.6.169 #监听的IP地址

93 port 6379 #监听端口

137 daemonize yes #使用守护进程的方式启动，即后台启动 159 pidfile /var/run/redis_6379.pid #Redis的进程号保存位置

172 logfile /var/log/redis_6379.log #日志保存的位置

187 databases 16 #监听库的数量（编号0-15）

/etc/init.d/redis_6379 restart #重启redis服务

redis-cli：Redis 命令行工具

 语法：redis-cli -h host -p port -a password-h：指定远程主机机-p：指定Redis服务的端口号-a：指定密码，未设置数据库密码可以省略-a选项#-a选项若不添加任何选项表示使用127.0.0.1:6379连接本机上的Redis数据库#登录本机redis-cli#远程登录redis-cli -h 192.168.6.188 -p 6379 [-a 密码]

7. redis-benchmark 测试工具

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

 基本的测试语法：redis-benchmark [选项] [选项值]-h：指定服务器主机名。-p：指定服务器端口。-s：指定服务器 socket-c：指定并发连接数。-n：指定请求数。-d：以字节的形式指定SET/GET值的数据大小。-k：l=keep alive 0=reconnect -r：SET/GET/INCR 使用随机key,SADD使用随机值-P：通过管道传输<numreg>请求-q：强制退出redis，仅显示query/sec值--csv：以CSV格式输出-l：生成循环,永久执行测试-t：仅运行以逗号分隔的测试命令列表-I：Idle模式，仅打开N个idle连接并等待

8.向IP地址为192.168.6.188、端口为6379 的Redis 服务器发送100个并发连接与10000 个请求测试性能。

9.Redis数据库常用命令

命令	作用
set	存放数据
get	获取数据
keys *	查看所有的key
keys k？	查看k开头后面任意一位的数据
exists	判断键是否存在（存在1，不存在0）
del	删除键
type	查看键对应的value值类型
rename key1 key2	改名，不管key2是否存在都会改名成功。如果存在，key1的值会覆盖key2得值
renamenx key1 key2	改名，若key2不存在，可以改名成功。若key2存在则不进行改名
dbsize	查看当前数据库中key的数目

二.redis高可用

简介:

在web服务器中，高可用是指服务器可以正常访问的时间，衡量的标准是在多长时间内可以提供正常服务（99.9%、99.99%、99.999%等等）
但是在Redis语境中，高可用的含义似乎要宽泛一些，除了保证提供正常服务（如主从分离、快速容灾技术），还需要考虑数据容量的扩展、数据安全不会丢失等.

redis实现高可用技术

1.持久化

主要是数据备份到磁盘。

2.主从复制（redis基础）

主从复制实现了数据多机备份，读操作的负载均衡和简单的故障恢复

缺：故障恢复无法自动化，写无法负载均衡

3.哨兵

主从复制基础上实现自动化故障恢复

写操作无法负载均衡，存储能力受单机限制

4.cluster集群

解决写操作无法负载均衡，以及存储能力受单机限制问题

实现了较为完善高可用方案

三、Redis主从复制

主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点（Master），后者称为从节点（slave）；数据的复制是单向的，只能由主节点到从节点。

默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

1 主从复制的作用

数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。
故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
负载均衡： 在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。
高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

Redis主从架构可以解决单机的读写瓶颈问题，但是没有自动故障转移功能，不能解决master单点故障问题。

2. 主从复制流程（步骤）

1.若启动一个Slave机器进程，则它会向Master机器发送一个"sync command"命令，请求同步连接；

2.无论是第一次连接还是重新连接，Master机器都会启动一个后台进程，将数据快照保存到数据文件中（执行rdb操作），同时Master还会记录修改数据的所有命令并缓存在数据文件中；

3.后台进程完成缓存操作之后，Master机器就会向Slave机器发送数据文件，slave端机器将数据文件保存到硬盘上，然后将其加载到内存中，接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机，则恢复正常后会自动重新连接；

4.Master机器收到Slave端机器的连接后，将其完整的数据文件发送给Slave端机器，如果Mater同时收到多个slave发来的同步请求，则Master会在后台启动一个进程以保存数据文件，然后将其发送给所有的Slave端机器，确保所有的slave端机器都正常；

3.REDIS主从复制配置：

主机	操作系统	ip	所需软件
master服务器	Centos7	192.168.6.170	redis-5.0.7
slave1服务器	Centos7	192.168.6.188	redis-5.0.7
slave2服务器	Centos7	192.168.6.169	redis-5.0.7

配置思路

1.准备三台安装好了redis服务器的主机;
2.master节点修改监听地址为0.0.0.0表示任意地址，并且需要开启AOF持久化，重启服务;
3.Slave节点修改监听地址0.0.0.0，开启AOF持久化，需要额外在配置文件287行指定同步的 master节点IP和端口，重启服务。在主服务器写入数据加以验证 ;

修改配置文件：

master配置：192.168.6.170

vim /etc/redis/6379.conf
#70行，修改bind 项，0.0.0.0监听所有网段
bind 0.0.0.0
#137行，开启守护进程
daemonize yes
#172行，指定日志文件目录
logfile /var/log/redis_6379.log
#264行，指定工作目录
dir /var/lib/redis/6379
#700行，开启AOF持久化功能
appendonly yes/etc/init.d/redis_6379 restart

slave1，slave2配置：

vim /etc/redis/6379.conf
#288行,指定要同步master节点IP和端口
replicaof 192.168.6.170 6379

实验效果：vim /var/log/redis_6379.log 查看主机master的日志：

查看主从同步效果：

slave1机的变化：

slave机变化

主机状态：

___---------------------------------------------------_

Redis与memcached比较

	Memcached	Redis
类型	Key-value数据库	Key-value数据库
过期策略	支持	支持
数据类型	单一数据类型	五大数据类型
持久化	不支持	支持
主从复制	不支持	支持
虚拟内存	不支持	支持

四.redis 两种方式持久化

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

AOF：把操作日志追加方式写入文件，类似于MYSQL中binlog

触发条件:

1. 手动触发
save命令和bgsave命令都可以生成RDB文件
1）save命令会阻塞Redis服务器进程，直到RDB文件创建完毕为止，在Redis服务器阻塞期间，服务器不能处理任何命令请求
2）bgsave命令会创建一个子进程，由子进程来负责创建RDB文件，父进程(即Redis主进程)则继续处理请求
bgsave命令执行过程中，只有fork子进程时会阻塞服务器，而对于save命令，整个过程都会阻塞服务器，因此save已基本被废弃，线上环境要杜绝save的使用

执行bgsave出发rdb持久化工作原理：

1.RDB持久化工作原理：

执行bgsave命令触发RDB持久化，redis父进程会进行判断，判断有没有其它子进程有没有

正在执行（rewriteaof/save）如果有直接返回。执行完之后，父进程就会去创建fork子进程

，创建的时候会阻塞父进程，不能接收请求，这个过程转瞬即逝非常快的。创建完之后将返回

给父进程backgroud saving started就不会在阻塞父进程，父进程就会接收请求，此时子进程会去创建rdb文件，创建完成之后将以快照的方式进行保存到磁盘中，完成之后将原有文件进行源自替换，向父进程发送信号表示已完成，父进程更新统计信息。

2. 自动触发

在自动触发RDB持久化时，Redis也会选择bgsave而不是save来进行持久化
自动触发最常见的情况是在配置文件中通过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

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

RDB文件的载入工作是在服务器启动时自动执行的，并没有专门的命令。但是由于AoF的优先级更高，因此当aoF开启时，Redis会优先载入AOF文件来恢复数据:只有当AOF关闭时，才会在Redis服务器启动时检测RDB文件，并自动毂入。服务器载入和RDB文件期间处于阻塞状态，直到载入完成为redis载入.RDB文件时，会对RDB文件进行校验，如果文件损坏，则日志中会打印错误，Redis启动失败。

开启AOF持久化：

RDB持久化是将进程数据写入文件，而AOF持久化，则是将Redis执行的每次写、删除命令记录到单独的日志文件中，查询操作不会记录:当Redis重启时再次执行AOF文件中的命令来恢复数据。

AOF追加到缓冲区

AOF个工作原理图

1.AOF的执行流程包括:
●命令追加(append):将Redis的写命令追加到缓冲区aof _buff；
·文件写入(write)和文件同步(sync):根据不同的同步策略将aof_buff中的内容同步到硬盘:·文件重写(rewrite):定期重写AOF文件，达到压缩的目的。

2. 文件写入（write）和文件同步（sync）

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

3.AoF缓存区的同步文件策略存在三种同步方式，它们分别是:

（vim /etc/redis/6379.conf ----》 729行）
1）appendfsync always：命令写入aof_buf后立即调用系统fsync操作同步到AOF文件，fsync完成后线程返回。这种情况下，每次有写命令都要同步到AOF文件，硬盘IO成为性能瓶颈，Redis只能支持大约几百TPS写入，严重降低了Redis的性能；即便是使用固态硬盘（SSD），每秒大约也只能处理几万个命令，而且会大大降低SSD的寿命
2）appendfsync no：命令写入aof_buf后调用系统write操作，不对AOF文件做fsync同步；同步由操作系统负责，通常同步周期为30秒。这种情况下，文件同步的时间不可控，且缓冲区中堆积的数据会很多，数据安全性无法保证
3）appendfsync everysec：命令写入aof_buf后调用系统write操作，write完成后线程返回；fsync同步文件操作由专门的线程每秒调用一次。everysec是前述两种策略的折中，是性能和数据安全性的平衡，因此是Redis的默认配置，也是我们推荐的配置.

4. 文件重写（rewrite）

随着时间流逝，Redis服务器执行的写命令越来越多，AOF文件也会越来越大；过大的AOF文件不仅会影响服务器的正常运行，也会导致数据恢复需要的时间过长
文件重写是指定期重写AOF文件，减小AOF文件的体积.

1)AOF重写是把Redis进程内的数据转化为写命令，同步到新的AOF文件2)不会对旧的AOF文件进行任何读取、写入操作.
对于AOF持久化来说，文件重写虽然是强烈推荐的，但并不是必须的；即使没有文件重写，数据也可以被持久化并在Redis启动的时候导入；因此在一些实现中，会关闭自动的文件重写，然后通过定时任务在每天的某一时刻定时执行.

文件重写之所以能够压缩AOF文件，原因在于：
1）过期的数据不再写入文件
2）无效的命令不再写入文件：如有些数据被重复设值(set mykey v1, set mykey v2)、有些数据被删除了(sadd myset v1, del myset)等
3）多条命令可以合并为一个：如sadd myset v1, sadd myset v2, sadd myset v3可以合并为sadd myset v1 v2 v3
通过上述内容可以看出，由于重写后AOF执行的命令减少了，文件重写既可以减少文件占用的空间，也可以加快恢复速度.

5.文件重写的触发，分为手动触发和自动触发：

1）手动触发：直接调用bgrewriteaof命令，该命令的执行与bgsave有些类似：都是fork子进程进行具体的工作，且都只有在fork时阻塞.
2）自动触发：通过设置auto-aof-rewrite-min-size选项和auto-aof-rewrite-percentage选项来自动执行BGREWRITEAOF。只有当auto-aof-rewrite-min-size和auto-aof-rewrite-percentage两个选项同时满足时，才会自动触发AOF重写，即bgrewriteaof操作。
① auto-aof-rewrite-percentage 100 ：当前AOF文件大小(即aof_current_size)是上次日志重写时AOF文件大小(aof_base_size)两倍时，发生BGREWRITEAOF操作
② auto-aof-rewrite-min-size 64mb ：当前AOF文件执行BGREWRITEAOF命令的最小值，避免刚开始启动Reids时由于文件尺寸较小导致频繁的BGREWRITEAOF.

注意：

1 ）重写由父进程fork子进程进行
2 ）重写期间Redis执行的写命令，需要追加到新的AOF文件中，为此Redis引入了aof_rewrite_buf缓存.

6. 文件重写的流程

文件重写工作原理：

1.bgrewrite执行时，redis父进程判断有无其它子进程正在进行，如果没有，fork会创建子进程

，创建子进程时会阻塞父进程，创建完后父进程可继续响应请求，子进程开始生成新的AOF文件

同时会把写入数据记录到aof_buf缓存区中，和aof_rewrite_buf缓冲区，aof_buf缓冲区会把同步策略同步到旧的AOF文件中，而aof_rewrite_buf会把数据同步到新的AOF文件中,保证在创建AOF文件时都有这个命令，子进程创建好之后会通知父进程，父进程会更新统计信息。

总结：
Redis 有几种持久化方式？
RDB

按照一定时间间隔对redis在内存运行的进程数据进行快照压缩保存到磁盘当中
优点：文件体积小，网络传输快，恢复速度也快，对性能的影响较小。
缺点：无法做到实时的持久化，容易数据的丢失。

AOF

可以实时地将内存运行的“进程数据”写入文件，是将Redis执行的写入删除命令以追加的方式记录到AOF文件中。
优势就是支持实时秒级持久化，兼容性好。
缺点：IO压力较大，可能会影响性能，文件体积大，恢复速度慢，影响性能较大。

Redis的性能管理

1. 查看Redis内存使用
redis-cli -h 192.168.6.188 -p 6379
info memory

2. 内存碎片率

操作系统分配的内存值used_memory_rss除以Redis使用的内存值used_memory计算得出
内存碎片是由操作系统低效的分配/回收物理内存导致的（不连续的物理内存分配）
跟踪内存碎片率对理解Redis实例的资源性能是非常重要的：
1）内存碎片率稍大于1是合理的，这个值表示内存碎片率比较低
2）内存碎片率超过1.5，说明Redis消耗了实际需要物理内存的150%，其中50%是内存碎片率。需要在redis-cli工具上输入shutdown save 命令，并重启Redis服务器
3）内存碎片率低于1的，说明Redis内存分配超出了物理内存，操作系统正在进行内存交换。需要增加可用物理内存或减少Redis内存占用.

3. 内存使用率

redis实例的内存使用率超过可用最大内存，操作系统将开始进行内存与swap空间交换
避免内存交换发生的方法：
1）针对缓存数据大小选择安装redis实例
2）尽可能的使用hash数据结构存储
3）设置key的过期时间

4. 内回收key

保证合理分配redis有限的内存资源。
当达到设置的最大阀值时，需选择一种key的回收策略，默认情况下回收策略是禁止删除

配置文件中修改im:axmemory-policy属性值：

vim /etc/redis/6379.conf
#----598取消注释----
maxmemory-policy noenviction

volatile-lru   ：使用LRU算法从已设置过期时间的数据集合中淘汰数据
volatile-ttl   ：从已设置过期时间的数据集合中挑选即将过期的数据淘汰
volatile-random   ：从已设置过期时间的数据集合中随机挑选数据淘汰
allkeys-lru       ：使用LRU算法从所有数据集合中淘汰数据
allkeys-random   ：从数据集合中任意选择数据淘汰
noenviction       ：禁止淘汰数据

取消注释禁止淘汰数据

Nosql之Redis配置与优化及主从复制技术相关推荐

NoSQL之 Redis配置与优化
NoSQL之 Redis配置与优化前言一.缓存概念 (1)系统缓存 ①buffer与cache (2)缓存保存位置及分层结构 ①DNS缓存 ②应用层缓存 ③数据层缓存 ④硬件缓存二.关系数据库和 ...
Linux NoSQL 之 Redis 配置与优化
目录 Linux NoSQL 之 Redis 配置与优化一.缓存缓存概念系统缓存缓存保存位置及分层结构 DNS 缓存应用层缓存数据层缓存 Redis 硬件缓存二.关系数据库和非关系数据库 ...
数据库缓存服务——NoSQL之Redis配置与优化
一.缓存概念缓存是为了调节速度不一致的两个或多个不同的物质的速度,在中间对速度较慢的一方起到加速作用,比如CPU的一级.二级缓存是保存了CPU最近经常访问的数据,内存是保存CPU经常访问硬盘的数据, ...
NoSQL之redis配置与优化（启示录）
目录一:关系型数据库和非关系型数据库概述 1.1关系型数据库 1.2非关系型数据库二:关系型数据库和非关系型数据库的区别 2.1数据存储方式不同 2.2扩展方式不同 2.3对事务性的支持不同 2. ...
NoSQL之Redis配置与优化
目录一.关系数据库与非关系型数据 1.关系型数据库 2.非关系型数据库 3.关系数据库与非关系型数据库区别 (1)数据存储方式不 (2)扩展方式不同 (3)对事务性的支持不同 4.非关系型数据库产生 ...
NoSQL 之 Redis 配置与优化
文章目录一.关系数据库与非关系数据库 1.1 关系型数据库 1.2 非关系型数据库二.关系型数据库和非关系型数据库区别 2.1 数据存储方式不同 2.2 扩展方式不同 2.2.1 负载增加时,有两 ...
NoSQL之Redis配置搭建部署与优化
NoSQL之Redis配置搭建部署与优化 Redis概念 Redis 具有的优点缓存概念系统缓存 buffer与cache: 缓存保存位置及分层结构 DNS缓存应用层缓存数据层缓存硬件缓存 ...
Linux企业化运维--(7)redis服务之redis配置及主从复制、主从自动切换、集群、redis+mysql、gearman实现数据同步
Linux企业化运维实验所用系统为Redhat-rhel7.6. 目录 Linux企业化运维 Linux企业化运维--(7)redis服务之redis配置及主从复制.主从自动切换.集群.redis+ ...
1.NoSQL之Redis配置与基础命令
文章目录前言一.关系数据库与非关系型数据库 1.关系型数据库 2.非关系型数据库 3.关系型数据库和非关系型数据库区别 3.1数据存储方式不同 3.2 扩展方式不同 3.3 对事务性的支持不同 4 ...

Nosql之Redis配置与优化及主从复制技术