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使用日志回复数据时，可能会出错。
正是因为执行完命令后才记录日志，所以不会阻塞当前的写操作。但是会存在两个风险：
更执行完命令还没记录日志时，宕机了会导致数据丢失
AOF不会阻塞当前命令，但是可能会阻塞下一个操作。
这两个风险最好的解决方案是折中妙用AOF机制的三种写回策略 appendfsync：
always，同步写回，每个子命令执行完，都立即将日志写回磁盘。
everysec，每个命令执行完，只是先把日志写到AOF内存缓冲区，每隔一秒同步到磁盘。
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 具好更好的性能保证。
