JavaEE 企业级分布式高级架构师（五）Redis学习笔记（4）

讲文明的喜羊羊拒绝pua

于 2020-08-28 00:01:05 发布

阅读量281

点赞数

分类专栏： Redis 文章标签： Redis主从复制 Redis哨兵机制 Redis集群演变

本文链接：https://blog.csdn.net/yangwei234/article/details/108271034

版权

Redis 专栏收录该内容

6 篇文章 2 订阅

订阅专栏

Redis学习笔记

集群篇

集群篇

Redis主从复制

什么是主从复制

持久化保证了即使 Redis服务器重启也不会丢失数据，因为 Redis 服务器重启后会将硬盘上持久化的数据恢复到内存中，但是当 Redis 服务器的硬盘损坏了可能会导致数据丢失，不过通过 Redis 的主从复制机制就可以避免这种单点故障，如下图：
在这里插入图片描述
说明：

主 Redis 中的数据有两个副本（replication），即从 Redis1 和从 Redis2，即使一台Redis服务器宕机其他两台Redis服务也可以继续提供服务
主 Redis 中的数据和从 Redis 上的数据保持实时同步，当主 Redis 写入数据时，通过主从复制机制会复制到两个从 Redis 服务器上
只有一个主 Redis，可以有多个从 Redis
主从复制不会阻塞 master，在同步数据时，master可以继续处理 client 请求
一个 Redis 可以即是主有是从，如下图：

主从配置

主Redis配置

无需特殊配置

从Redis配置

修改从服务器上的Redis.conf文件

# replicaof <masterip> <masterport>
# 表示当前【从服务器】对应的【主服务器】的IP是192.168.10.135，端口是6379。 
# 4.0之前只能slaveof 4.0之后默认replicaof，slaveof也起作用
slaveof 192.168.254.128 6379
replicaof 192.168.254.128 6379

实现原理

Redis 的主从同步，分为全量同步和增量同步
只有从机第一次连接上主机是全量同步
断线重连有可能触发全量同步，也有可能是增量同步（master判断runid是否一致）
除此之外的情况都是增量同步

全量同步

Redis 的全量同步过程主要分三个阶段：

同步快照阶段：Master创建并发送快照给Slave，Slave载入并解析快照。Master同时将此阶段所产生的新的写命令存储到缓冲区
同步写缓冲阶段：Master向Slave同步存储在缓冲区的写操作命令
同步增量阶段：Master向Slave同步写操作命令

增量同步

Redis增量同步主要指Slave完成初始化后开始正常工作时，Master发生的写操作同步到Slave的过程
通常情况下，Master每执行一个写命令就会向Slave发送相同的写命令，然后Slave接收并执行

Redis哨兵机制(难点,面试)

Redis主从复制的缺点：没有办法对master进行动态选择，需要使用Sentinel机制完成动态选举

简介

哨兵(Sentinel)主要是为了解决在主从复制架构中出现宕机的情况，主要分为两种情况：
- 从Redis宕机：这个相对而言比较简单，在Redis中从库重新启动后会自动加入到主从架构中，自动完成同步数据。在Redis2.8版本后,主从断线后恢复的情况下实现增量复制。
- 主Redis宕机：这个相对而言就会复杂一些，需要以下2步才能完成
  - 在从数据库中执行SLAVEOF NO ONE命令，断开主从关系并且提升为主库继续服务。
  - 将主库重新启动后，执行SLAVEOF命令，将其设置为其他库的从库，这时数据就能更新回来。
- 由于这个手动完成恢复的过程其实是比较麻烦的并且容易出错，所以 Redis 提供的哨兵 (sentinel) 的功能来解决。

Sentinel（哨兵）进程是用于监控 Redis 集群中 Master 主服务器工作的状态，在 Master 主服务器发送故障的时候，可以实现 Master 和 Slave 服务器的切换，保证系统的高可用（HA）。
其已经被集成在 redis2.6+ 的版本中，Redis的哨兵模式到了 2.8版本之后就稳定了下来。

Redis Sentinel工作原理分析

哨兵(sentinel)机制的高可用

