Redis Sentinel故障转移测试：奇数与偶数哨兵实例的对比分析

Redis哨兵模式（故障转移测试）

Sentinel模式是在主备模式的基础上，增加Sentinel来实现Redis集群的故障转移。
Sentinel负责监控集群状态，当Redis主节点出现故障时，通过Sentinel选举选出替代主节点。
选举通常需要奇数代表，并且多数人达成共识。
问：如果Sentinel集群中部分实例宕机，出现偶数个Sentinel，或者只剩下一个Sentinel，是否还能进行故障转移？为什么会出现这个问题：Sentinel实际上是一个Redis实例，一般来说，Sentinel是为了保证Redis集群的故障转移。
出于资源和网络通信性能的考虑，Sentinel和Redis通常部署在同一台物理机上。
如果物理机出现故障，Sentinel实例和Redis服务实例将同时关闭。
本文进行了一个实验来解决这个问题。
使用3+3模式，3Redis+3Sentinel。
三个虚拟机，每个虚拟机运行1个redis+1个sentinel，角色规划192.168.237.101：master、sentinel192.168.237.100：slave、sentinel192.168.237.103：slavenue、sentinel安装redis、redisentinelapt-getinstallredis-serverapt-getinstallredis-sentinelredis-server配置修改（/etc/redis/redis.conf）redis-serverslave配置修改启动redis-server/etc/init.d/redis-serverrestartredis-server主从集群查看状态修改sentinel配置（/etc/redis/sentinel.conf）Sentinelmonitormymaster192.168.237.10163792Sentinelknown-slavemymaster192.168.237.1006379protected-modenontinel从/etc/init.d/redis-sentinelstart启动检查redis-sentinel状态期望：故障转移，sentinel选举新的master并关闭redis-server(192.168.237.101)检查sentinel日志(/var/log/redis/redis-sentinel.log)可以看到，+odownmaster，Sentinel检测到master客观下线，然后投票：vote-forleader选择新的master：switch-mastermymaster192.168.237.1016379192.168.237.1036379192.168.237.101Sentinel日志：检查Redis和Sentinel集群状态，确认master已变为192.168.237.103（masterhost）并且恢复192.168。
237.101redis-server，查看日志，192.168.237.101已更改为slave：有两个sentinel，可能会出现剩下的两个slave根据sentinel原理获得投票，会等待一段时间重新选举的时间.只要没有从站拥有两票，故障转移就完成了。
实验3.1后，master已改为192.168.237.103。
现停止103上的哨兵和redis-server。
检查两个sentinel的redis-sentinel日志。
可以选择master进行故障转移：检查redis集群状态并确认master（192.168.237.100）预期：无法依次关闭2个sentinel和1个redis-servermaster。
在3.2节中，master被移至100。
环境恢复后，103和100上的sentinel依次关闭，100上的redis-servermaster查看101上的sentinel日志。
因为只有一名哨兵。
Sentinel在101上投票恢复了redis-sentinel。
目前使用两个redis-sentinel，选择101作为master，查看sentinel日志。
两个或多个Sentinel可以执行故障转移。
一个奇怪的哨兵可以更轻松地选择用于故障转移的主服务器。
+sdown：主观宕机+odown：客观宕机+new-era：集群增量版本号+vote-for-leader：投票选出Sentinel集群中的一个sentinel作为本次failover操作的leader+尝试do-failover：为某个投票的IP启动故障转移：另一个哨兵投票+elected-leader：在哨兵集群中重新确认哪个哨兵是该领导者这将进行故障转移。
+selected-slave：选择leader+failure-state-send-slave-noone-slave-leader：向目标slave发送“slaveof-noone”命令，告诉它不再是除该节点之外的任何其他节点的slave成为。
完成从奴隶到主人的转变。
+failover-state-wait-promotedslave：等待其他sentinels确认slave+promoted-slave：所有其他sentinels成功确认+failover-state-recover-slave.cluster+slave-reconf-在启动reconf操作中发送所有slave（更新配置信息）for：指定跟随的新master+switch-master向从站发送“slaveoff”命令：故障转移完成后，每个哨兵开始监视新的主站。

玩转Redis必备的几款运维工具，好用爆了~

