Redis03-配置文件+备份+发布订阅+主从复制+缓存问题

Redis03-配置文件+备份+发布订阅+主从复制+缓存问题

1.Redis配置文件

  1. bind 127.0.0.1，配置绑定的ip。bind 127.0.0.1，表示只有本地机器可以访问。如果需要其他的主机访问，可以设置为 bind *。
  2. daemonize no，是否以守护进程的方式运行，默认为no，如果需要后台运行可修改为yes。
  3. pidfile /var/run/redis_6379.pid，如果以后台方式运行，需要设置pid文件。
  4. 日志级别。
# 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 # 日志级别
  1. databases 16，默认16个数据库。
  2. RDB。
# 快照
#	after 900 sec (15 min) if at least 1 key changed
#   after 300 sec (5 min) if at least 10 keys changed
#   after 60 sec if at least 10000 keys changed

save 900 1
save 300 10
save 60 10000

stop-writes-on-bgsave-error yes # 持久化出错Redis是否继续工作
rdbcompression yes # rdb文件是否压缩
rdbchecksum yes # 是否校验rdb文件
dbfilename dump.rdb # rdb文件的命令

dir ./ # rdb文件的路径。
  1. Redis密码设置
requirepass foobared # 默认Redis没有设备密码

config get requirepass # 查看密码，默认为空
1) "requirepass"
2) ""

config set requirepass '123456'  # 设置密码

auth 123456 # 设置密码后通过密码登录
  1. 客户端连接的配置。
maxclients 10000 # 默认支持10000个客户端连接

maxmemory <bytes> # 最大的内存容量
maxmemory-policy noeviction # 打到最大内存时的处理方式

# volatile-lru # 只对设置了过期时间的key进行LRU（默认值）
# allkeys-lru # 删除lru算法的key
# volatile-random # 随机删除即将过期的key
# allkeys-random # 随机删除
# volatile-ttl # 删除即将过期的
# noevication # 永不过期，返回错误
  1. AOF
appendonly no # 默认不开启aof

appendfilename "appendonly.aof" # aof文件的名称

# aof的方式
# appendfsync always # 每次修改都会 sync。
appendfsync everysec # 每秒执行一次 sync
# appendfsync no # 不执行 sync，有操作系统进行 sync

2.RDB

  1. RDB快照时，Redis会创建（fork）一个进程来进行持久化，会先将数据写入到一个临时文件中，等待整个持久化过程都结束了，在用这个临时文件替换上次持久化好的文件。
  2. RDB文件名，dump.rdb；config get dir，查看RDB文件的保存位置。
  3. 将dump.rdb放在config get dir配置的路径，即将dump.rdb文件放在和redis启动脚本redis-server相同 的路径，Redis在启动的时候会启动通过dump.rdb来还原数据。
  4. RDB文件的生成规则。触发save规则；执行flushall命令；‘执行shutdown退出Redis。
  5. RDB的优点：如果进行大规模的数据恢复，并且对数据恢复的完整性不是非常敏感，RDB方式要比AOF更加的高效。
  6. RDB的缺点：如果Redis突然宕机，最后一次RDB后的数据可能丢失。
  7. Redis默认情况下开启RDB配置。

3.AOF

  1. AOF记录所有修改Redis数据的指令，将修改指令追击到appendonly.aof文件中。

  2. Redis默认不开启AOF文件配置，修改Redis配置文件appendonly no为appendonly yes来开启AOF。

  3. Redis启动时会在/usr/local/bin下创建appendonly.aof 文件。

  4. 如果AOF文件被破坏了，Redis会启动失败，可以使用redis-check-aof --fix appendonly.aof来还原AOF文件。

  5. auto-aof-rewrite-min-size 64mb，当AOF文件超过64M的时候，会重写AOF文件。

  6. AOF的优点：每一次修改，都进行数据同步，文件的完整性好；每秒同步一次，只会丢失一秒的数据。

  7. AOF的缺点：相对于数据文件来说，AOF远远大于RDB，所以修复数据的速度慢。

4.RDB和AOF的使用

  1. 在主从复制中，RDB不会放在主机上，而是放在从机，同时保留save 900 1这条规则，一般不会使用AOF。
  2. 同时开启两种持久化方式，当Redis重启的时候会先载入AOF来恢复原始的数据，因为AOF比RDB文件保存的数据要完整。
  3. RDB的数据不实时，同时使用两者，服务器重启也只会找AOF文件，那要不要只使用AOF呢？建议不要，RDB更适合备份数据库，并且可以快速重启。
  4. 如果不使用 AOF，可以靠主从复制来实现高可用性，可以省掉一大笔IO，同时减少rewrite是带来的系统波动。代价是Master/Slave同时宕机，会丢失十几分钟的数据，启动脚本会比较Master和Slave中的RDB文件，使用较新的RDB文件。

5.Redis发布和订阅

subscribe mychannel1 # 订阅频道
publish mychannel1 hello # 发布消息到指定频道
unsubscribe channel # 退订指定频道
PUBSUB CHANNELS # 列出当前订阅的频道
	
	
# Redis发布和订阅实现原理。
# 1 subscribe mychannel，订阅时，会将订阅了mychannel的客户端保存到list中，list的key是mychannel频道名称，value是订阅了该频道的所有客户端所形成的链表。
# 2 publish mychannel message  # 发布消息时就遍历mychannel对应的链表，将消息发送到订阅的客户端中。

