redis学习——目录

其余更多java基础文章：
java基础学习(目录)

---

这一系列主要是针对慕课网的redis实战写的一个复盘文章，对视频内容进行一次整理和输出。在整理输出找资料的过程当中，发现了一个也是慕课网系列的整理文章，以为还挺不错的。

高可用Redis(一)：通用命令，数据结构和内部编码，单线程架构
高可用Redis(二)：字符串类型
高可用Redis(三)：Hash类型
高可用Redis(四)：列表，集合与有序集合
高可用Redis(五)：瑞士军刀之慢查询，Pipeline和发布订阅
高可用Redis(六)：瑞士军刀之bitmap，HyperLoglog和GEO
高可用Redis(七)：Redis持久化
高可用Redis(八)：Redis主从复制
高可用Redis(九)：Redis Sentinel
高可用Redis(十)：Redis原生命令搭建集群
高可用Redis(十一)：使用redis-trib.rb工具搭建集群
高可用Redis(十二)：Redis Cluster
高可用Redis(十三)：Redis缓存的使用和设计

总结

RBD

RDB持久化功能能够将Redis中全部数据生成快照并以二进行文件的形式保存到硬盘里，文件名为.RDB文件。

在Redis启动时载入RDB文件，Redis读取RDB文件内容，还原服务器原有的数据库数据

RBD的三种方式

1. 使用SAVE命令手动同步建立RDB文件

客户端向Redis服务端发送SAVE命令，服务端把当前全部的数据同步保存为一个RDB文件 经过向服务器发送SAVE命令，Redis会建立一个新的RDB文件。在执行SAVE命令的过程当中(也就是即时建立RDB文件的过程当中),Redis服务端将被阻塞，没法处理客户端发送的其余命令请求。

2. 使用BGSAVE命令异步建立RDB文件

BGSAVE不会形成redis服务器阻塞：在执行BGSAVE命令的过程当中，Redis服务端仍然能够正常的处理其余的命令请求。Redis服务端经过fork()来生成一个名叫redis-rdb-bgsave的进程，由redis-rdb-bgsave子进程来建立RDB文件，而Redis主进程则继续处理客户端的命令请求。

BGSAVE是一个异步命令，Redis客户端向Redis服务端发送BGSAVE命令后会当即获得回复，而实际的操做在Redis服务端回复以后才开始

3. 自动建立RDB文件

打开Redis的配置文件/etc/redis.conf

save 900 1
save 300 10
save 60 10000
复制代码

自动持久化配置解释：

save 900 1表示：若是距离上一次建立RDB文件已通过去的900秒时间内，Redis中的数据发生了1次改动，则自动执行BGSAVE命令
save 300 10表示：若是距离上一次建立RDB文件已通过去的300秒时间内，Redis中的数据发生了10次改动，则自动执行BGSAVE命令
save 60 10000表示：若是距离上一次建立RDB文件已通过去了60秒时间内，Redis中的数据发生了10000次改动，则自动执行BGSAVE命令
复制代码

当三个条件中的任意一个条件被知足时，Redis就会自动执行BGSAVE命令

RDB现存问题

1. 耗时耗性能

Redis把内存中的数据dump到硬盘中生成RDB文件，首先要把全部的数据都进行持久化，所须要的时间复杂度为O(N)，同时把数据dump到文件中，也须要消耗CPU资源， 因为BGSAVE命令有一个fork子进程的过程，虽然不是完整的内存拷贝，而是基于copy-on-write的策略，可是若是Redis中的数据很是多，占用的内存页也会很是大，fork子进程时消耗的内存资源也会不少 磁盘IO性能的消耗，生成RDB文件原本就是把内存中的数据保存到硬盘当中，若是生成的RDB文件很是大，保存到硬盘的过程当中消耗很是多的硬盘IO

2. 不可控，丢失数据

自动建立RDB文件的过程当中，在上一次建立RDB文件之后，又向Redis中写入多条数据，若是此时Redis服务中止，则从上一次建立RDB文件到Redis服务挂机这个时间段内的数据就丢失了

AOF(AppendOnlyFile)方式

AOF持久化保存数据库的方法是：每当有修改的数据库的命令被执行时，服务器就会将执行的命令写入到AOF文件的末尾。

由于AOF文件里面储存了服务器执行过的全部数据库修改的命令，因此Redis只要从新执行一遍AOF文件里面保存的命令，就能够达到还原数据库的目的

AOF三种策略

为了控制Redis服务器在遇到意外停机时丢失的数据量，Redis为AOF持久化提供了appendfsync选项，这个选项的值能够是always,everysec或者no

• Always

Redis每写入一个命令，always会把每条命令都刷新到硬盘的缓冲区当中而后将缓冲区里的数据写入到硬盘里。 这种模式下，Redis即便用遭遇意外停机，也不会丢失任何本身已经成功执行的数据

• Everysec

Redis每一秒调用一次fdatasync,将缓冲区里的命令写入到硬盘里， 这种模式下，当Redis的数据交换不少的时候能够保护硬盘 即便Redis遭遇意外停机时，最多只丢失一秒钟内的执行的数据

• No

服务器不主动调用fdatasync,由操做系统决定任何将缓冲区里面的命令写入到硬盘里，这种模式下，服务器遭遇意外停机时，丢失的命令的数量是不肯定的

AOF三种方式比较

运行速度：always的速度慢，everysec和no都很快

• always不丢失数据，可是硬盘IO开销不少，通常的SATA硬盘一秒种只能写入几百次数据
• everysec每秒同步一次数据，若是Redis发生故障，可能会丢失1秒钟的数据
• no则系统控制，不可控，不知道会丢失多少数据

AOF重写功能简介

随着服务器的不断运行，为了记录Redis中数据的变化，Redis会将愈来愈多的命令写入到AOF文件中，使得AOF文件的体积来断增大。 为了让AOF文件的大小控制在合理的范围，redis提供了AOF重写功能，经过这个功能，服务器能够产生一个新的AOF文件。

新的AOF文件记录的数据库数据和原有AOF文件记录的数据库数据彻底同样
新的AOF文件会使用尽量少的命令来记录数据库数据，所以新的AOF文件的体积一般会比原有AOF文件的体积要小得多
AOF重写期间，服务器不会被阻塞，能够正常处理客户端发送的命令请求

经过配置选项自动执行BGREWRITEAOF命令

• auto-aof-rewrite-min-size

触发AOF重写所需的最小体积：只要在AOF文件的大小超过设定的size时，Redis会进行AOF重写，这个选项用于避免对体积太小的AOF文件进行重写

• auto-aof-rewrite-percentage

指定触发重写所需的AOF文件体积百分比：当AOF文件的体积大于auto-aof-rewrite-min-size指定的体积，而且超过上一次重写以后的AOF文件体积的percent%时，就会触发AOF重写，若是服务器刚启动不久，尚未进行过AOF重写，那么使用服务器启动时载入的AOF文件的体积来做为基准值。
将这个值设置为0表示关闭自动AOF重写功能

只有当上面两个条件同时知足时才会触发Redis的AOF重写功能