笔记

后期或者大项目如果进一步优化 Redis，则使用主从复制，降低压力，提高效率。

• 1. 概念
• 2. 环境配置
• 3. 配置三类
  • 一主二从
  • 主从复制原理
  • 薪火相传
  • 反客为主
• 4. 哨兵模式
  • 什么是哨兵模式
  • 故障转移过程
  • 配置哨兵
  • 集群脑裂
  • 配置哨兵并测试
  • 哨兵模式的全部配置
  • Java整合

1. 概念

主从复制，是指将一台 Redis 服务器的数据，复制到其他的 Redis 服务器。前者称为主节点（master/leader），后者称为从节点（slave/follower）；数据的复制是单向的，只能由主节点到从节点。Master 以写为主，Slave 以读为主。

默认情况下，每台 Redis 服务器都是主节点；且一个主节点可以有多个从节点（或没有从节点），但一个从节点只能有一个主节点。

主从复制的作用主要包括：

1. 数据冗余：通过复制机制实现了数据的备份，为Redis数据提供了额外的保障。
2. 故障恢复：当主节点遇到故障时，可以迅速从从节点中选举或切换到一个新的主节点，从而恢复服务，减少服务中断时间。
3. 负载均衡：通过读写分离，主节点处理写请求，从节点处理读请求，有效分散读操作带来的负载，尤其适用于读操作远多于写操作的场景，提高了系统的并发处理能力。
4. 高可用基石：主从复制是Redis哨兵（Sentinel）和Redis集群（Cluster）实现高可用的基础架构，通过监控、通知和自动故障转移来维护Redis服务的可用性。

一般来说，要将 Redis 运用于工程项目中，只使用一台 Redis 是万万不能的，原因如下：

• 从结构上，单个 Redis 服务器会发生单点故障，并且一台服务器需要处理所有的请求负载，压力较大

• 从容量上，单个 Redis 服务器内存容量有限，就算一台 Redis 服务器内存容量为 256G，也不能将所有内存用作 Redis 存储内存，一般来说，单台 Redis 最大使用内存不应该超过 20G

电商网站上的商品，一般都是一次上传，无数次浏览的，说专业点也就是「多读少写」。

对于这种场景，我们可以使如下这种架构：

2. 环境配置

查看当前库的信息：info replication

127.0.0.1:6379> info replication
# Replication
role:master	# 角色：表示当前Redis实例的角色，这里显示为master，即主节点
connected_slaves:0	# 从机数量：当前连接到此主节点的从节点数量，这里为0表示没有从节点连接
master_failover_state:no-failover	# 主节点故障转移状态：显示当前主节点是否处于故障转移状态，no-failover表示没有进行故障转移
master_replid:1a6933acf7ec9711bfa0a1848976676557e1e6a0	# 主节点的复制ID：一个唯一标识，用于复制过程中识别主节点
master_replid2:0000000000000000000000000000000000000000	# 第二个复制ID：在进行故障转移或配置更改时使用
master_repl_offset:0	# 主节点复制偏移量：标识主节点数据流中数据的位置，用于从节点与主节点同步
second_repl_offset:-1	# 第二个复制偏移量：用于特殊情况下的数据同步
repl_backlog_active:0	# 复制积压缓冲区是否激活：0表示未激活，1表示激活。复制积压缓冲区用于存储暂时无法发送给从节点的数据
repl_backlog_size:1048576	# 复制积压缓冲区大小：以字节为单位，表示缓冲区的大小
repl_backlog_first_byte_offset:0	# 复制积压缓冲区的第一个字节的偏移量：表示缓冲区中第一个字节数据在主节点数据流中的位置
repl_backlog_histlen:0	# 复制积压缓冲区历史长度：表示当前缓冲区中数据的大小（字节）

因为没有多个服务器，就以本地开启 3 个端口，模拟 3 个服务

既然需要启动多个服务，就需要多个配置文件。每个配置文件对应修改以下信息：

• 端口号（port）
• pid文件名（pidfile）
• 日志文件名（logfile）
• rdb文件名（dbfilename）

