美文网首页
Redis高级操作

Redis高级操作

作者: 攻城老狮 | 来源:发表于2020-12-22 09:23 被阅读0次

    持久化AOF

    1. Redis默认会将持久化的数据保存在 /usr/local/bin 目录下的 dump.rdb 文件内，可以通过以下命令查看
    127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"
    1. rdb触发机制
    • save规则满足的情况下，会自动触发rdb持久化
    • 执行flushall命令，触发rdb持久化
    • 退出redis，会触发rdb持久化
    1. 恢复rdb

    只要将rdb文件放在redis的启动目录下，redis就可以自动检测并恢复数据

    1. 优缺点
    • 优点：
      • 适合大规模数据恢复
      • 对数据完整性要求不高
    • 缺点：
      • 需要一定的时间间隔操作，若redis意外宕机，最后一次修改可能无法得到保存
      • fork进程会占用一定的内存空间

    持久化AOF

    1. 以日志的形式记录写操作，将Redis执行过的指令记录(读指令不记录)，只会追加文件但不可以改写文件。Redis启动后会根据日志内容将写指令从头至尾的执行一遍以完成数据的恢复。
    2. AOF默认关闭，需要手动开启
    3. aof文件操作说明
    • 配置文件中将aof打开
    appendonly yes
    • 重启server服务器使配置文件生效，在其中放入一些值
    127.0.0.1:6379> set name yorick
OK
127.0.0.1:6379> set age 23
OK
127.0.0.1:6379> set address beijing
OK
127.0.0.1:6379> shutdown
not connected> exit
    • 关闭server服务后，会在目录下生成 appendonly.aof文件，该文件以日志的形式保存了写指令的相关操作
    [root@yqj bin]# ls
appendonly.aof  myconfig         redis-check-aof  redis-cli       redis-server
dump.rdb        redis-benchmark  redis-check-rdb  redis-sentinel
    • 删除 dump.rdb 防止实验测试对数据干扰，打开 appendonly.aof 文件，恶意修改文件。会发现无法再次重启redis服务。
    • 此时需要执行redis对aof的检验修复操作
    redis-check-aof --fix appendonly.aof
    • 再次重启server服务，发现可以正常获取其他未受干扰的数据
    127.0.0.1:6379> keys *
1) "age"
2) "name"
    1. 优缺点
    • 优点：
      • 每一次修改都同步，数据完整性好
      • 每一秒都同步，只会丢失1秒数据
      • 从不同步，效率最高
    • 缺点：
      • aof文件大小比rdb远远要大，修复速度也慢
      • aof运行效率比rdb也慢，故默认使用rdb

    发布订阅

    1. 发布/订阅模型：发布者，接收者，频道
    2. Redis发布订阅的操作说明
    • 开启一个客户端用于订阅频道
    127.0.0.1:6379> subscribe weichat # 订阅频道 weichat
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "weichat"
3) (integer) 1
    • 开启另外一个客户端将消息发布到频道
    127.0.0.1:6379> publish weichat "hello world" # 向频道发布消息
(integer) 1
    • 查看客户端方的接收情况
    1) "message" # 消息
2) "weichat" # 频道
3) "hello world" # 消息内容

    主从复制

    1. 主从复制用于读写分离，80%情况下都在进行读操作，可以减轻服务器的压力。
    2. 默认情况下，每台Redis服务器均是主节点。一个主节点可以有多个从节点，而一个从节点只能有一个主节点。
    3. 主从复制的作用
      • 数据冗余
      • 故障修复
      • 负载均衡
      • 高可用（集群）
    4. 集群搭建（只需配置从库，不用配置主库）
    • 查看信息
    127.0.0.1:6379> info replication
# Replication
role:master # 默认为主库
connected_slaves:0 # 目前没有从机
master_replid:c9924dae7b83755d68ac28f0c11826628396b926
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
    • 修改3个配置文件，实现一主机二从机的架构
    1.修改端口 port 6380
2.修改pid名字 pidfile /var/run/redis_6380.pid
3.修改log文件名字 logfile "6380.log"
4.修改dump.rdb名字 dbfilename dump6380.rdb
5.修改为守护进程 daemonize yes
    • 在客户端手动配置一主机二从机的架构

    6380从机配置

    127.0.0.1:6380> slaveof 127.0.0.1 6379 # 将6380设为6379的从机
OK
127.0.0.1:6380> info replication
# Replication
role:slave # 从机角色
master_host:127.0.0.1 # 主机host
master_port:6379 # 主机 port
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:0
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fd0e64a5a450ee131f523ff903158e6921c075d6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0

    6381从机配置

    127.0.0.1:6381> slaveof 127.0.0.1 6379 # 将6381设为6379的从机
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:98
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fd0e64a5a450ee131f523ff903158e6921c075d6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:98
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:85
repl_backlog_histlen:14

    6379主机信息

    127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2 # 有2个从机