6.Redis主从复制

  1. 默认情况下，开启一个Redis服务，这个Redis服务就一个主节点。

  2. info replication，查看当前Redis主从复制的信息。

  3. 搭建Redis主从复制环境，一主两从。

    1. 复制三个配置文件。
    cp redis.conf redis6379.conf
cp redis.conf redis6380.conf
cp redis.conf redis6381.conf
    1. 修改配置文件。
    # 以修改6379为例。
port 6379
pidfile /var/run/redis_6379.pid # pid文件
logfile "6379.log" # 日志文件
dbfilename dump6379.rdb # RDB
    1. redis-server redisconfig/redis6379.conf，启动Redis。
    2. redis-cli -p 6379，连接Redis服务，执行info replication命令，会发现三个Redis都是主机。
    3. 将Redis设置为从节点。临时方法，在客户端执行slaveof 127.0.0.1 6379；永久方法，在Redis配置文件中增加**replicaof 127.0.0.1 6379 **，表示以从机的身份启动。

  4. Redis主从复制模式，主节点可以进行读写操作，从节点只能进行读的操作。

  5. Redis主从复制的原理。从节点成功连接到主节点后会发送一个sync命令；主节点接受到命令后，启动后台存盘进程，收集修改的数据的命令，然后发送给Slave，完成一次完全同步；只有的主节点会增量复制给从节点。即从节点连接到主节点后，先进行一次全量复制，然后再通过增量复制来同步主机上最新的修改操作。

  6. Redis的主从复制模式缺点：主机宕机，从机不会升级为主机，即此时不能对外提供写的操作，可以采用哨兵模式。

  7. Redis的主从复制模式，主机宕机后，又重新启动，启动之后进行的写的操作，依然可以同步到从机。

  8. 一主两从的另一中实现方式。在6380上执行slaveof 127.0.0.1 6379，在6381上执行slaveof 127.0.0.1 6380，线程一个链状结构。

  9. slaveof no one，可以将从节点升级为主节点。

7.Redis哨兵模式

  1. 哨兵模式是一种特殊的模式，哨兵是一个独立的进程，独立运行。其原理是哨兵进程不断的发送命令，等待Redis服务器响应，从而监控运行的多个redis实例。

  2. 同时为了保证高可用，需要多个哨兵，哨兵直接相互监控，即构成Redis集群。

  3. Redis哨兵模式下，假设主节点宕机，哨兵1先检测到，此时并不会将主节点failover下线，仅仅是哨兵1认为主服务器不可用，现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover故障转移操作。 切换完成后，通过发布订阅模式，让各个哨兵把自己监控的从服务器切换为主机，这个过程成为客观下线。

  4. Redis哨兵模式的配置。

    1. vim redisconfig/sentinel.conf，创建哨兵进程启动的配置文件。
    2. sentinel monitor myredis 127.0.0.1 6379 1，配置文件的内容。myredis，自定义的哨兵；127.0.0.1 6379，要监控的主机ip和端口；1，主机宕机，要通过投票来选举可以切换为主节点的从节点。
    3. redis-sentinel redisconfig/sentinel.conf，启动哨兵进程。
    # 哨兵的日志
1760:X 21 Nov 2021 13:58:44.662 # +monitor master myredis 127.0.0.1 6379 quorum 1 # 监控的主节点
1760:X 21 Nov 2021 13:58:44.663 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379 # 检查到的从节点
1760:X 21 Nov 2021 13:58:44.665 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379 # 检查到的从节点

# 主机宕机回来后，会变为从机
1760:X 21 Nov 2021 14:01:41.833 * +convert-to-slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6380

8.Redis缓存

  1. 缓存穿透。
    1. 用户想要查询id=2的商品信息，会先去缓存中查询，缓存中没有，在去数据库中查询，但是数据库中也没有，当大量的请求都去查询id=2的商品的信息时，就会出现缓存穿透的问题。
    2. 解决方法一，使用布隆过滤器在控制层先进行校验，将不符合的规则的查询操作丢弃，从而避免对数据库的查询，减轻了数据库的压力。
    3. 解决方法二，id=2的商品没有，就在缓存中缓存一个空对象，从而避免缓存中没有数据而进行的数据库查询。这用方式带来的问题，空值被缓存，会导致缓存存储更多空的数据，这些没有意义的空数据会占用内容空间。
  2. 缓存击穿。
    1. 热点key在过期的一瞬间有大量的请求过来，这时去请求数据库，造成数据库压力过大。
    2. 解决方法一，设置热点数据永不过期。
    3. 解决方法二，加互斥锁，当热点key在过期的一瞬间有大量的请求过来时，保证对于同一个key只有一个请求可以去数据库进行查询操作。
  3. 缓存雪崩。
    1. Redis宕机，造成数据库压力过大；大量热点key在相同的时间加入缓存，就会在相同的时间过期，从而导致后面的查询会去数据库中查询，造成数据库压力过大。
    2. 解决方式一，数据预热。在高并发访问前，手动触发将热点数据加入到缓存，并且为其设置不同的过期时间。
    3. 解决方法二，加互斥锁，当热点key在过期的一瞬间有大量的请求过来时，保证对于同一个key只有一个请求可以去数据库进行查询操作。
posted @ 2021-11-21 19:56  行稳致远方  阅读(44)  评论(0)    收藏  举报