拷贝多个 redis.conf 文件

端口分别是 6379、6380、6381，且每个文件开启 daemonize yes

[root@localhost ~]# cd /usr/local/bin/myredis
[root@localhost myredis]# ls
dump.rdb  redis.conf
[root@localhost myredis]# cp redis.conf redis79.conf
[root@localhost myredis]# cp redis.conf redis80.conf
[root@localhost myredis]# cp redis.conf redis81.conf
[root@localhost myredis]# ls
dump.rdb  redis79.conf  redis80.conf  redis81.conf  redis.conf

分别修改配置上面四点对应的配置，举例：

配置好分别启动 3 个不同端口服务

redis-server myredis/redis79.conf 
redis-server myredis/redis80.conf
redis-server myredis/redis81.conf

3. 配置三类

一主二从

主的文件（redis79.conf）

include /etc/redis.conf    # 引入核心配置文件
pidfile /var/run/redis_6379.pid   # 固定
port 6379                   # 主节点端口
dbfilename dump6379.rdb     # 持久化文件名
daemonize yes               # 以守护进程运行
protected-mode no
dir "/myredis"              # 数据和备份文件存储目录（自定义）

二从的文件（redis80.conf、redis81.conf）

include /etc/redis.conf    # 引入核心配置文件
pidfile /var/run/redis_6380.pid   # 固定
port 6380                   # 从节点端口
dbfilename dump6380.rdb     # 持久化文件名
daemonize yes               # 以守护进程运行
protected-mode no
dir "/myredis"              # 数据和备份文件存储目录（自定义）

################################################### 

include /etc/redis.conf    # 引入核心配置文件
pidfile /var/run/redis_6381.pid   # 固定
port 6381                   # 另一个从节点端口
dbfilename dump6381.rdb     # 持久化文件名
daemonize yes               # 以守护进程运行
protected-mode no
dir "/myredis"              # 数据和备份文件存储目录（自定义）

如果重新配置了文件内容，则需要重启 Redis 服务。

• 启动好 3 个不同端口服务后，我们再分别开启 Redis 连接

  redis-cli -p 6379
  redis-cli -p 6380
  redis-cli -p 6381
  

  通过 info replication 指令查看信息

  127.0.0.1:6379> info replication
  

  可以发现，默认情况下，开启的每个 Redis 服务器都是主节点

  

• 配置为一个 Master 和 两个 Slave（即一主二从）

  6379 为主，6380、6381 为从，分别在 6380、6381 的 Redis 上执行如下指令：

  slaveof 127.0.0.1 6379
  

  

• 在主机设置值，在从机都可以取到，但是从机不能写值

  

  我们这里是使用命令搭建，是「暂时的」，如果重启三个 Redis 服务，则又恢复到三主的地位

  如果想配置「永久的」，则去配置里进行修改，找到 slaveof <ip> <port> 指令进行配置：

  

使用规则

在Redis主从结构中，主节点负责处理写操作，而从节点则主要处理读请求。

• 主机宕机：如果主节点出现故障或宕机，从节点将无法再同步新的数据更改。在这种情况下，集群将失去写能力，但仍可以提供读服务。一旦主节点恢复，它将自动重新连接从节点，并恢复正常的复制流程。
• 从机宕机：如果从节点发生故障或宕机，它在重启后需要重新连接到主节点来同步数据。如果从节点没有使用配置文件永久设置为从节点，它可能会以主节点的身份启动，这时它将不包含主节点的数据。通过重新执行SLAVEOF命令或在配置文件中设置，可以使其再次成为从节点，并从主节点同步数据。

主从复制原理

当Redis的从节点启动并连接到主节点时，复制过程开始，这个过程分为两个主要阶段：全量复制（full synchronization）和增量复制（partial synchronization）。

全量复制