slave0:ip=127.0.0.1,port=6380,state=online,offset=182,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=182,lag=0
master_replid:fd0e64a5a450ee131f523ff903158e6921c075d6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:182
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:182
    • 测试正常主从交互，其中主机负责写操作，从机负责读操作
    127.0.0.1:6379> set name yorick
OK

    127.0.0.1:6380> get name
"yorick"

    127.0.0.1:6381> get name
"yorick"
    • 测试主机宕机的情况

    主机宕机后从机的状态信息

    127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down # 主机宕机
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:548
master_link_down_since_seconds:9
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fd0e64a5a450ee131f523ff903158e6921c075d6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:548
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:548

    主机重新上线

    1.从机的状态变为up状态
2.可以正常接收主机的写信息
3.从机会在主机上线后，做全量复制。当主机此时的rdb做了清空操作，则导致从机也会同步到清空的rdb
    • 从机宕机

    主机此时会剔除掉从机节点

    27.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=394,lag=0
master_replid:62a549d678800656506801c644cf8d1745d13b33
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:394
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:394

    从机重新上线，若是之前在命令中手动配置的话，会又变为master节点，需要再次手动配置为6379的从机节点。之后会从主机节点进行全量复制的操作，同步数据信息。

    • 测试三个节点形成串行架构，A -- B -- C ，其中 A为主机，B C为从机。此时，若主机A宕机，将B手动配置为主机的情形。

    A节点信息

    127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1038,lag=0
master_replid:62a549d678800656506801c644cf8d1745d13b33
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1038
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1038

    B节点信息

    127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:996
slave_priority:100
slave_read_only:1
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=996,lag=0
master_replid:62a549d678800656506801c644cf8d1745d13b33
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:996
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:677
repl_backlog_histlen:320

    C节点信息

    127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:996
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:62a549d678800656506801c644cf8d1745d13b33
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:996
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:996

    A节点宕机，让B节点变为主节点

    127.0.0.1:6380> slaveof no one
OK
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=1248,lag=1
master_replid:790fe401bebe59340a2d205afbfb1979a04dab8d
master_replid2:62a549d678800656506801c644cf8d1745d13b33
master_repl_offset:1248
second_repl_offset:1235
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:677
repl_backlog_histlen:572

    此时，C从机会根据B节点的数据变化而同步数据

    哨兵模式

    利用哨兵模式实现对一主机二从机的架构进行监控，有宕机发生时可以实现自动选举新的主机节点

    1. 编写哨兵的配置文件 sentinel.conf
    # sentinel monitor 自定义名称 host port 票数 
sentinel monitor myredis 127.0.0.1 6379 1
    1. 启动哨兵，监控
    redis-sentinel myconfig/sentinel.conf
    1. 测试使主节点宕机

    哨兵监控到主节点宕机，选举6381为主节点

    17063:X 18 Dec 2020 08:45:54.116 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6381
17063:X 18 Dec 2020 08:45:54.116 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
17063:X 18 Dec 2020 08:46:24.170 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381

    此时若恢复原来的节点，则会将该节点变为新主节点的从节点

    127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:18536
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:adf8c515dc36f5834f3a1f4b49076e62a4046de6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:18536
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:14470
repl_backlog_histlen:4067
    1. 哨兵模式的优缺点
    • 优点：
      • 哨兵集群基于主从复制模式，所有的主从配置优点，哨兵全部继承
      • 主从可以实现切换，故障转移，系统的可用性提升
      • 哨兵模式是主从模式的升级，手动到自动更健壮
    • 缺点：
      • Redis不易进行在线扩容，集群容量达到上线后扩容较为麻烦
      • 实现哨兵模式的配置较为复杂

    参考地址：https://www.bilibili.com/video/BV1S54y1R7SB

    相关文章

      网友评论

          本文标题：Redis高级操作

          本文链接：https://www.haomeiwen.com/subject/pmhxnktx.html

          延伸阅读

          深度阅读

          • 您也可以注册成为美文阅读网的作者，发表您的原创作品、分享您的心情！

          栏目导航

          热点阅读

          关于我们|服务条款|联系我们|Redis高级操作|投稿指南|网站地图|RSS订阅|排版工具|手机版

          提供经典美文摘抄,优美散文欣赏,现代诗歌精选,短篇小说,心情随笔,表白情书范文,故事会在线阅读欣赏

          Copyright © 2014-2023 Haomeiwen.com All Rights Reserved. 好美文阅读网 版权所有

          备案信息：桂公网安备 45052102000051号 · 桂ICP备13007215号-3

          本站所收录作品、热点评论等信息部分来源互联网，目的只是为了系统归纳学习和传递资讯

          所有作品版权归原创作者所有，与本站立场无关，如不慎侵犯了你的权益，请联系我们告知，我们将做删除处理！