Sentinel(哨兵)是Redis 的高可用性解决方案：由一个或多个Sentinel 实例组成的Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器。如下图所示：
在Server1 掉线后：
升级Server2 为新的主服务器：

哨兵的定时监控

任务1：每个哨兵节点每10秒会向主节点和从节点发送info命令获取最新拓扑结构图，哨兵配置时只要配置对主节点的监控即可，通过向主节点发送info，获取从节点的信息，并当有新的从节点加入时可以马上感知到。
任务2：每个哨兵节点每隔2秒会向redis数据节点的指定频道上发送该哨兵节点对于主节点的判断，以及当前哨兵节点的信息，同时每个哨兵节点也会订阅该频道，来了解其它哨兵节点的信息及对主节点的判断，其实就是通过消息publish和subscribe来完成的。
任务3：每隔1秒每个哨兵会向主节点、从节点及其余哨兵节点发送一次ping命令做一次心跳检测，这个也是哨兵用来判断节点是否正常的重要依据。

故障判定原理分析

主观下线(SDOWN)：所谓主观下线，就是单个sentinel认为某个服务下线(有可能是接收不到订阅，之间的网络不通等等原因)。
sentinel会以每秒一次的频率向所有与其建立了命令连接的实例(master、slave服务，其他sentinel)发 ping命令，通过判断ping回复是有效回复，还是无效回复来判断实例时候在线(对该sentinel来说是“主观在线”)。
sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down- after-milliseconds毫秒内，返回的都是无效回复，那么sentinel回认为该实例已(主观)下线，修改其 flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after- milliseconds配置不同，这个在实际生产中要注意。
客观下线(ODOWN)：当主观下线的节点是主节点时，此时该哨兵3节点会通过指令sentinel is-masterdown-by- addr寻求其它哨兵节点对主节点的判断，如果其他的哨兵也认为主节点主观线下了，则当认为主观下线的票数超过了quorum(选举)个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了，大部分哨兵节点都同意下线操作，也就说是客观下线。

重点：sentinel monitor

哨兵Leader的选举流程

如果主节点被判定为客观下线之后，就要选取一个哨兵节点来完成后面的故障转移工作，选举出一个Leader的流程如下：

每个在线的哨兵节点都可以成为领导者，当它确认(比如哨兵3)主节点下线时，会向其它哨兵发is-master-down-by-addr命令，征求判断并要求将自己设置为领导者，由领导者处理故障转移。
当其它哨兵收到此命令时，可以同意或者拒绝它成为领导者。
如果哨兵3发现自己在选举的票数num 大于等于 (sentinels)/2+1时，将成为领导者，如果没有超过，继续选举…

自动故障转移机制

【在从节点中选择新的主节点】：sentinel状态数据结构中保存了主服务的所有从服务信息，领头sentinel按照如下的规则从从服务列表中挑选出新的主服务：

过滤掉主观下线的节点；
选择slave-priority/ replica-priority最高的节点，如果有则返回没有就继续选择；
选择出复制偏移量最大的系节点，因为复制偏移量越大则数据复制的越完整，如果由就返回了，没有就继续；
选择run_id最小的节点。

【更新主从状态】通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
将已下线的主节点设置成新的主节点的从节点，当其回复正常时，复制新的主节点，变成新的主节点的从节点。
同理，当已下线的服务重新上线时，sentinel会向其发送slaveof命令，让其成为新主的从。

哨兵进程的作用

监控（Monitoring）：哨兵（sentinel）会不断地检查你的 Master 和 Slave 是否运行正常
提醒（Notification）：当被监控的某个Redis节点出现问题时，哨兵（sentinel）可以通过 API 向管理员或者其他应用程序发送通知
自动故障迁移（Automatic failover）：当一个 Master 不能正常工作时，哨兵（sentinel）会开始一次自动故障迁移操作，具体操作如下：

* 它会将失效Master的其中一个Slave升级为新的Master，并让失效Master的其他Slave改为复制新的Master
* 当客户端视图连接失效的Master时，集群也会向客户端返回新Master地址，使得集群可以使用现在的Master替换失效Master
* Master和Slave服务器切换后，Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变，即Master主服务器的redis.conf配置文件中会多一行slaveof的配置，sentinel.conf的监控目标会随之调换

