redis及持久化

redis非关系型数据库，缓存型数据库

关系型数据库和非关系型数据库的区别：

关系型数据库是一个机构化的数据库，行和列。

列声明对象

行，记录对象的属性。

表与表之间是有关联的。使用sql语句，来对指定的表，库，进行增删改查。

在创建表时，我们是设计好了表的结构。按照表结构来存储数据。数据如果与表结构不匹配那么存储数据会失败。

非关系型数据库：nosql not only sql

不需要定义库，也不需要定义表结构，直接记录即可，而且每条记录都可以有不同的数据类型，字段（字段个数）

redis key:vlaues 键值对形式存储，每个键之间没有直接关联，库与库之间互相独立。

区别：

1、数据的存储方式不同。

2、扩展方式，性能上的提升。关系型数据库靠的是提升本机性能。非关系型数据库，可以横向扩展，加入节点服务器的方式来提高性能

3、对事务的支持性，mysql支持事务。

原子性

隔离性

一致性

持久性

非关系型数据库也支持事务，redis也可以支持事务，但是稳定性和处理能力都不如关系型数据库

非关系型数据库的主要场景：

1、操作的扩展性

2、海量数据处理

web2.0交互

纯动态网站的三高问题

1、对数据库高并发读写的需求

2、对海量数据高效存储与访问的需求

3、对数据库的高可用扩展性与高可用性的需求

数据库缓存：

web页面缓存：

cpu和磁盘之间缓存

常见的缓存需求场景

关系型数据库：

库-----表------行，列----->存储数据

非关系数据库：

库-----集合----->键值对

他不需要手动的创建库中间件和集合

redis：开源的，使用c语言编写的NQL数据库

redis:基于内存运行，支持持久化（数据恢复）。采用的就是key-value(键值对)的存储形式，目前在分布式架构中，非常重要的一环

redis服务器程序，是一个单进程模式，即只有一个主进程工作。也就是说在一台服务器上可以启动多个redis （端口号不能冲突）

redis的实际处理速度是完全依靠主进程的执行效率。

服务器只部署了一个redis进程，多个客户端访问，可能会导致redis的处理能力下降

如果部署了多个redis进程，虽然提高了redis的并发处理能力，但是会给服务器的cpu带来很大压力

一般情况下

一台服务器，部署三个redis进程 （根据情况来看，高并发，要部署多个。一般的情况，单进程足够）

redis的特点：

1、具有极高的读写速度，数据读取每秒110000次，写入数据每秒可执行81000的写入

2、支持丰富的数据类型

3、支持持久化。平常的数据都是保存在内存中，持久化可以写入到磁盘中，既可以保存到本地，也可以实现备份。

4、原子性，所有的操作都是原子性

5、支持主从模式—master-slave

面试：redis为什么这么快

1、redis是纯内存结构，避免磁盘I/O的耗时

2、核心模块是一个单进程，减少了线程切换和回收线程资源的时间

3、I/O的多路复用机制。每一个执行线路都可以同时执行读和写，高并发的效率大大提高。

特殊说明：redis的读写仍然是单进程的处理。

redis的服务控制命令：

/etc/init.d/redis_6379 stop start restart status

redis的命令工具：
redis-server:直接启动redis,只能启动

redis-benchmark:检测redis在本机的运行效率

redis-cli:命令行工具

redis-check-aof:检测AOF文件是否正常

redis-check-rdb:检测rdb文件是否正常

redis-benchmark:
-h 指定服务器的主机名IP地址

-p 指定服务器的端口号

-c 指定并发连接数

redis的数据类型：

1、如何进入redis

redis-cli直接使用，仅限于本地，远程登录还是需要指定目标服务器的IP地址

redis-cli -h 192.168.211.11 -p 6379

-h 指定IP地址

-p 指定端口号

-a 指定登录密码

redis数据类型 五大数据类型

1、string (字符串)：也是redis最基本的类型，最大能存储512MB的数据，可以存储任何数据，数字，文字，图片，等等都可以

2、list数据类型

列表当中的元素还是string类型

3、hash类型

