配置文件中的各个参数，详解
2、主机(master)配置:
bind：0.0.0.0 #表示允许所有远程访问。如果想指定限制访问，可设置对应的 ip。
port：6379 #关闭保护模式，可以外部访问。
daemonize：yes # 设置为后台启动。
logfile：./redis.log # 日志文件。
requirepass：pwdtest@2019 #设置 redis 连接密码。
masterauth：pwdtest@2019 #slave 服务连接 master 的密码
3、从机(slave)的配置和主机相似，不同的地方是需要使用replicaof指定主机（master）的IP地址和端口，需要注意的是老版本使用的是 slaveof
当本机为 slave 服务时，设置 master 服务的IP地址及端口，在 redis 启动的时候会自动跟 master 进行数据同步
4、启动:切换到 bin 目录，使用./redis-server即可启动 redis 服务，但是这种方式没有指明配置文件，redis 将采用默认配置，所以我们需要让 redis 按照我们的配置文件来启动,启动时指定刚才我们复制到 etc 文件夹下的redis.conf
三、Sentinel(哨兵)模式:
1、哨兵模式详解
Redis Sentinel是Redis 的高可用性解决方案，由一个或多个Sentinel（哨兵）实例组成。它可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，它的主要功能如下：
监控(Monitoring)：Sentinel会不断地检查你的主服务器和从服务器是否运作正常。
通知(Notification)：当被监控的某个 Redis 服务器出现问题时， Sentinel可以通过API向管理员或者其他应用程序发送通知。
故障迁移：当主服务器不能正常工作时，Sentinel会自动进行故障迁移，也就是主从切换。
统一的配置管理：连接者询问sentinel取得主从的地址。
2、原理:
Sentinel 使用的算法核心是 Raft 算法，主要用途就是用于分布式系统，系统容错，以及Leader选举，每个Sentinel都需要定期的执行以下任务：
每个 Sentinel 会自动发现其他 Sentinel 和从服务器，它以每秒钟一次的频率向它所知的主服务器、从服务器以及其他 Sentinel 实例发送一个 PING 命令。
如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 那么这个实例会被 Sentinel 标记为主观下线。 有效回复可以是： +PONG 、 -LOADING 或者 -MASTERDOWN 。
如果一个主服务器被标记为主观下线， 那么正在监视这个主服务器的所有Sentinel要以每秒一次的频率确认主服务器的确进入了主观下线状态。
如果一个主服务器被标记为主观下线， 并且有足够数量的Sentinel（至少要达到配置文件指定的数量）在指定的时间范围内同意这一判断， 那么这个主服务器被标记为客观下线。
在一般情况下， 每个Sentinel会以每 10 秒一次的频率向它已知的所有主服务器和从服务器发送 INFO 命令。 当一个主服务器被Sentinel标记为客观下线时，Sentinel向下线主服务器的所有从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。
当没有足够数量的Sentinel同意主服务器已经下线， 主服务器的客观下线状态就会被移除。 当主服务器重新向Sentinel的 PING 命令返回有效回复时， 主服务器的主管下线状态就会被移除。
3、哨兵的配置主要就是修改sentinel.conf配置文件中的参数，在Redis安装目录即可看到此配置文件
参数详解
# 哨兵sentinel实例运行的端口，默认26379
port 26379
# 哨兵sentinel的工作目录
dir ./
# 是否开启保护模式，默认开启。
protected-mode:no
# 是否设置为后台启动。
daemonize:yes
# 哨兵sentinel的日志文件
logfile:./sentinel.log
# 哨兵sentinel监控的redis主节点的
## ip：主机ip地址
## port：哨兵端口号
## master-name：可以自己命名的主节点名字（只能由字母A-z、数字0-9 、这三个字符".-_"组成。）
## quorum：当这些quorum个数sentinel哨兵认为master主节点失联 那么这时 客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass，所有连接Redis实例的客户端都要提供密码。
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster 123456
# 指定主节点应答哨兵sentinel的最大时间间隔，超过这个时间，哨兵主观上认为主节点下线，默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 指定了在发生failover主备切换时，最多可以有多少个slave同时对新的master进行同步。这个数字越小，完成failover所需的时间就越长；反之，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1，来保证每次只有一个slave，处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间failover-timeout，默认三分钟，可以用在以下这些方面：
## 1. 同一个sentinel对同一个master两次failover之间的间隔时间。
## 2. 当一个slave从一个错误的master那里同步数据时开始，直到slave被纠正为从正确的master那里同步数据时结束。
## 3. 当想要取消一个正在进行的failover时所需要的时间。
## 4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来同步数据了
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# 当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等），将会去调用这个脚本。一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
# 对于脚本的运行结果有以下规则：
## 1. 若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10。
## 2. 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
## 3. 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/
4、搭建：编辑 sentinel.conf，配置文件修改如
//端口默认为26379。
port:26379
//关闭保护模式，可以外部访问。
protected-mode:no
//设置为后台启动。
daemonize:yes
//日志文件。
logfile:./sentinel.log
//指定主机IP地址和端口，并且指定当有2台哨兵认为主机挂了，则对主机进行容灾切换。
sentinel monitor mymaster 192.168.231.130 6379 2
//当在Redis实例中开启了requirepass，这里就需要提供密码。
sentinel auth-pass mymaster pwdtest@2019
//这里设置了主机多少秒无响应，则认为挂了。
sentinel down-after-milliseconds mymaster 3000
//主备切换时，最多有多少个slave同时对新的master进行同步，这里设置为默认的1。
sentinel parallel-syncs mymaster 1
//故障转移的超时时间，这里设置为三分钟。
sentinel failover-timeout mymaster 180000
5、启动：redis-sentinel ./entinel.conf(配置文件路径)三、缺点:资源使用：每个 Sentinel 实例也会占用系统资源，包括 CPU 和内存，尤其是在大型集群中。
网络依赖性：Sentinel 的效果很大程度上依赖于网络的可靠性。网络分区或是延迟高的情况可能会导致误判或故障转移延迟。
冷启动问题：如果所有 Redis 节点同时宕机，Sentinel 系统无法自动恢复，需要手动干预来重新设置主节点和从节点。
数据丢失风险：在发生故障转移时，如果还有未同步到从节点的数据，那么这部分数据可能会丢失。这是因为 Redis 使用异步复制。
四、写操作局限性
单点瓶颈：在一主多从架构中，所有写操作都必须由主节点处理。这意味着主节点的处理能力和资源（CPU、内存、网络带宽）将直接限制系统的写入吞吐量。
数据同步延迟：尽管从节点可以提供读扩展性，它们依赖于与主节点的数据同步。高写负载情况下，数据复制到从节点可能会经历延迟,影响了数据的最终一致性。
故障风险：如主节点出现故障，整个系统的写能力会丧失直到故障转移完成并且一个从节点被提升为新的主节点。这个过程可能会导致服务中断。