Redis学习笔记（2）

一、配置文件（部分）

1. UNITS（单位）

数据单位

2. INCLUDES（包含）

可以包含其他配置文件，而redis.conf作为总的配置文件

3. NETWORK（网络配置）

-网络端口的绑定

-tcp-backlog 在高并发的环境下需要高的backlog值来避免慢客户端连接问题

-tcp-keepalive 连接存活的检查，即心跳机制，默认300s

4. GENERAL（通用配置）

-loglevel 日志水平；默认notice

5. SNAPSHOTTING（快照）

与RDB持久化有关

6. APPEND ONLY MODE

与AOF持久化有关

7.REPLICATION （复制）

与备份有关

8. SECURITY（安全）

主要是密钥相关

9. CLIENTS（客户端）

设置最大连接的客户数

10. MEMORY MANAGEMENT（内存管理）

- 设置最大的内存容量；

- 缓存过期策略：当内存满了，需要配合maxmemory-policy策略进行处理，可以通过一些策略移除一些数据；默认设置不移除。

 #设置最大的内存容量

  # maxmemory <bytes>

  # MAXMEMORY POLICY

  # 内存容量超过maxmemory后的处理策略。

  # lru 最近最少使用算法

  #volatile-lru：在设置过期时间的key中使用lru算法进行数据的移除

  #volatile-random：在设置过期时间的key中随机移除

  #volatile-ttl：在设置过期时间的key中，根据ttl移除最快过期的key

 #allkeys-lru：利用LRU算法移除任何key。

 #allkeys-random：随机移除任何key。

 #noeviction：不移除任何key，只是返回一个写错误;正常的生成环境中不可采用。

 #上面的这些移除策略，如果没有合适的key可以移除，对于写命令会返回错误；这种情况下，redis将不再接收写请求，只接收get请求。

 # lru检测的样本数,

 # maxmemory-samples 

 # 是否开启salve的最大内存，默认yes

 # replica-ignore-maxmemory yes

11. LAZY FREEING（惰性释放）

非阻塞的方式释放内存

12. REDIS CLUSTER（集群）

redis集群的配置

二、数据持久化

指的是将内存中的数据写入到磁盘中，以实现持久化存储；当要恢复数据时，加载相应的文件以恢复内存数据。

有两种持久化方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

1. RDB

含义：指定时间间隔内将内存中的数据（即快照）写入到磁盘中，恢复时只需要将快照直接读到内存上，以实现数据的加载；是Redis默认的持久化方式。

触发方式：手动触发和自动触发。

- 手动触发：通过save指令和bgsave指令可以手动触发；其中save是阻塞型的，bgsave是非阻塞型的，异步的，redis会fork一个子进程进行持久化，客户端仍然可以进行IO操作。

- 自动触发：通过配置文件，自动触发，在conf文件的SNAPSHOTTING部分设置，格式为 save [seconds] [changes] 参数代表在多少时间内数据进行了多少次变动，则会触发持久化。默认的触发配置：save 900 1 和 save 300 10 和 save 60 10000

保存的文件：dump.rdb 可以设置保存目录，默认会保存到工作目录下

自动触发的save:

Redis会单独创建（fork）一个子进程来进行持久化，会先将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。

整个过程中，主进程是不进行任何IO操作的，这就确保了极高的性能。

优缺点：

适合于大规模数据的恢复，且对于数据恢复的完整性不是非常敏感；rdb方式要比AOF方式更加的高效，数据恢复性能要远高于aof；
rdb的缺点是最后一次持久化后的数据可能丢失；持久化时会fork一个子进程，属于重量级操作，导致内存消耗过大。

其他设置：

rdbcompression 压缩，LZF

rdbchecksum 用CRC64算法进行数据校验，默认开；会消耗10%的cpu性能。

注意：如果Flushall会自动触发生成空的dump.rdb文件，就无法通过dump.rdb恢复原有的数据。shutdown也会触发持久化，生成rdb文件。

2. AOF

含义：以独立日志的方式记录每次写命令，重启时再从前到后重新执行aof文件中的命令达到恢复数据的目的；默认不开启。

保存的文件：appendonly.aof

AOF的持久化类型（appendfsync）：

always：每条写指令出现后即进行记录；性能较差。

everysec：每秒进行记录，是异步的持久化；默认采用。

no：不进行持久化。

AOF的修复：如果AOF的记录出现错误，可以用指令：redis-check-aof --fix进行修复。同理对rdb。

重写机制：

当aof文件超过某一个阈值，Redis就启动重写机制对文件进行压缩，只保留可以恢复数据的最小指令集。通过重写，可以时aof文件变小，降低了文件占用空间且更快地被Redis加载。阈值可以在conf文件中进行设置，即auto-aof-rewrite-percentage和auto-aof-rewrite-min-size。也可以手动触发，通过bgrewriteaof指令。

重写原理：

Redis会fork一个子进程进行重写过程；AOF重写并不需要原有AOF文件，而是通过读取服务器当前的数据库状态来实现的，过期的数据不予考虑。通过遍历所有数据库的所有的键，采用set、rpush等指令生成最小指令集的aof文件，并替换掉原有的aof文件，从而实现重写。

优缺点：

对比RDB方式，AOF更加实时，对数据的完整性支持更好，在最恶劣的情况下只会丢失不超过2s的数据；在两种方式同时存在的情况下，redis优先采用AOF进行恢复。

AOF文件要远大于RDB文件，且AOF的运行效率比RDB低，恢复速度比RDB慢。

3. 使用

- 因为RDB文件只用作后备用途，建议只在Slave上持久化RDB文件，而且只要15分钟备份一次就够了，即只保留save 900 1这条规则。

- 如果Enalbe AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO，二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可，应该尽量减少AOF rewrite的频率，AOF重写的基础大小默认值64M太小了，可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。

- 如果不Enable AOF ，仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个。