哨兵配置

修改从机的 sentinel.conf

# 【命令格式】：sentinel monitor <master-name> <master ip> <master port> <quorum>
# 参数<master-name>：可以自己命名的主节点名字，只能由字母[a-zA-Z]、数字[0-9]、[,-_]组成
# 参数<master ip> <master port>：哨兵 sentinel 监控的 redis 主节点的 IP PORT
# 参数<quorum>：当有 quorum个 sentinel哨兵认为master主节点失联，那么这时客观上认为主节点失联了
sentinel monitor mymaster 192.168.254.128 6379 1

其他配置项说明

# 哨兵 sentinel 实例运行的端口 默认26379
port 26379

# 哨兵 sentinel 的工作目录
dir /tmp

# 【命令格式】：sentinel monitor <master-name> <master ip> <master port> <quorum>
sentinel monitor mymaster 127.0.0.1 6379 2

# 【命令格式】：sentinel auth-pass <master-name> <password>
# 当在 Redis 实例中开启了requirepass foobared 授权密码，这样所有连接 Redis 实例的客户端都要提供密码
# 设置哨兵 sentinel 连接主从的密码，注意必须为 主从设置一样的验证密码
sentinel auth-pass mymaster MySUPER--secret-0123passwOrd

# 【命令格式】：sentinel down-after-milliseconds <master-name> <milliseconds>
# 指定多少毫秒之后，主节点没有应答哨兵 sentinel，此时哨兵主观认为主节点下线，默认30秒
sentinel down-after-milliseconds mymaster 30000

# 【命令格式】：sentinel parallel-syncs <master-name> <numslaves>
# 这个配置项指定了在发生 failover 主备切换时，最多可以有多少个 slave 同时对新的 master 进行同步，
# 这个数字越小，完成 failover 所需的时间就越长，但是如果这个数字越大，就意味着越多的 slave 因为 replication 而不可用
# 可以通过将这个值设为 1 来保证每次只有一个 slave 处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 1

# 【命令格式】：sentinel failover-timeout <master-name> <milliseconds>
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
# 1. 同一个 sentinel 对同一个 master 两次 failover 之间的间隔时间
# 2. 当一个 slave 从一个错误的 master 那里同步数据开始计算时间，直到 slave 被矫正为向正确的 master 那里同步数据时
# 3. 当想要取消一个正在进行的 failover 所需要的时间
# 4. 当进行 failover 时，配置所有 slaves 指向新的 master 所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向 master，但是就不按 parallel-syncs 所配置的规则来了
# 默认三分钟
sentinel failover-timeout mymaster 180000

# SCRIPTS EXECUTION

# 配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知相关人员
# 对于脚本的运行结果有以下规则：
# 若脚本执行后返回1，那么该脚本稍后将会再次执行，重复次数目前默认为10
# 若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行
# 如果脚本在执行过程中由于收到系统中断信号被终止了，则通返回值1时的行为相同
# 一个脚本的最大执行时间为60s，如果超时，脚本将会被一个SIGKILL信号终止，之后重新执行

# 【命令格式】：sentinel notification-script <master-name> <script-path>
# 通知型脚本：当 sentinel 有任何警告级别的时间发生时（比如说redis实例的主观失效和客观失效等），将会去调用这个脚本，这时这个脚本应该通过邮件、SMS等方式去通知系统管理员关于系统不正常运行的信息。调用该脚本时，将传给脚本两个参数，一个是事件类型，一个是事件的描述。
# 如果sentinel.conf配置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无法正常启动成功。
sentinel notification-script mymaster /var/redis/notify.sh

# 【命令格式】：sentinel client-reconfig-script <master-name> <script-path>
# 客户端重新配置主节点参数脚本
# 当一个 master 由于 failover 而发生改变时，这个脚本将会被调用，通知相关的客户端关于 master 地址已经发生改变的信息
# 以下参数将会在调用脚本时传给脚本：
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port>
# 目前<state>总是 failover
# 参数<from-ip> <from-port> <to-ip> <to-port>是用来和旧的master与新的master（即旧的slave）通信的这个脚本应该是通用的，能被多次调用，不是针对性的。
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh

