Redis.config 配置 深度剖析_redis config

 redis 重要的配置

打开  redis目录中 redis.config配置

1. 单位 

 配置文件对 大小写不敏感

2.包含

 好比string improt标签把其他东西导到这里   ,通俗  就是把多个配置文件 配置过来

3.网络

  bind 127.0.0.1     # 本机地址 目前只能本机访问 。如果想远程 可以写一个 " * " 号通配  或指定ip

  protected-mode  yes   # 是否受保护的   一般都是开启的  保证安全性

  port  6379     #  端口号 修改端口可以在这改   比如集群肯定是需要修改的 

4.通用

daemonize  yes   #已守护进程的方式运行, 默认是 no , 需要自己开启为 yes ,否则 一退出 进程就

结束了

# 日志
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)    生产环境
# warning (only very important / critical messages are logged)
loglevel notice

logfile ""   #日志的文件位置名  默认为空不输出

databases 16   #  默认的数据库 数量   16个 

always - show - logo  yes   # 是否显示logo     就是我们启动redis 的logo  

 5.快照  配置rdb

持久化, 在规定时间内 , 执行多少次操作后, 则会持久化到文件 .rdb .aof

redis 是内存数据库 , 不持久化 数据就会丢 , 断电及失 !

save 900 1        #  如果900s内 , 如果 至少有1个key 进行了修改, 就进行持久化操作
save 300 10      #  如果300s内 , 如果 至少有10个key 进行了修改, 就进行持久化操作
save 60 10000  #  如果60s内 , 如果 至少有10000个key 进行了修改, 就进行持久化操作

# 以上是默认配置    我们可以根据自己需求 以及并发量 去设置 

# 如果想使用rde规则可以用#号注释  , rdb aof  都可以单独使用  也可以组合使用

stop-writes-on-bgsave-error yes  # 持久化如果出错 , 是否还需继续工作!

rdbcompression yes   #   是否压缩 rdb  文件, 需要消耗一些cpu 资源 !

rdbchecksum yes      # 保存 rdb 文件的时候 , 进行错误的检查校验!

dir ./   # rdb 文件保存的目录!

6. REPLICATION   主从复制  

7. SECURITY  安全   

 默认是没有密码!

 这个时候我们 登录 就需要 密码了   。更多时候 我们是用命令去设置的!

rdeis 通过命令设置密码:   

1. 查看是否有密码 config get requirepass   

2. 设置密码 config set requirepass "需要设置的密码"  

3. 设置密码后我们直接ping 是ping 不通的 会报: (error)NOAUTH Authentication required. 需要输入密码认证

4. auth 123456   登录认证

8. LIMITS 限制 

maxclients 10000   #  设置能连接上redis最大客户端连接数 默认10000

maxmemory <bytes>  # 设置 redis 的最大内存  默认是字节 

maxmemory-policy noeviction  #内存到达上限之后的处理策略

1. volatile-lru : 只对设置了过期时间的key 进行LRU ( 默认值 )
2. allkeys-lru : 删除lru算法的key
3. volatile-random : 随机删除即将过期的 key
4. allkeys-random : 随机删除
5. volatile-ttl : 删除即将过期的
6. noeviction : 永久不过期, 返回错误

APPEND ONLY MODE   配置aof

appendonly no  # 默认是不开启的, 默认是使用 rdb方式持久化 , 大部分情况下rdb 完全够用!

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

# appendfsync always    #  每次修改都会  sync 。 消耗性能
appendfsync everysec     #  每秒执行一次 sync 。可能会丢失这1s的数据!
# appendfsync no        #不执行 sync 。这个时候操作系统自己同步数据, 速度最快 !

解析 aof  

Redis默认情况是不开启AOF的。重启时再重新执行AOF文件中的命令来恢复数据。它主要解决数据持久化的实时性问题。

AOF是执行完命令后才记录日志的。为什么不先记录日志再执行命令呢？这是因为Redis在向AOF记录日志时，不会先对这些命令进行语法检查，如果先记录日志再执行命令，日志中可能记录了错误的命令，Redis使用日志回复数据时，可能会出错。

正是因为执行完命令后才记录日志，所以不会阻塞当前的写操作。但是会存在两个风险：

1. 更执行完命令还没记录日志时，宕机了会导致数据丢失

2. AOF不会阻塞当前命令，但是可能会阻塞下一个操作。

这两个风险最好的解决方案是折中妙用AOF机制的三种写回策略 appendfsync：

1. always，同步写回，每个子命令执行完，都立即将日志写回磁盘。

2. everysec，每个命令执行完，只是先把日志写到AOF内存缓冲区，每隔一秒同步到磁盘。

3. no：只是先把日志写到AOF内存缓冲区，有操作系统去决定何时写入磁盘。

always同步写回，可以基本保证数据不丢失，no策略则性能高但是数据可能会丢失，一般可以考虑折中选择everysec。

RDB 和AOF 如何选择?

• 如果数据不能丢失，RDB和AOF混用

• 如果只作为缓存使用，可以承受几分钟的数据丢失的话，可以只使用RDB。

• 如果只使用AOF，优先使用everysec的写回策略。

RDB 的优劣势

优势:

　　1.RDB是一个非常紧凑(compact)的文件，它保存了redis 在某个时间点上的数据集，这种文件非常适合用于进行备份和灾难恢复。

　　2.生成RDB文件的时候，redis主进程会fork()一个子进程来处理所有保存工作，主进程不需要进行任何磁盘IO操作。

　　3.RDB 在恢复大数据集时的速度比AOF的恢复速度要快。

劣势:

1、RDB方式数据没办法做到实时持久化/秒级持久化。因为bgsave每次运行都要执行fork操作创建子进程，频繁执行成本过高

2、在一定间隔时间做一次备份，所以如果redis意外down掉的话，就会丢失最后一次快照之后的所有修改（数据有丢失）。

AOF 的优劣势

优点：

1、AOF 持久化的方法提供了多种的同步频率，即使使用默认的同步频率每秒同步一次，Redis 最多也就丢失 1 秒的数据而已。

缺点：

1、对于具有相同数据的的Redis，AOF 文件通常会比 RDB 文件体积更大（RDB存的是数据快照）。

2、虽然 AOF 提供了多种同步的频率，默认情况下，每秒同步一次的频率也具有较高的性能。在高并发的情况下，RDB 比 AOF 具好更好的性能保证。