1. 初始化同步：当从节点首次连接到主节点，或由于某些原因需要重新同步全部数据时，从节点会向主节点发送SYNC命令来初始化复制过程。
2. 后台保存数据：主节点接收到SYNC命令后，会启动一个后台进程，该进程将当前数据库状态保存到磁盘上的临时RDB文件中。
3. 命令缓存：同时，主节点会开始缓存所有新的、会修改数据集的命令，确保在RDB文件生成期间发生的更改不会丢失。
4. 传输RDB文件：RDB文件生成后，主节点将这个文件发送给从节点。从节点将接收到的RDB文件保存到磁盘上，并加载到内存中，完成全量数据的同步。

增量复制

1. 应用增量更改：在全量复制之后，主节点会继续将那些在全量复制期间缓存的命令，以及之后所有新的写命令，发送给从节点。从节点按照接收到的命令顺序执行这些命令，以此实现增量数据的同步。
2. 持续同步：只要从节点保持连接，这种增量复制就会持续进行，确保从节点数据的实时更新和主节点的一致性。

自动触发全量复制

每当从节点重新连接到主节点时（比如，因为网络中断、从节点重启等），Redis会默认自动执行一次全量复制，以确保从节点的数据与主节点完全一致，避免数据不一致的问题。

有两种方式可以产生新的主机：看下文「反客为主」

薪火相传

Redis的"薪火相传"模式是指在Redis主从复制结构中，一个从节点（Slave）既可以接收来自主节点（Master）的数据同步，也可以作为另一个从节点的主节点，向它传递数据。这种配置方式形成了一种层级或链式的数据复制结构，从而实现了数据同步的分级传递。

特点

• 降低主节点负载：通过允许从节点再作为主节点对其他从节点进行数据同步，这种模式可以有效分散原本集中在单个主节点上的数据同步压力。
• 去中心化：这种分级复制的方式有助于去中心化，减少了对单一主节点的依赖，从而提高了整个系统的稳定性和可靠性。
• 灵活的数据同步：在复杂的应用场景中，"薪火相传"模式提供了一种灵活的数据同步解决方案，尤其适用于分布式数据共享和备份。

应用场景

• 负载均衡：在读密集型应用中，通过配置多级从节点来分担读操作的压力，实现负载均衡。
• 数据冗余备份：多级数据复制可以在不同的节点上创建多个数据副本，增强数据的冗余性和备份安全。
• 灾难恢复：在发生节点故障时，通过层级复制关系中的其他节点快速恢复数据，减少数据丢失和服务中断的风险。

实现方法

在Redis中实现"薪火相传"模式，需要通过配置每个从节点的slaveof指令，指定它们的主节点。例如，假设有三个Redis节点A、B和C，其中A是原始的主节点，B和C是从节点，可以这样配置：

1. B节点作为A节点的从节点。
2. C节点作为B节点的从节点。

通过这种方式，数据更新在A到B的过程中也会被同步到C，实现了数据的层级传递。

在一个从机用 slaveof <ip> <port> 指令连接另一个从机。

或者在配置文件里找到 slaveof <ip> <port> 指令进行配置。

反客为主

Redis的"反客为主"机制是指在主节点（Master）发生故障宕机的情况下，允许从节点（Slave）晋升为新的主节点，以保持服务的连续性和数据的可用性。这一机制是Redis高可用架构设计中的关键部分，确保了Redis集群在面对节点故障时能够快速自我恢复。

在Redis中，产生新的主节点主要有两种方式：

1. 手动晋升：在这种方式下，当检测到主节点宕机后，管理员需要手动地选择一个从节点，并通过执行SLAVEOF NO ONE命令让其脱离当前的复制关系，成为一个独立的主节点。这要求管理员对系统的状态有实时的监控，并能够迅速做出反应。

   redis-cli -p <slave_port> SLAVEOF NO ONE
   

   这条命令告诉从节点停止与任何主节点的复制过程，让它成为新的主节点。

2. 哨兵模式（自动选举）：哨兵（Sentinel）系统是Redis的高可用解决方案，能够监控Redis主从节点的运行状态。当主节点发生故障时，哨兵会自动从现有的从节点中选举一个作为新的主节点，并自动将其他从节点重新配置为新主节点的从节点。

   哨兵模式的自动选举过程大大简化了故障恢复的操作，无需人工干预，可以快速确保Redis服务的连续性。哨兵会考虑多个因素来选择新的主节点，比如节点的健康状态、复制偏移量和网络连接性等。

