强的网站建设公外贸网站主机选择

当前位置： 首页 > news >正文

强的网站建设公,外贸网站主机选择,旅游网站开发建设方案,2345网址大全官网前言#xff1a;此篇文章系本人学习过程中记录下来的笔记#xff0c;里面难免会有不少欠缺的地方#xff0c;诚心期待大家多多给予指教。 基础篇#xff1a; Redis#xff08;一#xff09;Redis#xff08;二#xff09;Redis#xff08;三#xff09;Redis#x…  前言此篇文章系本人学习过程中记录下来的笔记里面难免会有不少欠缺的地方诚心期待大家多多给予指教。 基础篇 Redis一Redis二Redis三Redis四Redis五 接上期内容上期完成了Redis主从模式的学习。下面开始学习Redis的哨兵模式(重点)话不多说直接发车。 一、定义 Q既然已经有了主从模式为什么还要推出哨兵模式呢 A在主从模式的架构里当 Master 节点发生宕机故障时从节点并不会自动晋升为新的Master。要是 Master 节点在短时间内无法恢复正常运行系统就会陷入一个棘手的状况。此时系统仅仅保留了读操作的功能却丧失了写操作的能力。这种读写能力的失衡显然无法满足实际业务对系统高可用性和数据完整性的要求。 而哨兵模式正是为了解决上述主从模式的痛点而诞生。它通过一组Sentinel节点来监控主从架构中的Redis实例当主节点出现故障时自动将一个从节点晋升为主节点并让其他从节点重新指向新的主节点从而实现自动故障转移保证系统的高可用性。俗称无人值守运维。 二、功能 主从监控哨兵节点不断地检查主节点和从节点是否正常运行通过定期发送 PING 命令来判断节点的健康状态。消息通知当某个 Redis 实例出现问题时哨兵可以通过 API 向管理员或其他应用程序发送通知以便及时处理。自动故障转移这是哨兵模式的核心功能。当主节点不可用时哨兵会在从节点中选举一个新的主节点并调整其他从节点的配置使其指向新的主节点。配置中心客户端可以通过连接哨兵来获取主节点信息。 三、实操 一、架构说明 3个哨兵1个Master2个Slave。哨兵自动监控和维护集群不存放数据只是吹哨人Master负责存Slave负责读。 由于机器硬件问题同时启动6台虚拟机电脑吃不消所以将哨兵的集群放在6379上。 二、实操步骤 1、拷贝原生配置 拷贝redis压缩目录下的sentinel.conf到/myredis下。 2、修改参数配置 2.1、参数说明 常用参数 bind服务监听地址用于客户端连接默认本机 daemonize是否以后台daemon方式运行 protected-mode安全保护模式 port端口 logfile日志文件路径 pidfilepid文件路径 dir工作目录 sentinel monitor master-name ip redis-port quorum设置要监控的master服务器quorum代表确认客观下线的最少的哨兵数量 sentinel auth-pass master-name password连接Master的密码 其他参数 sentinel down-after-milliseconds master-name milliseconds指定多少毫秒之后主节点没有应答哨兵此时哨兵主观上认为主节点下线 sentinel parallel-syncs master-name nums表示允许并行同步的slave个数当Master挂了后哨兵会选出新的Master此时剩余的slave会向新的master发起同步数据 sentinel failover-timeout master-name milliseconds故障转移的超时时间进行故障转移时如果超过设置的毫秒表示故障转移失败 sentinel notification-script master-name script-path 配置当某一事件发生时所需要执行的脚本 sentinel client-reconfig-script master-name script-path客户端重新配置主节点参数脚本 2.2、修改配置 由于sentinel集群是在6379上所以需要配置3份sentinel.conf文件。 vim 打开sentinel26379.conf 文件删除里面所有内容拷贝下面内容改为自己虚拟机的IP地址 bind 0.0.0.0 daemonize yes protected-mode no port 26379 logfile /myredis/logs/sentinel26379.log pidfile /var/run/redis-sentinel26379.pid dir /myredis sentinel monitor mymaster 192.168.112.129 6379 2 sentinel auth-pass mymaster root 23680、23681也一样但是只要改端口号即可改为自己虚拟机的IP地址 3、测试主从模式 如果不知道主从模式怎么搭建请前往Redis五 启动Master两台slave并查看主从关系。 Master 启动80、81slave 确定主从关系 测试主从是否正常工作 4、配置哨兵集群 在6379那台机器上启动sentinel集群。 哨兵集群已成功启动。 5、模拟故障场景 我们自己手动关闭6379服务器模拟master挂了。 5.1、思考问题 Q1Master主机挂了两台从机是否正常 A从机数据正常。 Q2是否从两台slave中选出新的Master A会。如Q1所示6380和6381在Master宕机后哨兵会进行选举和故障转移导致从机在获取数据时出现Server closed或者broken pipe错误但是会立马恢复了。 此时6380已经成为了new Master6381也变成了6380的slave。 Q3之前的Master恢复后谁会是新的Master双Master会不会冲突 A新Master当然是哨兵选举出来的本次是6380下次不知道是谁不会出现双Master的场景以前的Master重新恢复后会变成new Master的slave。 启动6379查看主从关系 查看Master6380 完美收官。 6、对比配置文件 后续又重新玩了一遍所以新Master由6380变成了6381。 查看sentinel26379.conf文件。 老Master6379.conf new Master 6381.conf 结论文件的内容在运行期间会被sentinel动态进行更改。 当Master宕机后哨兵选举出new Master之后sentinel会对oldMaster_redis.conf、slave_redis.conf、sentinel.conf文件的内容进行更改即oldMaster_redis.conf中会多一行slaveof的配置newMaster_redis.conf中会移除之前的配置而三个sentinel.conf的监控目标也会随之调换。 四、哨兵模式运行流程和选举流程 一、主观下线 所谓主观下线Subjectively Down 简称 SDOWN指的是单个Sentinel实例对服务器做出的下线判断即单个sentinel认为某个服务下线有可能是接收不到订阅或者二者之间的网络不通等等原因。主观下线就是说如果服务器在[sentinel down-after-milliseconds]给定的毫秒数之内没有回应PING命令或者返回一个错误消息 那么这个Sentinel会主观的(单方面的)认为这个master不可以用了。 sentinel.conf文件中 sentinel down-after-milliseconds master-name milliseconds表示Master被当前sentinel实例认定为失效的间隔时间这个配置其实就是进行主观下线的一个依据Master在多长时间内一直没有给sentinel返回有效信息则认定该Master主观下线。也就是说如果多久没联系上redis-servevr认为这个redis-server进入到失效SDOWN状态。 二、客观下线 当一个Sentinel节点将主节点标记为 “主观下线” 后它会通过Sentinel之间的gossip协议流言协议将这个信息传播给其他 Sentinel 节点。当有足够数量quorum的Sentinel节点都认为主节点处于 “主观下线” 状态时这个主节点就会被标记为 “客观下线”Objectively Down。 quorum这个参数是进行客观下线的一个依据 意思是至少有quorum个sentinel认为这个master有故障才会对这个master进行下线以及故障转移。因为有的时候某个sentinel节点可能因为自身网络原因导致无法连接master而此时master并没有出现故障所以这就需要多个sentinel都一致认为该master有问题才可以进行下一步操作这就保证了公平性和高可用。  sentinel.conf文件中 三、选举leader 当主节点被判断客观下线以后各个哨兵节点会进行协商先选举出一个领导者哨兵节点兵王也即被选举出的兵王进行failover故障迁移。 Q领导者哨兵节点如何选举出来的 A监视该主节点的所有哨兵都有可能被选为领导者选举使用的算法是Raft算法Raft算法的基本思路是先到先得即在一轮选举中哨兵A向B发送成为领导者的申请如果B没有同意过其他哨兵则会同意A成为领导者。这里涉及到一个算法问题不做过多阐述有兴趣可以私底下学习。 四、故障转移 故障转移分为三个步骤。可以趣称为“新主登基”、“群臣俯首”、“旧主拜服”。 一、“新主登基” 新主登基指某个slave节点被选为Master。 从slave节点中选出new Master的规则优先级–偏移量–Run ID 1、优先级 redis.conf文件中优先级slave-priority或者replica-priority最高的从节点(数字越小优先级越高 )默认100。 2、偏移量 指复制偏移位置offset最大的从节点通俗一点就是谁从原Master哪儿复制的key多谁就当新的Master。 3、Run ID Run ID是Redis 实例启动时生成的一个随机的 40 位十六进制字符串全局唯一。哨兵会选择 Run ID字典序最小的从节点作为新的主节点 4、选举流程图 二、“群臣俯首” 群臣俯首指当new Master选举出来后剩余的slave节点脱离宕机的Master重新连接的新的Master可以从sentinel.log文件查看)。具体分为二步 1、Sentinel leader会对选举出的new Master执行slaveof no one操作将其提升为Master节点。 2、Sentinel leader向其它slave发送命令让剩余的slave成为新的Master节点的slave。 三、“旧主拜服” 旧主拜服指已经宕机的Master故障恢复重启成功了从新加入。但是身份由以前的Master变成slave。 四、故障转移小总结 上述的failover操作均由sentinel自己独自完成完全无需人工干预。 五、使用注意事项 哨兵节点的数量应为多个哨兵本身应该集群保证高可用。哨兵节点的数量应该是奇数。各个哨兵节点的配置应一致。如果哨兵节点部署在Docker等容器里面尤其要注意端口的正确映射。哨兵集群主从复制并不能保证数据零丢失。 六、总结 Redis哨兵模式通过监控、通知和自动故障转移机制为 Redis集群提供了高可用性保障。合理配置和应用 Redis哨兵模式可以有效地提升系统的稳定性和性能。在实际应用中需要根据具体的业务需求和场景灵活调整配置参数以充分发挥 Redis 哨兵模式的优势。 ps努力到底让持续学习成为贯穿一生的坚守。学习笔记持续更新中。。。。