通过 redis-sentinel 启动哨兵服务

./redis-sentinel sentinel.conf

Redis集群演变

主从复制

参考主从复制

Replication+Sentinel 高可用

这套架构使用的是社区版本推出的原生高可用解决方案，其架构图如下

这里Sentinel的作用有三个：
监控：Sentinel 会不断的检查主服务器和从服务器是否正常运行。
通知：当被监控的某个Redis服务器出现问题，Sentinel通过API脚本向管理员或者其他的应用程序发送通知。
自动故障转移：当主节点不能正常工作时，Sentinel会开始一次自动的故障转移操作，它会将与失效主节点是主从关系的其中一个从节点升级为新的主节点，并且将其他的从节点指向新的主节点。

工作原理

当Master宕机的时候，Sentinel会选举出新的Master，并根据Sentinel中client-reconfig-script脚本配置的内容，去动态修改VIP(虚拟IP)，将VIP(虚拟IP)指向新的Master。我们的客户端就连向指定的VIP即可。故障发生后的转移情况，可以理解为下图：

缺陷

主从切换的过程中会丢数据。
Redis只能单点写，不能水平扩容。

常用方案

内网DNS，VIP和封装客户端直连Redis Sentinel 端口。

内网DNS

底层是 Redis Sentinel 集群，代理着 Redis 主从，Web 端连接内网 DNS 提供服务。内网 DNS 按照一定的规则分配，比如 xxxx.redis.cache/queue.port.xxx.xxx，第一个段表示业务简写，第二个段表示这是 Redis 内网域名，第三个段表示 Redis 类型，cache 表示缓存，queue 表示队列，第四个段表示Redis 端口，第五、第六个段表示内网主域名。当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达，Sentinel 集群会调用 client-reconfig- 配置的脚本，修改对应端口的内网域名。对应端口的内网域名指向新的 Redis 主节点。
优点：秒级切换，10秒之内；脚本自定义，架构可控；对应用透明，前端不用担心后端发生什么变化。
缺点：维护成本高；依赖DNS，存在解析超时；哨兵存在短时间服务不可用；服务时通过外网不可采用。

VIP

和第一种方案略有不同，把内网 DNS 换成了虚拟 IP。底层是 Redis Sentinel 集群，代理着 Redis 主从，Web 端通过 VIP 提供服务。在部署 Redis 主从的时候，需要将虚拟 IP 绑定到当前的 Redis 主节点。当主节点发生故障，比如机器故障、Redis 节点故障或者网络不可达，Sentinel 集群会调用 client-reconfig- 配置的脚本，将 VIP 漂移到新的主节点上。
优点：秒级切换，5秒之内 ;脚本自定义，架构可控;对应用透明，前端不用担心后端发生什么变化。
缺点：维护成本更高，使用VIP增加维护成本，并存在IP混乱风险。

封装客户端直连Redis Sentinel 端口

这个主要是因为有些业务只能通过外网访问 Redis，于是衍生出了这种方案。Web 使用客户端连接其中一台 Redis Sentinel 集群中的一台机器的某个端口，然后通过这个端口获取到当前的主节点，然后再连接到真实的 Redis 主节点进行相应的业务员操作。需要注意的是，Redis Sentinel 端口和 Redis 主节点均需要开放访问权限。前端业务使用 Java，有JedisSentinelPool 可以复用。
优点：服务探测故障及时，DBA维护成本低。
缺点：依赖客户端支持Sentinel；Sentinel 服务器和 Redis 节点需要开放访问权限；再有对应用有侵入性。

Proxy+Replication+Sentinel(了解)

这里的Proxy有两种选择：Codis(豌豆荚)和Twemproxy(推特)。

因为Codis开源的比较晚，考虑到更换组件的成本问题。毕竟本来运行好好的东西，你再去换组件，风险是很大的。
Redis Cluster在2015年还是试用版，不保证会遇到什么问题，因此不敢尝试。所以我没接触过Codis，之前一直用的是Twemproxy作为Proxy。这里以Twemproxy为例说明，如下图所示：

工作原理