注意事项

• 选择新主节点的标准：无论是手动晋升还是哨兵自动选举，选择新主节点时都应考虑节点的数据完整性、网络延迟和系统负载等因素，以确保新主节点的稳定性和可靠性。

• 数据一致性：主节点宕机可能会导致部分最近的写操作丢失（取决于复制和持久化策略），在晋升新的主节点时应考虑数据一致性问题。

• 客户端处理：主节点发生变更时，客户端可能需要更新其连接配置以指向新的主节点。

通过"反客为主"机制，Redis提供了一种灵活且可靠的方式来处理主节点故障，无论是通过手动介入还是依赖于哨兵的自动选举，都能够确保Redis服务的高可用性。

4. 哨兵模式

什么是哨兵模式

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。Redis 从 2.8 开始正式提供了 Sentinel（哨兵）架构来解决这个问题。

反客为主的自动版，能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

哨兵模式是一种特殊的模式，首先 Redis 提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是 哨兵通过发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。

这里的哨兵有两个作用：

• 通过发送 Info Replication 命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器。
• 当哨兵监测到 Master 宕机，会自动将 Slave 切换成 Master，然后通过 发布订阅模式 通知其他的从服务器，修改配置文件，让它们切换主机。

然而一个哨兵进程对 Redis 服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

故障转移过程

1. 主观下线：当某个哨兵认为主节点不可达时，将该节点标记为主观下线状态。这个状态仅代表单个哨兵的观点，系统并不会马上进行 failover（故障转移）操作。
2. 客观下线：当足够多的哨兵（根据sentinel monitor配置的<count>值）都认为主节点不可达时，系统会将该主节点标记为客观下线。此时，哨兵间会通过投票选择一个哨兵来负责执行failover（故障转移）操作。
3. 选举新的主节点：选定的哨兵会从现有的从节点中选择一个作为新的主节点，并通知其他从节点改变复制关系，复制新的主节点。
4. 通知客户端：一旦新的主节点选举完成，哨兵会通过发布订阅模式通知所有客户端新主节点的信息。

配置哨兵

哨兵的配置主要通过sentinel monitor命令来实现，命令格式如下：

sentinel monitor <master-name> <ip> <port> <count>

• <master-name>是主节点的名称，由用户自定义。
• <ip>和<port>指定了主节点的网络地址。
• <count>是进行客观下线所需要的最小哨兵投票数，建议设置为(哨兵总数 / 2) + 1，以确保决策的一致性。

监控主节点的名字（自定义一个名字）、IP 和端口，最后一个 count 的意思是有几台 Sentinel 发现有问题，就会发生故障转移，例如配置为 2，代表至少有 2 个 Sentinel 节点认为主节点不可达，那么这个不可达的判定才是客观的。对于设置的越小，那么达到下线的条件越宽松，反之越严格。一般建议将其设置为 Sentinel 节点的一半加 1，count 不得大于 Sentinel 的个数。

集群脑裂

Redis集群脑裂是指在分布式环境中，由于网络分区或其他原因，导致集群中的一部分节点（例如，一个Master节点）与其他节点失去连接，但是该节点本身仍然正常运行。这种情况下，集群可能会错误地认为该节点已宕机，并触发故障转移过程，选举新的Master节点，从而导致集群中同时存在多个Master节点，即发生了脑裂现象。这不仅会导致数据不一致，还可能在原Master重新加入集群时导致数据丢失。

造成的问题

此时哨兵可能就会认为 Master 宕机了，然后开始选举，让其它 Slave 切换成 Master。这时候集群里就会有 2 个 Master，也就是所谓的脑裂。此时虽然某个 Slave 被切换成了 Master，但是可能 Client 还没来得及切换成新的 Master，还继续写向旧的 Master，这样数据可能就丢失了。因此旧 Master 再次恢复的时候，会被作为一个 Slave 挂到新的 Master 上去，自己的数据会被清空，重新从新的 Master 复制数据。