应用Redis时遇到的运维任务包括实时监控Redis执行状态、数据迁移、主从集群部署和运行、集群切片等。
为了帮助您理解和操作这些任务，本文介绍了几种Redis运维工具，重点介绍Redis的实时执行状态监控、数据迁移工具和集群管理工具。
###Redis中实时执行状态监控-**基本监控工具**：您可以使用Redis自带的`INFO`命令来获取有关您的实例的丰富监控信息。
INFO命令支持通过参数section分类获取各类监控信息。
这些部分分为五个类别，主要涵盖命令执行、内存使用和CPU资源使用等关键指标。
-**可视化监控工具**：使用第三方开源工具Prometheus，直观地展示“INFO”命令的返回结果。
Prometheus通过‘Redis-exporter’等插件实现监控功能，可以收集Redis的执行状态和统计信息，并通过Prometheus实现监控数据和报警设置的可视化。
Redis-exporter目前支持Redis版本2.0到6.0。
###数据迁移工具-**Redis-shake**：阿里云Redis和MongoDB团队开发的用于数据同步的工具。
它的工作方式是模拟一个Redis实例，实现与源实例的数据全同步。
Redis-shake支持单实例和集群之间的数据迁移，以及使用代理的集群切片。
它还支持Redis实例在云端和云端之间的迁移，帮助您将Redis服务带到云端。
###集群管理工具-**CacheCloud**：搜狐开发的一款用于Redis运维的云平台，支持主从集群、Sentinel集群、RedisCluster的自动部署和管理。
CacheCloud提供丰富的监控信息，包括实例运行状态、内存使用情况、客户端连接数、键值对数据量等，并允许用户从管理界面执行运维任务。
这些工具可帮助您更高效、直观地管理Redis应用程序的运维，包括实时监控、数据迁移和集群部署。
这些工具简化了运维流程，提高了效率，是Redis部署和管理过程中的得力助手。

redis集群模式三种方式

主从架构和哨兵模式在Redis中的应用Redis集群主要有三种模式：主从复制（masterslave）、哨兵（sentinel）监控和Redis集群（RedisCluster）。
其中，主从复制模式使用一个主节点（master）处理事务操作，其他从节点（slave）只负责读取并通过数据同步来维护一致性。
在原始架构中，所有从站都直接连接到主站，但为了处理大量从站，这可能会导致同步延迟，可以采用分层结构，其中一个从站充当代理来同步其他从站。
奴隶。
主从模式的核心是数据同步，由从节点发起，通过全量和增量数据同步来实现。
全同步是在Slave初始化时将所有数据复制到Master，在节点运行过程中Master进行写操作后同步到Slave，保证数据的一致性。
但异常恢复时，必须支持断点恢复。
设置主从模式时，通过配置文件调整节点角色，确认主节点的从机信息，通过操作检查集群结构是否正常。
主从模型的优点包括数据冗余和高可用性。
Redis2.8中引入了Sentinel机制，用于监控主从节点并处理故障转移。
客户端通过sentinel获取主节点信息，保证服务连续性。
Sentinel通过监控、ping请求和故障诊断来保证实例的健康状况，并在master出现故障时自动进行切换。
Redis集群是一种分布式存储，通过哈希轨道将数据分布到多个主节点上。
每个节点维护集群状态信息，并通过gossip协议维持节点之间的通信。
当key不在当前节点时，会通过MOVED重定向到处理节点。
无论是主从模式、哨兵监控还是Redis集群，每种模式都有其独特的优势，共同保证了Redis服务的高可用性和数据一致性。
通过了解这些模式，您可以更好地设计和管理Redis的分布式部署。

Docker搭建Redis主从复制

Redis主从复制是一种数据复制机制，其中主节点负责写入数据，从节点负责读取数据。
通常，系统仅由一个主节点和多个从节点组成。
创建主从复制集群时，首先需要创建三个配置文件，分别是redis6379.conf、redis6380.conf和redis6381.conf。
在这些配置文件中，分别指定主节点和两个从节点的配置信息。
接下来，使用Docker容器启动主节点和两个从节点。
通过查看容器状态和目录确认容器运行成功。
进入主节点容器并获取IP地址，这是从节点连接主节点时必须的信息。
对于从节点1来说，主节点绑定操作需要在容器内执行。
从节点2的配置与从节点1类似，但步骤可能略有不同。
验证主从复制功能时，从节点尝试添加数据，必然失败；主节点添加数据也必须成功，从节点主节点读取数据也必须成功；如果从节点宕机重启，新数据不会自动同步，需要手动调整配置。
当主节点宕机时，从节点仍然可以读取数据，主节点重启后，从节点数据恢复到崩溃前的状态。
一主二从配置不适合生产环境或者生产环境推荐集群模式。
这个过程将在下一篇文章中详细讨论。