Redis配置文件

配置文件

Redis单位

网站：https://blog.csdn.net/suprezheng/article/details/90679790

对大小写不敏感

INCLUDES 包含

就好比我们学习spring时配置文件可以使用import加入别的配置文件

NETWORK 网络

# 指定 redis 只接收来自于该IP地址的请求，如果不进行设置，那么将处理所有请求
bind 127.0.0.1

# 是否开启保护模式，默认开启。要是配置里没有指定bind和密码。开启该参数后，redis只会本地进行访问，拒绝外部访问。要是开启了密码和bind，可以开启。否则最好关闭，设置为no
protected-mode yes

# redis监听的端口号
port 6379

GENERAL 通用

# 是否在后台执行（守护进程），yes：后台运行；no：不是后台运行，默认是no
daemonize yes


# redis的进程文件，如果以后台的方式运行，我们就需要指定一个 pid 文件
pidfile /var/run/redis/redis.pid

# 日志级别
# debug (很多信息，方便开发和测试)
# verbose (许多有用的信息，但是不像debug级别那么混乱)
# notice (适当的日志级别，适合生产环境，默认级别)
# warning (只有非常关键重要的信息)
loglevel notice

# 指定了记录日志的文件。空字符串的话，日志会打印到标准输出设备。后台运行的redis标准输出是/dev/null
logfile ""

# 默认数据库的数量
databases 16

# 是否总是显示log
always-show-logo yes

SNAPSHOTTING 快照

持久化，在规定的时间内，执行了多少次操作，则会持久化到 .rdb .aof 文件，Redis是内存数据库，如果没有持久化，它的数据是断电即失的

# RDB核心规则配置 save <指定时间间隔> <执行指定次数更新操作>，满足条件就将内存中的数据同步到硬盘；官方默认是下面三个配：在900s后有一个key发生变化，就进行持久化操作，或者在300s后有10个key发生变化、60s后有10000个key发生变化就进行持久化操作；若不想用RDB方案，可以把 save "" 的注释打开，下面三个注释
#   save ""
save 900 1
save 300 10
save 60 10000

# 当RDB持久化出现错误后，是否停止工作，yes：停止，no：不停止，可以通过info中的rdb_last_bgsave_status了解RDB持久化是否有错误
stop-writes-on-bgsave-error yes

# 配置存储至本地数据库时是否压缩数据，默认为yes。Redis采用LZF压缩方式，但占用了一点CPU的时间。若关闭该选项，会导致数据库文件变的巨大。建议开启
rdbcompression yes

# 是否校验rdb文件;从rdb格式的第五个版本开始，在rdb文件的末尾会带上CRC64的校验和。这跟有利于文件的容错性，但是在保存rdb文件的时候，会有大概10%的性能损耗，所以如果你追求高性能，可以关闭该配置
rdbchecksum yes

# 指定本地数据库文件名，一般采用默认的 dump.rdb
dbfilename dump.rdb

# 数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
dir ./

REPLICATION 复制

################################# REPLICATION #################################
 
# 复制选项，slave复制对应的master，配置主机的ip和port，这样这个服务器启动就是从机
# replicaof <masterip> <masterport>    
 
#如果master设置了requirepass，那么slave要连上master，需要有master的密码才行。masterauth就是用来配置master的密码，这样可以在连上master后进行认证。
# masterauth <master-password>

SECURITY 安全

# 可以在这里设置密码，默认是没有密码的
# requirepass foobared
# 也可以通过命令来设置
127.0.0.1:6379> config set requirepass 12345
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "12345"

CLIENTS 客户端

# 设置能连上redis的最大客户端连接数量。默认是10000个客户端连接。由于redis不区分连接是客户端连接还是内部打开文件或者和slave连接等，所以maxclients最小建议设置到32。如果超过了maxclients，redis会给新的连接发送’max number of clients reached’，并关闭连接
# maxclients 10000

MEMORY MANAGEMENT 内存配置

# redis配置的最大内存容量。当内存满了，需要配合maxmemory-policy策略进行处理。注意slave的输出缓冲区是不计算在maxmemory内的。所以为了防止主机内存使用完，建议设置的maxmemory需要更小一些
maxmemory <bytes>		# Redis最大内存容量

#内存容量超过maxmemory后的处理策略。
#volatile-lru：利用LRU算法移除设置过过期时间的key。
#volatile-random：随机移除设置过过期时间的key。
#volatile-ttl：移除即将过期的key，根据最近过期时间来删除（辅以TTL）
#allkeys-lru：利用LRU算法移除任何key。
#allkeys-random：随机移除任何key。
#noeviction：不移除任何key，只是返回一个写错误。
maxmemory-policy noeviction