解决策略

为了减轻异步复制和脑裂导致的数据丢失风险，Redis提供了一些配置参数来增强集群的健壮性，在配置文件添加（模板）：

min-slaves-to-write 1

min-slaves-max-lag 10

• min-slaves-to-write：这个配置项指定了Master节点在接受写操作之前必须连接的最小Slave节点数量。设置为1表示至少需要有一个Slave节点连接，这有助于确保数据至少被复制到一个Slave，从而减少数据丢失的风险。
• min-slaves-max-lag：这个配置项用于指定Slave节点与Master节点之间复制数据的最大延迟时间（以秒为单位）。如果所有Slave节点的延迟都超过了这个时间，Master节点将停止接受写请求。这有助于避免在出现网络问题或Slave节点故障时继续写入可能会丢失的数据。

上面两个配置可以减少 异步复制 和 脑裂导致 的数据丢失。

原理：正常的 Slave 从 Master 复制数据，除了刚开始启动时需要全部复制，其他时候都是复制新的数据（增量复制），耗时少，一旦出现复制时间很长，则代表该 Slave 是刚启动的，非常有可能是旧的 Master 宕机重新启动，所以通过复制超时时间来判断是否是异步复制或者脑裂导致。

解决异步复制导致的数据丢失

在异步复制的过程当中，通过 min-slaves-max-lag 这个配置，就可以确保的说，一旦 Slave 复制数据和 ack 延迟时间太长，就认为可能 Master 宕机后损失的数据太多了，那么就拒绝写请求，这样就可以把 Master 宕机时由于部分数据未同步到 Slave 导致的数据丢失降低到可控范围内。

解决集群脑裂导致的数据丢失

集群脑裂因为 Client 还没来得及切换成新的 Master，还继续写向旧的 Master，这样数据可能就丢失了，通过 min-slaves-to-write 确保必须是有多少个从节点连接，并且延迟时间小于 min-slaves-max-lag 多少秒。

配置哨兵并测试

在Redis中配置哨兵（Sentinel）是实现自动故障转移和高可用性的关键步骤。哨兵能够监控Redis主从服务器的运行状态，并在主服务器出现故障时自动完成主从切换。以下是如何配置和测试Redis哨兵的详细步骤：

1. 哨兵配置准备

1. 调整Redis结构：确保你有一个运行中的Redis主服务器（例如端口为6379），以及两个从服务器（端口为6380和6381）。

2. 创建哨兵配置文件：在自定义目录（如/myredis）下新建一个名为sentinel.conf的哨兵配置文件。请确保文件名称正确无误。

2. 配置哨兵文件

在sentinel.conf文件中填入以下配置内容：

sentinel monitor mymaster 127.0.0.1 6379 1

这里的配置说明如下：

• mymaster是你为被监控的Redis主服务器设置的名字，这个名称是自定义的，用于在哨兵中标识这个Redis实例。
• 127.0.0.1 6379指定了主服务器的IP地址和端口号。
• 最后的数字1指的是进行故障转移时，需要的最小哨兵同意票数。在这个示例中，只需一个哨兵投票就可以触发主从切换。实际部署时，这个数字应该根据你部署的哨兵数量来决定，通常设置为哨兵数量的一半加一，以确保决策的有效性和一致性。

3. 启动哨兵

使用以下命令启动哨兵进程：

redis-sentinel /path/to/myredis/sentinel.conf

请确保路径/path/to/myredis/sentinel.conf正确指向你的哨兵配置文件。如果你部署了多个哨兵，需要在每个哨兵所在的机器上重复这个步骤，使用各自的配置文件启动哨兵。

成功启动哨兵模式状态如下：

此时哨兵监视着我们的主机 6379，当我们断开主机后：

哪个从机会被选举为主机呢？根据优先级别：slave-priority，这个指令需要去每个从机的配置文件进行配置，默认都是 100。