前端使用Twemproxy+KeepAlived做代理，将其后端的多台Redis实例分片进行统一管理与分配。
每一个分片节点的Slave都是Master的副本且只读。
Sentinel持续不断的监控每个分片节点的Master，当Master出现故障且不可用状态时，Sentinel会通知/启动自动故障转移等动作。
Sentinel 可以在发生故障转移动作后触发相应脚本(通过 client-reconfig-script 参数配置 )，脚本获取到最新的Master来修改Twemproxy配置。

缺陷

部署结构超级复杂。
可扩展性差，进行扩缩容需要手动干预。
运维不方便。
Redis3.0以后推出的Redis cluster集群方案，Redis cluster集群保证了高可用、高性能、高可扩展性

Redis-cluster集群(重点)

Redis-cluster架构图

在这里插入图片描述

架构细节

所有的 redis 节点彼此互联（PING-PONG机制），内部使用二进制协议优化传输速度和带宽
所有节点的 fail 是通过集群中超过半数的节点检测失效时才生效
客户端与 redis 节点直连，不需要中间 proxy 层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可
redis-cluster 把所有的物理节点映射到[0-16383]slot上，cluster 负责维护 node<=>slot<=>value

Redis 集群中内置了16383个哈希槽，当需要在 Redis 集群中放置一个 key-value 时，redis 先对 key 使用 crc16 算法算出一个结果，然后把结果对16384求余数，这样每个key都会对应一个编号 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点

在这里插入图片描述

Redis-cluster投票：容错

如何判断redis cluster中的master主节点 fail？
如何判断redis cluster集群 fail？
节点失效判断：集群中所有master参与投票，如果半数以上master节点与其中一个master节点通常超过（cluster-node-timeout），认为该master节点挂掉。

集群失效判断：什么时候整个集群不可用（cluster_state:fail）？

如果集群任意 master 挂掉，且当前 master 没有slave，则集群进入fail状态。也可以理解为 [0-16383]slot 映射不完全时进入 fail 状态
如果集群超过半数以上 master 挂掉，无论是否有 slave，集群进入 fail 状态。

工作原理

客户端与Redis节点直连,不需要中间Proxy层，直接连接任意一个Master节点。
根据公式HASH_SLOT=CRC16(key) mod 16384，计算出映射到哪个分片上，然后Redis会去相应的节点进行操作。

优点

无需Sentinel哨兵监控，如果Master挂了，Redis Cluster内部自动将Slave切换Master。
可以进行水平扩容。
支持自动化迁移，当出现某个Slave宕机了，那么就只有Master了，这时候的高可用性就无法很好的保证了，万一Master也宕机了，咋办呢? 针对这种情况，如果说其他Master有多余的Slave ，集群自动把多余的Slave迁移到没有Slave的Master 中。

缺点

批量操作是个坑。
资源隔离性较差，容易出现相互影响的情况。

Redis Cluster集群安装

安装Ruby环境

redis 集群需要使用集群管理脚本 redis-trib.rb，它的执行相应依赖 ruby 环境

第一步：安装 ruby

yum install ruby
yum install rubygems

第二步：下载 redis-3.2.2.gem（下载地址：https://rubygems.org/downloads/redis-3.2.2.gem），并安装

gem install redis-3.2.2.gem

在这里插入图片描述

第三步：复制 redis-3.2.9/src/redis-trib.rb 文件到 /usr/local/server/redis-cluster目录

cp /root/redis-3.2.9/src/redis-trib.rb /usr/local/server/redis-cluster/ -r

安装RedisCluster

Redis集群最少需要三台主服务器，三台从服务器
端口号分别为：7001 ~ 7006

第一步：创建7001实例，并编辑redis.conf文件，修改port为7001.
注意：创建实例，即拷贝单机版安装时，生成的 bin 目录，为7001（cp /usr/local/server/redis/bin/ ./7001 -r）
第二步：修改 redis.conf 配置文件，打开 Cluster-enable yes
第三步：复制7001，创建7002~2006实例，注意端口修改
第四步：启动所有实例，vim start-cluster.sh：

