广州网站备案要审核多久,pc端软件界面设计,美工常用找素材网站,网站每天做多少外链合适前言 在生产环境中#xff0c;除了采用持久化方式实现 Redis 的高可用性#xff0c;还可以采用主从复制、哨兵模式和 Cluster 集群的方法确保数据的持久性和可靠性。 目录 一、主从复制 1. 概述 2. 作用 3. 主从复制流程 4. 部署 4.1 安装 redis 4.2 编辑 master 节…前言 在生产环境中除了采用持久化方式实现 Redis 的高可用性还可以采用主从复制、哨兵模式和 Cluster 集群的方法确保数据的持久性和可靠性。 目录 一、主从复制 1. 概述 2. 作用 3. 主从复制流程 4. 部署 4.1 安装 redis 4.2 编辑 master 节点配置文件 4.3 编辑 slave 节点配置文件 4.4 验证主从效果 二、哨兵模式 1. 概述 2. 结构 2. 功能与原理 3. 作用 4. 故障转移机制 5. 主节点选举的过程  6. 搭建 redis 哨兵模式  6.1 所有节点修改哨兵模式配置文件 6.2 启动哨兵模式 6.3 查看哨兵信息 6.4 查看日志并模拟 master 故障 6.5 再次查看哨兵信息 一、主从复制 1. 概述 主从复制是高可用 Redis 的基础将一台 Redis 服务器的数据复制到其它的 Redis 服务器。前者 为主 master后者为 slave单向从主到从主可以有多个从从只能有一个主。 2. 作用 ① 数据冗余主从复制实现了数据的热备份是持久化之外的一种数据冗余方式 ② 故障恢复当主节点出现问题时可以由从节点提供服务实现快速的故障恢复实际上是一种服务的冗余 ③ 负载均衡在主从复制的基础上配合读写分离可以由主节点提供写服务由从节点提供读服务即写Redis数据时应用连接主节点读Redis数据时应用连接从节点分担服务器负载尤其是在写少读多的场景下通过多个从节点分担读负载可以大大提高Redis服务器的并发量 ④ 高可用基石除了上述作用以外主从复制还是哨兵和集群能够实施的基础因此说主从复制是Redis高可用的基础 3. 主从复制流程 ① 启动一个 slave 机器进程从 redis 会向主发送 sync 同步数据请求 ② 主 redis 会 fork 一个子进程会产生 rdb 文件完全备份文件的过程 ③ rdb 文件的持久化完成后主 redis 会将 rdb 文件和缓存起来的命令推送给从服务器 ④ 复制、推送完后后主 redis 会持续的同步操作命令利用 aof增备持久化功能 ⑤ 在下一台 redis 接入主从复制之前会持续利用 aof 的方式同步数据给从服务器 4. 部署 环境准备关闭防火墙与核心防护 master节点 192.168.190.100slave1节点 192.168.190.101slave2节点 192.168.190.102 4.1 安装 redis yum install -y gcc gcc-c make cd /opt/ wget http://download.redis.io/releases/redis-5.0.7.tar.gz tar zxvf redis-5.0.7.tar.gz cd redis-5.0.7/ make -j 2 make prefix/usr/local/redis install cd /opt/redis-5.0.7/utils ./install_server.sh ...... Please select the redis executable path [/usr/local/bin/redis-server] /usr/local/redis/bin/redis-server ln -s /usr/local/redis/bin/* /usr/local/bin/4.2 编辑 master 节点配置文件 [rootmaster ~]# vim /etc/redis/6379.conf70 bind 0.0.0.0 # 修改监听地址为0.0.0.0137 daemonize yes # 开启守护进程172 logfile /var/log/redis_6379.log # 指定日志文件目录264 dir /var/lib/redis/6379 # 指定工作目录700 appendonly yes # 开启AOF持久化功能 [rootmaster ~]# /etc/init.d/redis_6379 restart 选择配置 systemd 管理服务 [rootmaster ~]# vim /usr/lib/systemd/system/redis.service [Unit] # 包含了关于服务单元的描述信息 DescriptionRedis Server # 描述服务 Afternetwork.target # 指定了服务应该在网络服务启动后启动[Service] # 包含了关于服务如何运行的配置信息 PIDFile/var/run/redis_6379.pid # 方便使用pid号进行操作 ExecStart/usr/local/redis/bin/redis-server /etc/redis/6379.conf # 指定了启动Redis服务时要执行的命令 ExecStop/usr/local/redis/bin/redis-cli shutdown # 指定了停止Redis服务时要执行的命令这里是使用redis-cli发送shutdown命令 Restartalways # 指定了服务在意外终止时应该自动重新启动[Install] # 定义了如何安装这个服务 WantedBymulti-user.target # 安装字符界面指定了在多用户模式下启用这个服务 [rootmaster ~]# systemctl daemon-reload [rootlocalhost ~]# systemctl start redis.service [rootlocalhost ~]# systemctl status redis.service ● redis.service - Redis ServerLoaded: loaded (/usr/lib/systemd/system/redis.service; disabled; vendor preset: disabled)Active: active (running) since 三 2024-04-03 17:56:18 CST; 6s agoMain PID: 5473 (redis-server)4.3 编辑 slave 节点配置文件 [rootslave1 ~]# vim /etc/redis/6379.conf70 bind 0.0.0.0 # 修改监听地址为0.0.0.0137 daemonize yes # 开启守护进程172 logfile /var/log/redis_6379.log # 指定日志文件目录264 dir /var/lib/redis/6379 # 指定工作目录288 replicaof 192.168.190.100 6379 # 指定要同步的Master节点IP和端口700 appendonly yes # 开启AOF持久化功能 [rootslave1 ~]# scp -p /etc/redis/6379.conf root192.168.190.102:/etc/redis/ /etc/init.d/redis_6379 restart # 两台从服务器均重启redis服务 4.4 验证主从效果 ① 在 master 节点上验证从节点 [rootmaster ~]# redis-cli info replication # Replication role:master connected_slaves:2 slave0:ip192.168.190.101,port6379,stateonline,offset98,lag0 slave1:ip192.168.190.102,port6379,stateonline,offset98,lag1 [rootmaster ~]# tail -f /var/log/redis_6379.log② 在 master 数据库存放数据 [rootmaster ~]# redis-cli 127.0.0.1:6379 set a 1 OK 127.0.0.1:6379 get a 1③ 在 slave 数据库获取数据 [rootslave1 ~]# redis-cli 127.0.0.1:6379 get a 1[rootslave2 ~]# redis-cli 127.0.0.1:6379 get a 1 # 至此实现主从复制 二、哨兵模式 1. 概述 主从切换需要人工干预为了解决主从复制的缺点在主从复制的基础上哨兵引入了主节点的自动故障转移。 2. 结构 哨兵节点哨兵系统由一个或多个哨兵节点组成哨兵节点是特殊的 redis 节点不存储数据 数据节点主节点和从节点都是数据节点 2. 功能与原理 哨兵sentinel是一个分布式系统用于对主从结构中的每台服务器进行监控当出现故障时通过投票机制选择新的 Master并将所有slave连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。 3. 作用 监控哨兵会不断地检查主节点和从节点是否运作正常哨兵间也会监测 自动故障转移当主节点不能正常工作时哨兵会开始自动故障转移操作它会将其中一个从节点升级为新的主节点并让其它从节点改为复制新的主节点 通知提醒哨兵可以将故障转移的结果发送给客户端 4. 故障转移机制 ① 由哨兵节点定期监控发现主节点是否出现了故障每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次 ping 命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息那么这个哨兵就会认为这个主节点主观下线了单方面的。当超过半数哨兵节点认为该主节点主观下线了这样就客观下线了。 ② 当主节点出现故障此时哨兵节点会通过 Raft 算法选举算法实现选举机制共同选举出一个哨兵节点为 leader来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。 ③ 由 leader 哨兵节点执行故障转移过程如下 将某一个从节点升级为新的主节点让其它从节点指向新的主节点若原主节点恢复也变成从节点并指向新的主节点通知客户端主节点已经更换 注意客观下线是主节点才有的概念如果从节点和哨兵节点发生故障被哨兵主观下线后不会再有后续的客观下线和故障转移操作。  5. 主节点选举的过程  监控对象 哨兵对主从复制集群进行监控所有redis数据节点 哨兵与哨兵之间进行相互监控哨兵彼此 监控目的 哨兵监控所有的 redis 数据库的目的为了实现故障自动故障切哨兵与哨兵之间的监控目的检测彼此的存活状态 故障切换过程 ① 当master 挂掉哨兵会及时发现之后 进行投票机制选发现举出一个新的master服务器一定是基数 ② 完成 salve 到 master 的切换 ③ 完成其他的从服务器对新的 master 配置 6. 搭建 redis 哨兵模式  6.1 所有节点修改哨兵模式配置文件 vim /opt/redis-5.0.7/sentinel.conf17 protected-mode no # 关闭保护模式21 port 26379 # Redis哨兵默认的监听端口26 daemonize yes # 指定sentinel为后台启动36 logfile /var/log/sentinel.log # 指定日志存放路径65 dir /var/lib/redis/6379 # 指定数据库存放路径84 sentinel monitor mymaster 192.168.190.100 6379 2 # 修改master ip # 指定该哨兵节点监控192.168.190.100:6379这个主节点该主节点的名称是mymaster最后的2的含义与主节点的故障判定有关至少需要2个哨兵节点同意才能判定主节点故障并进行故障转移 113 sentinel down-after-milliseconds mymaster 30000 # 判定服务器down掉的时间周期默认30000毫秒30秒 146 sentinel failover-timeout mymaster 180000 # 故障节点的最大超时时间为180000180秒 6.2 启动哨兵模式 注意先启 master再启 slave [rootmaster ~]# cd /opt/redis-5.0.7/ [rootmaster redis-5.0.7]# redis-sentinel sentinel.conf [1] 6728[rootslave1 ~]# cd /opt/redis-5.0.7/ [rootslave1 redis-5.0.7]# redis-sentinel sentinel.conf [1] 41954[rootslave2 ~]# cd /opt/redis-5.0.7/ [rootslave2 redis-5.0.7]# redis-sentinel sentinel.conf [1] 8273 6.3 查看哨兵信息 [rootslave2 ~]# redis-cli -p 26379 info Sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:namemymaster,statusok,address192.168.190.100:6379,slaves2,sentinels3 # 名为 mymaster 的主节点的详细信息。它显示该主节点的状态正常statusok地址为 192.168.190.100:6379有 2 个从节点slaves和 3 个 Sentinel。 6.4 查看日志并模拟 master 故障 [rootmaster ~]# systemctl stop redis.service [rootslave2 ~]# tail -f /var/log/sentinel.log 8261:X 03 Apr 2024 19:47:03.639 # config-update-from sentinel f6084d790599b7c806cde643fcf083df6f782182 192.168.190.101 26379 mymaster 192.168.190.100 6379 # 表示一个 Sentinel 实例收到了来自另一个 Sentinel 实例的配置更新 8261:X 03 Apr 2024 19:47:03.639 # switch-master mymaster 192.168.190.100 6379 192.168.190.102 6379 # 名为 mymaster 的主节点从地址 192.168.190.100:6379 切换到了新地址 192.168.190.102:6379。这通常代表着故障转移failover的发生即主节点切换到了另一个地址上 8261:X 03 Apr 2024 19:47:03.640 * slave slave 192.168.190.101:6379 192.168.190.101 6379 mymaster 192.168.190.102 6379 8261:X 03 Apr 2024 19:47:03.640 * slave slave 192.168.190.100:6379 192.168.190.100 6379 mymaster 192.168.190.102 6379 # 表示两个从节点已经成功地重新连接到新的主节点地址 192.168.190.102:6379。 8261:X 03 Apr 2024 19:47:33.715 # sdown slave 192.168.190.100:6379 192.168.190.100 6379 mymaster 192.168.190.102 63796.5 再次查看哨兵信息 [rootmaster ~]# redis-cli -p 26379 info Sentinel # Sentinel sentinel_masters:1 sentinel_tilt:0 sentinel_running_scripts:0 sentinel_scripts_queue_length:0 sentinel_simulate_failure_flags:0 master0:namemymaster,statusok,address192.168.190.102:6379,slaves2,sentinels3