建议每个从机都配置不同的 slave-priority，这样可以避免复制延时。

值越小优先级越高。

复制延时

由于所有的写操作都是先在 Master 上操作，然后同步更新到 Slave 上，所以从 Master 同步到 Slave 机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave 机器数量的增加也会使这个问题更加严重。

哨兵模式的优缺点

优点：

1. 哨兵集群，基于主从复制模式，所有主从复制的优点，它都有
2. 主从可以切换，故障可以转移，系统的可用性更好
3. 哨兵模式是主从模式的升级，手动到自动，更加健壮

缺点：

1. Redis 不好在线扩容，集群容量一旦达到上限，在线扩容就十分麻烦
2. 实现哨兵模式的配置其实是很麻烦的，里面有很多配置项

哨兵模式的全部配置

完整的哨兵模式配置文件 sentinel.conf

# Example sentinel.conf
 
# 哨兵 sentinel 实例运行的端口 默认 26379
port 26379
 
# 哨兵 sentinel 的工作目录
dir /tmp
 
# 哨兵 sentinel 监控的 redis 主节点的 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 1
 
# 当在 Redis 实例中开启了 requirepass foobared 授权密码 这样所有连接 Redis 实例的客户端都要提供密码
# 设置哨兵 sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
 
 
# 指定多少毫秒之后 主节点没有应答哨兵 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
 
# SCRIPTS EXECUTION
 
# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员。
# 对于脚本的运行结果有以下规则：
# 若脚本执行后返回 1，那么该脚本稍后将会被再次执行，重复次数目前默认为 10
# 若脚本执行后返回 2，或者比 2 更高的一个返回值，脚本将不会重复执行。
# 如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为 1 时的行为相同。
# 一个脚本的最大执行时间为 60s，如果超过这个时间，脚本将会被一个 SIGKILL 信号终止，之后重新执行。
 
# 通知型脚本:当 sentinel 有任何警告级别的事件发生时（比如说 Redis 实例的主观失效和客观失效等等），将会去调用这个脚本，
# 这时这个脚本应该通过邮件，SMS 等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，
# 一个是事件的类型，
# 一个是事件的描述。
# 如果 sentinel.conf 配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则 sentinel 无法正常启动成功。
# 通知脚本
# sentinel notification-script <master-name> <script-path>
  sentinel notification-script mymaster /var/redis/notify.sh
 
# 客户端重新配置主节点参数脚本
# 当一个 Master 由于 failover 而发生改变时，这个脚本将会被调用，通知相关的客户端关于 Master 地址已经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前 <state> 总是「failover」,
# <role> 是「leader」或者「observer」中的一个。 
# 参数 from-ip, from-port, to-ip, to-port 是用来和旧的 Master 和新的 Master(即旧的 Slave)通信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

Java整合

开启哨兵后，Java 获取哨兵的代码：

public class RedisSentinel {
    private static JedisSentinelPool jedisSentinelPool = null;
    public static Jedis getJedisFromSentinel(){
        if(jedisSentinelPool == null){
            Set<String> sentinelSet = new HashSet<>();
            sentinelSet.add("192.168.11.103:26379"); // 指定哨兵的 ip 和端口
            JedisPoolConfig jedisPoolConfig = new JedisPoolConfig();
            jedisPoolConfig.setMaxTotal(10); // 最大可用连接数
            jedisPoolConfig.setMaxIdle(5); // 最大闲置连接数
            jedisPoolConfig.setMinIdle(5); // 最小闲置连接数
            jedisPoolConfig.setBlockWhenExhausted(true); // 连接耗尽是否等待
            jedisPoolConfig.setMaxWaitMillis(2000); // 等待时间
            jedisPoolConfig.setTestOnBorrow(true); // 去连接的时候进行一下测试 ping pong
            jedisSentinelPool = new JedisSentinelPool("mymaster",sentinelSet,jedisPoolConfig);
            return jedisSentinelPool.getResource();
        }else{
            return jedisSentinelPool.getResource();
        }
    }
}