hash类型用于存储对象，采用hash的格式来进行操作。占用的磁盘空间少，而且一个hash可以存储4294967295个键值对

4、set数据类型（无序集合）元素类型也是string，元素是唯一的。 不允许重复，多个集合类型可以进行并集，交集和差集运算。

set当中的元素类型是唯一的，可以跟踪一些唯一性的数据。访问微博的用户名，只要把对应名称写进redis，set会自动保存唯一性，方便下一次的访问

5、有序集合：有序集合，元素类型也是string.元素唯一，不能重复。 zset

每个元素都会关联一个double（小数点）的分数（score,表示权重），可以通过权重的大小，进行排序。元素的权重可以相同

在线积分的排行榜，可以实时更新用户的分数 可以使用zrange命令获取积分top10的用户。zrank命令通过用户的名称username来获取用户的排行信息。

192.168.211.11:6379> ZCOUNT myzset 1 2
(integer) 2

表示权重的范围

set和hset创建普通类型和hash类型该怎么选

一般情况下，如无特殊需求，普通创建方式即可

对一个键进行多字段存储，节省内存，使用hash方式。

redis的库，库都是创建好的库，16个库

数字排名：0-15 每个数据库之间互相独立互不干扰

redis的特点：读写速度快。

数据类型：

1、string

2、list

3、hash 对一个键进行多段操作要用hash 节省内存空间

4、无序集合 set 元素不能重复 可以用来定义唯一值

5、有序集合 zset 元素不能重复 但是权重可以相同

192.168.211.11:6379> ttl test1
(integer) -1
负一表示永不过期 
负二表示已过期 


192.168.211.11:6379> expire test 30 
(integer) 1
对已创建的进行生命期修改 30s 

redis的数据类型的增删改查

redis的高可用

在集群当中有一个非常重要的指标，提供正常服务的时间的百分比（365天）99.9%

redis的高可用含义更加宽泛，正常服务是指标之一，数据容量的扩展，数据的安全性。

在redis中实现高可用技术：持久化，主从复制，哨兵模式，cluster集群

持久化：持久化是最简单的高可用方法，主要作用就是数据备份，也就是把redis缓存在内存中的数据保存到本地的硬盘中（冷备份）

---

redis持久化的两种方式

1、RDB持久化：redis在内存中的数据定时保存到磁盘（自动执行，手动执行）

2、AOF持久化：redis的操作日志，以追加的方式写入一个AOF的文件，类似于mysql的binlog

rdb的持久化：指在指定时间间隔内，将内存中当前进程中的数据生成快照保存到硬盘（快照持久化），用二进制压缩存储

保存的文件名的后缀.rdb. redis启动时，可以直接读取快照文件，实现数据恢复

rdb的触发机制：

手动机制:save bgsave 都可以生成RDB文件

save创建RDB文件时，整个redis进程都会被堵塞，期间redis将无法进行读写操作，直到RDB文件创建完成为止

BGSAVE：主进程会通过fork机制创建一个子进程，子进程的创建过程中，主进程会阻塞，子进程创建完毕，主进程解除阻塞

子进程来创建RDB文件。创建完成之后通知主进程更新通知信息

save 900 1

900秒 当时间到900秒时，redis的数据至少发生了一次变化就会执行bgsave

save 300 10

300秒 当时间300秒时，redis的数据至少发生了10次变化就会执行bgsave

save 60 10000

60秒 当时间60秒时，redis的数据至少发生了10000次变化就会执行bgsave

rdbcompression no

开启RDB文件的压缩功能，在高并发场景建议关闭。

除了配置文件中的save m n 之外

主从复制，从节点执行全量复制操作，主节点会执行bgsave 把RDB文件传送给从节点

关闭主进程，shutdown之后，会自动执行RDB的持久化。

启动时加载：如果启动时加载发现rdb文件损坏，日志中会打印错误，redis会拒绝启动。

redis-check-rdb 修复RDB的持久化文件。

---

AOF持久化

aof持久化是将redis的每一次读 写 删除命令记录到一个单独的.aof为结尾的文件。查询操作由主进程记录。

当redis重启时，再次执行AOF文件中的命令来恢复数据

