redis.conf
我们安装成功之后就会有这个配置文件，但是我们一般都不推荐直接使用出厂的配置文件，而是单独拷贝一份使用，以避免我们因为配置错误而带来不必要的麻烦。
如图我单独拷贝了一份在根目录下面的文件夹：
redis单元：
Tcp-backlog：
设置tcp的backlog，backlog其实是一个连接队列，backlog队列总和=未完成三次握手队列+已经完成三次握手队列。
在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值，所以需要确认增大somaxconn和tcp_max_syn_backlog两个值来达到想要的效果。
timeout：
Tcp-keepalive：
单位为秒，如果设置成0，则不会进行keepalive检测，建议设置成60
redis日志级别：
分为四种：debug，verbose，notice，warning。从上到下日志级别越来越高。
debug通常用于开发/测试，提供的非常详细
在通过测试之后生产上线的时候通常使用notice或warning
redis密码的查看，设置与取消：
我们可以看到在配置文件中，这些全部被默认注释掉了。
那我们查看，修改密码则需要连接redis服务器进行设置：
如上图：一开始可以ping通，然后我们查看requirepass发现是空字符串，然后我们设置requirepass为“123456”，再去ping就发现ping不通了，这是因为只要我们一设置安全验证，它就立刻生效，在我们输入任何命令前都需要通过验证，即键入auth 123456来通过验证。
limit限制：
Maxclients 最大客户连接数
Maxmemory 最大缓存
Maxmemory-policy 最大缓存过期策略：
共分为六种：
（1）volatile-lru：使用LRU算法移除key，只对设置了过期时间的键
（2）allkeys-lru：使用LRU算法移除key
（3）volatile-random：在过期集合中移除随机的key，只对设置了过期时间的键
（4）allkeys-random：移除随机的key
（5）volatile-ttl：移除哪些TTL值最小的key，即那些最近要过期的key
（6）noeviction：不进行移除。针对写操作，只是返回错误信息 * 一般只在学习中设置它，实际生产中在1~5里面选一种
Maxmemory-samples ：设置样本数量，LRU算法和最小TTL算法都并非是精确的算法，而是估算值，所以你可以设置样本的大小，redis默认会检查这么多个key并选择其中LRU的那个
redis RDB持久化
什么是redis持久化？用两个关键词来概括，就是RDB和AOF
RDB：Redis DataBase
AOF：Append Only File
那么RDB具体有什么用？
答：在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的Snapshot快照，它恢复时是将快照文件直接读到内存里
redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。
如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
Fork：Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等）数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
RDB保存的是dump.rdb文件
我们为了方便解释，先把这个dump.rdb删掉，然后开两个窗口
然后我们备份一份dump.rdb文件并命名为dump_back.rdb文件：
之后我们在redis中进行清库操作，然后关闭连接：
那么此时，我们的dump.rdb文件应该记录的是什么？
我们重新进入redis查看：
可以看到 ，我们之前新增的12个key已经没有了，这是因为我们在执行flushall指令的时候它会立即生成一个新的dump.rdb文件并把原来的覆盖掉，
不过这时候我们之前备份的dump_back.rdb文件就可以派上用场了：
我们先把这次的dump.rdb文件删掉，然后把之前的备份文件复制一份并命名为dump.rdb:
然后我们再进入redis查看，就可以看到之前 新增的12个key了：
RDB是整个内存压缩过的Snapshot，RDB的数据结构，可以配置复合的快照触发条件。
如果想禁用RDB持久化的策略，只要不设置任何save指令，或者给save传入一个空字符串参数就可以了。
如果我们传入的参数很重要，要求它立即备份，也可以再redis中键入save来完成手动备份
stop-writes-on-bgsave-error yes
这一行说的是当后台保存数据时错误，那么禁止继续写入数据，当然如果配置成no，表示你不在乎数据不一致或者有其他的收端发现和控制。
rdbcompression ：对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbchecksum：在存储快照后，还可以让rdis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
总结一下：
如何触发RDB快照：
1、配置文件中默认的快照配置-冷拷贝后重新使用 可以cp dump.rdb dump_back.rdb
2、执行save命令或bgsave：
save：save时只管保存，其他不管，一律阻塞
bgsave：redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
3、执行flushall命令，也会产生dump.rdb文件，单里面是空的，无意义
如何恢复：
将备份文件（dump.rbd)移动到redis的启动目录（你在哪个目录下启动的redis，哪个目录就是你的启动目录）下并启动服务即可
config get dir 获取目录
rdb的优势：
1、适合大规模的数据恢复
2、对数据的完整性和一致性要求不高
rdb的劣势：
1、在一定时间间隔做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照后的所有修改
2、Fork的时候，内存中的数据被克隆了一份，大致2倍的膨胀性需要考虑
如何停止：
动态所有停止RDB保存规则的方法：redis-cli config set save “”
redis AOF持久化：
AOF是什么：以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作
我们为了方便解释，先复制一个redis.conf 并命名为redis_aof.conf，然后把所有的rdb文件全部删掉：
然后把redis_aof.conf里的appendonly 那一项改为yes（默认是no）
然后我们在左边的窗口启动redis_aof.conf：
然后我们会发现我们的目录里多出来一个appendonly.aof文件：
我们在redis中新增四个key：
然后我们可以在appendonly.aof文件中可以看到它原模原样记录了我们的写动作（甚至我们在哪个库都记录下来了）：
然后我们执行flushall指令：
我们会发现appendonly.aof文件中也把flushall这个指令记录下来了：
可以看到现在我们的库里面是空的：
然后我们把appendonly.aof文件里面的那行flushall删掉（实际生产中不允许直接修改appendonly.aof文件）：
然后我们重新启动redis：
可以看到，我们的数据又恢复了。
第二个问题，如果dump.rdb和appendonly.aof文件共存，那么启动的是谁？
我们执行一个shutdown命令，它会自动生成一个dump.rdb文件：
然后我们给appendonly.aof文件搞破坏：
我们键入一大堆无用字符，并保存：
那么现在这个文件相当于被损坏掉了。
那么我们再启动redis的时候，如果能够正常启动，说明它找的是dump.rdb文件，如果不能正常启动，那说明它找的是aof文件：
如上图，我们可以看到进程并没有被正常启动，说明它是先识别aof文件的，那么我们把aof文件删掉，只保留rdb文件，他就应该能正常启动了，我们来试一下：
果然可以正常启动，这也再次证明redis启动的时候识别的是aof文件。
那如果不删除aof，怎么修复呢？
我们要用到src目录下的redis-check-aof文件：
我们把它复制一份到我的安装目录下，然后执行如下操作：
然后我们就可以正常启动redis了：
2020 02 05：
Appendfsync：
Always：同步持久化 每次发生数据变更会立即记录到磁盘 性能较差但数据完整性比较好
Everysec：出厂默认推荐，异步操作，每秒记录，如果一秒内宕机，有数据丢失
NO
rewrite：
是什么：AOF采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令bgrewriteaof
重写原理：AOF文件秩序增长而过大时，会fork出一条新进程来将文件重写（也是险些历史文件最后再rename），遍历新进程的内存中数据，每条记录有一条的Set语句。重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件，这点和快照有点相似。
触发机制：redis会记录上次重写时的aof大小，默认配置是当aof文件大小时上次rewrite后大小的一倍且文件大于64M时触发
No-appendfsync-on-rewrite：重写时是否可以运用Appendfsync，用默认no即可，保证数据安全性。
Auto-aof-rewrite-min-size：设置重写的基准值
Auto-aof-rewrite-percentage：设置重写的基准值
总结一下：
AOF的优势：
每秒同步：appenndfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
每修改同步：appnedfsync everysec 异步操作，每秒记录 如果一秒内宕机，有数据丢失
不同步：appendfsync no 从不同步
劣势：
相同数据集的数据而言aof文件要远大于rdb文件，恢复速度慢于rdb
aof运行效率要慢于rdb，每秒同步策略效率较好，不同步效率和rdb相同
以上就是redis的两种持久化方式，那么我们选择哪一种比较好？
RDB持久化方式能够在指定的时间间隔对你的数据进行快照存储
AOF持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来赴会原始的数据，AOF命令以redis协议追加保存每次写的操作到文件末尾。redis还能对AOF文件进行后台重写，使得AOF文件的体积不至于过大
只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。
同时开启两种持久化方式：
在这种情况下，当redis重启的时候会优先加载AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据集要比RDB文件保存的数据集要完整。
RDB的数据不实时，同时使用两者时服务器重启也只会找AOF文件。那要不要只使用AOF呢？作者建议不要，因为RDB更适合用于备份数据库（AOF在不断变化不好备份），快速重启而且不会有AOf可能潜在的bug，留着作为一个万一的手段。
性能建议：
因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，只保留save 900 1 这条规则。
如果Enable AOF，好处是在最恶劣的情况下也只丢失不超过两秒的数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite 的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrtie的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%时重写也可以改到适当的数值。
如果不Enable AOF，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价就是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的哪个。新浪微博就选用了这种架构。
