其他更多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重写功能