APPEND ONLY MODE appendonly模式（aof）

# 默认不开启aof模式，默认是使用rdb方式持久化的
appendonly no

# 持久化的文件名
appendfilename "appendonly.aof"


#aof持久化策略的配置
#no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快
#always表示每次写入都执行fsync，以保证数据同步到磁盘
#everysec表示每秒执行一次fsync，可能会导致丢失这1s数据
# appendfsync always
appendfsync everysec
# appendfsync no

#aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程
auto-aof-rewrite-percentage 100
 
#设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写
auto-aof-rewrite-min-size 64mb

持久化

Redis是内存数据库，如果没有持久化操作，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化操作

RDB（Redis DataBase）

是指用数据集快照的方式半持久化模式记录 redis 数据库的所有键值对,在某个时间点将数据写入一个临时文件，持久化结束后，用这个临时文件替换上次持久化的文件，达到数据恢复

工作方式

Redis会单独创建（fork）一个子程序来进行持久化，子程序用来完成io操作，让主进程继续处理命令

优点

• 只有一个文件 dump.rdb，方便持久化
• 容灾性好，一个文件可以保存到安全的磁盘
• 性能最大化，fork 子进程来完成写操作，让主进程继续处理命令，所以是 IO最大化。使用单独子进程来进行持久化，主进程不会进行任何 IO 操作，保证了 redis的高性能)
• 相对于数据集大时，比 AOF 的启动效率更高

缺点

• 数据安全性低。RDB 是间隔一段时间进行持久化，如果持久化之间 redis 发生故障，会发生数据丢失。所以这种方式更适合数据要求不严谨的时候)

触发规则

• 配置文件里 save的条件满足会生成 rdb文件

• 直接使用 save 命令

  • 使用save命令会立刻对当前内存中的数据进行持久化 ,但是会阻塞，也就是不接受其他操作了

• 退出Redis（shutdown）也会生成 rdb文件

• 执行flushall命令也会生成rdb文件

• Redis启动时也会自动生成

查看所在位置

127.0.0.1:6379> CONFIG get dir
1) "dir"
2) "/opt/redis-6.0.6"

AOF（Append-only file）

是指所有的命令行记录以 redis 命令请求协议的格式完全持久化存储保存为 aof 文件

以日志的形式记录每个写操作，将Redis执行过的所有指令记录下来（读操作不记录），只许追加文件但不可以更改文件，Redis启动之初会读取该文件重新构建数据

配置文件：appendonly.aof

默认是不开启的，需要进行手动配置

测试

将appendonly no 改为 appendonly yes 启动

在启动Redis时就会多一个 appendonly.aof文件，它里面记录了我们所有的操作

但是如果这个文件被破坏了（我们这里人为的给它命令随便改点乱码），我们重启Redis时就会报错

我们可以使用redis-check-aof工具来修复（在src文件夹下），直接把错误的命令干掉

# --fix 关联需要修复的文件
[root@iZ2zeghyi5idbl1rlnkp5tZ redis-6.0.6]# src/redis-check-aof --fix appendonly.aof 
0x              30: Expected \r\n, got: 7364
AOF analyzed: size=74, ok_up_to=23, diff=51
This will shrink the AOF from 74 bytes, with 51 bytes, to 23 bytes
Continue? [y/N]: y
Successfully truncated AOF

优点

• 数据安全，aof 持久化可以配置 appendfsync 属性，有 always，每进行一次命令操作就记录到 aof 文件中一次。
• 通过 append 模式写文件，即使中途服务器宕机，可以通过 redis-check-aof工具解决数据一致性问题。
• AOF 机制的 rewrite 模式。AOF 文件没被 rewrite 之前（文件过大时会对命令进行合并重写），可以删除其中的某些命令（比如误操作的 flushall）)

缺点

• AOF 文件比 RDB 文件大，且恢复速度慢
• 数据集大的时候，比rdp启动效率低

扩展

同时开启两种持久化方式

• 在这种情况下，当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 rewrite 的频率，AOF重写的基础大小默认64M太小了，可以设到5G以上，默认超过原大小100%大小重写可以改到适当的数值
• 如果不Enable AOF，仅靠 Master-Slave Replication 实现高可用性也可以，能省掉一大笔IO，也减少了rewrite时带来的系统波动。代价是如果Master/Slave 同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个 Master/Slave 中的 RDB文件，载入较新的那个，微博就是这种架构