AOF的实时性更好，也是主流的持久化方案。

配置文件中

appendonly yes 设置为yes打开

用于判断AOF文件，如果被截断时的行为。

yes:发现被截断（写入过程中出现异常，导致文件未能完全写入）redis会尽可能的恢复文件中的数据，redis会继续运行

no:发现AOF文件被截断，redis将拒绝启动

对数据完整性的要求高，no

如果注重数据服务器的可用性，yes

rdb是redis的默认持久化文件，但是一旦开启AOF持久化，那么redis会以AOF的持久化文件作为最高优先级

AOF的重写功能

1、随着时间增长，AOF文件当中的数据也会不断的增加。AOF的文件也会越来越大。过大的AOF文件不仅仅会影响服务器的正常运行，也会导致数据恢复时间过长。

文件重写是指定期的重写AOF文件，减小AOF文件的体积。AOF重写是把redis进程内的数据，转化为写的命令，同步到新的AOF文件当中（不会额外的生成一个新的文件，只是在原内容中进行压缩）。不会对原有的AOF文件进行任何读，写的操作

*文件重写虽然是AOF持久化强烈推荐的，但不是必须的。没有重写并不影响redis启动时读取数据。在实际中，会关闭自动的文件重写。通过定时任务来完成。

AOF同步的文件策略的三种方式

appendfsync always：写入过程中，立刻调用redis系统的fsync操作写入到AOF文件，每次写入都执行同步，硬盘的性能有瓶颈。硬盘的寿命也会大大降低

appendfsync everysec：命令写入，调用redis操作，write操作结束后，线程会返回。FSYNC同步文件操作由专门的线程，每秒调用一次。这是一个折中的策略，是性能和安全性的平衡，是redis的默认配置，也是推荐配置。

appendfsync no：写入操作会调用系统的write操作，但是不对AOF文件进行同步，操作系统来同步，同步周期30秒，文件同步的时间不可控，缓冲区会堆积大量数据，数据的安全也无法保证。

重写的触发条件是什么？

1、手动触发

redis-cli bgrewriteaof

2、自动触发

auto-aof-rewrite-percentage 100

文件的大小超过基准的百分比，默认值就是100.文件的大小超过两倍时，执行这个bgrewriteaof 设置为0，禁用自动触发

100M 200M 400M

auto-aof-rewrite-min-size 64mb

文件大于基准值，才会进行重写。这个值是AOF文件执行重写的最小值。避免开始启动redis后，文件太小，然后频繁的进行重写

redis-cli bgrewriteaof

AOF重写为什么能够压缩文件：

1、重写的过程中，过期的数据不会写入文件

2、无效的命令不再写入文件，数据被重复设置 set test=1 set test=2 ,删除的数据也不会写入 set test1 del test

3、多条命令合并成一个，sadd test1 v1 sadd test1 v2 sadd test1 v3 合并为sadd test v1 v2 v3

重写之后，AOF的文件当中的命令减少了，空间也少了，恢复速度也会增加（重写不是必须）

---

RDB和AOF之间的优缺点：

RDB的优点：文件体积小，网络传输速度很快，适合全量复制。恢复速度也比AOF要快

缺点：没有办法做到一个实时的持久化，数据如此重要，不能够容忍丢失的，另外RDB需要满足特定的格式，兼容性很差。

老版本的RDB不支持新版本。（redis的版本一定要一致）5.0.7

AOF的优点：秒级的持久化。兼容性好。文本格式保存的命令 命令是通用的

缺点：文件较大，占用的空间比较多 恢复速度慢 AOF持久化需要频繁的向磁盘写入数据，磁盘的I/O压力大。对redis主进程的性能也会有一定的影响

redis的持久化也可以算作是高可用的一种，通过备份文件来恢复数据，是一种冷备份。

rdb：save在线上是不用的。bgsave：

AOF ：实时持久化 写入的操作命令，除了查set del 会记录 get select 不计入。实时记录，恢复方式类似于mysql的bin-log

重写：推荐，但是不是必须的，重写也是主进程创建一个子进程，由子进程来创建AOF文件 在过程中产生的数据以及同步策略都是写入到AOF文件当中