cd ./7001
./redis-server redis.conf
cd ..
cd ./7002
./redis-server redis.conf
cd ..
cd ./7003
./redis-server redis.conf
cd ..
cd ./7004
./redis-server redis.conf
cd ..
cd ./7005
./redis-server redis.conf
cd ..
cd ./7006
./redis-server redis.conf
cd ..

在这里插入图片描述

第五步：创建Redis集群

./redis-trib.rb create --replicas 1 192.168.254.128:7001 192.168.254.128:7002 192.168.254.128:7003 192.168.254.128:7004 192.168.254.128:7005 192.168.254.128:7006
# --replicas 1 ： 表示一主一从

在这里插入图片描述

命令客户端连接集群

命令：

./redis-cli -h 127.0.0.1 -p 7001 -c

在这里插入图片描述

注意：-c 表示是以 redis 集群方式进行连接

查看集群的命令

查看集群状态
查看集群中的节点

维护节点

集群创建成功后可以继续向集群中添加节点

添加主节点

先创建7007节点

cp -f ./7001 ./7007
cd 7007
rm -rf appendonly.aof
rm -rf dump.rdb
rm -rf nodes.conf

修改7007节点的配置文件，将端口好改为7007
添加7007节点作为新节点，执行命令：

./redis-trib.rb add-node 127.0.0.1:7007 127.0.0.1:7001

在这里插入图片描述

查看集群节点，发现7007已添加到集群中，但是7007并没有分配槽

hash槽重新分配（数据迁移）

添加完主节点，需要对主节点进行hash槽分配，这样该主节点才可以存储数据

查看集群中槽占用情况：

cluster nodes

redis 集群有16384个槽，集群中的每个节点分配自己的槽，通过查看集群节点可以看到槽占用情况
给刚添加的 7007 节点分配槽步骤：

第一步：连接上集群（连接集群中任意一个可用节点都行）

./redis-trib.rb reshard 192.168.254.128:7001

第二步：输入要分配的槽数量，例如，输入3000，表示给目标节点分配3000个槽
第三步：输入接收槽的节点id，这里是给7007分配槽，通过节点信息可以看到7007节点的id为：d2e5beb0d6f0d1293d716f63a39f56a3fb37c586
第四步：输入源节点id，槽将从源节点中拿，分配后的槽在源节点中就不存在了，输入all表示从源节点中获取槽，输入done表示取消分配。
第五步：输入 yes 开始移动槽到目标节点 id
查看节点信息

添加从节点

添加新节点7008，并启动之
启动7008
添加7008从节点，将7008作为7007的从节点
命令：

./redis-trib.rb add-node --slave --master-id 主节点id 新节点ip和端口 旧节点ip和端口（集群中任意节点都可以）

在这里插入图片描述
d2e5beb0d6f0d1293d716f63a39f56a3fb37c586是7007节点的id，可以通过cluster nodes 查看
注意：如果原来该节点在集群中的配置信息已经生成到 cluster-config-file 指定的配置文件中，这时可能会报错：

解决办法是删除生成的配置文件 nodes.conf，删除后执行 ./redis-trib.rb add-node 命令

查看集群中的节点，刚添加的7008为7007的从节点

删除节点

命令

./redis-trib.rb del-node 127.0.0.1:7005 b1b05dfdde75b62cec776f822c571beaddec64f0

在这里插入图片描述

删除已经占有hash槽的节点会失败，报错如下
需要将该节点占用的 hash 槽分配出去

讲文明的喜羊羊拒绝pua

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
打赏
0
评论
JavaEE 企业级分布式高级架构师（五）Redis学习笔记（4）

Redis学习笔记集群篇Redis主从复制什么是主从复制主从配置主Redis配置从Redis配置实现原理全量同步增量同步Redis哨兵机制(难点,面试)简介Redis Sentinel工作原理分析哨兵(sentinel)机制的高可用哨兵的定时监控故障判定原理分析哨兵Leader的选举流程自动故障转移机制哨兵进程的作用哨兵配置推荐配置Redis集群演变主从复制Replication+Sentinel 高可用工作原理缺陷常用方案内网DNSVIP封装客户端直连Redis Sentinel 端口Proxy+Repl
复制链接

扫一扫