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

最新推荐文章于 2020-08-28 00:15:45 发布
最新推荐文章于 2020-08-28 00:15:45 发布
阅读量281 收藏
点赞数
分类专栏： Redis 文章标签： Redis主从复制 Redis哨兵机制 Redis集群演变
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/yangwei234/article/details/108271034
版权

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
推荐配置

推荐的sentinel 集群是1主2从3哨兵

  • 如果有一个sentinel：实际情况，其实单纯从代码的情况，其实1个Sentinel就能完成主观下线(sdown，SubjectivelyDown)，客观下线(odown, Objectively Down) 的判断，自动发现 Sentinel 和从服务器，并且完成故障转移。
  • 如果有2个sentinel：如果哨兵集群仅仅部署了个2个哨兵实例，quorum=1。s1和s2中只要有1个哨兵认为master宕机就可以还行切换，同时s1和s2中会选举出一个哨兵来执行故障转移。同时这个时候，需要majority，也就是大多数哨兵都是运行的，2个哨兵的majority就是2(2的majority=2，3的majority=2，5的majority=3，4的majority=3)，如果一个节点挂了那么哨兵也就挂了，哨兵只剩下一个，那么就无法完成故障转移。
    在这里插入图片描述
  • 如果是经典的3节点哨兵集群：Configuration: quorum = 2。majority=2(majority不能配置，由redis自行计算所得。)如果M1所在机器宕机了，那么三个哨兵还剩下2个，S2和S3可以一致认为master宕机，然后选举出一个来执行故障转移。同时3个哨兵的majority是2，所以还剩下的2个哨兵运行着，就可以允许执行故障转移。这就是经典的sentinel3个节点的集群。节省资源的同时又满足了高可用。
    在这里插入图片描述

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企业级分布式高级架构师视频-全套（18年11月）
11-22
Mybatis Spring 分布式和 mysql 集群 redis mongodb zookeeper dubbo
JavaEE系统架构师学习路线之高级篇
11-27
这是一套JavaEE系统架构师学习路线之高级教程，由本站工作了10年的资深Java架构师整理。
JavaEE 企业级分布式高级架构师（五）Redis学习笔记（3）
yangwei2048的博客
08-24 553
Redis学习笔记进阶篇缓存通识无处不在的缓存缓存数据存储(hash表)缓存的关键指标影响缓存命中率的主要指标缓存键集合大小缓存可使用内存空间缓存对象生存时间缓存类型代理缓存反向代理缓存多层反向代理缓存内容分发网络(CDN - Content Distribution Network)CDN同时配置静态文件和动态内容通读缓存(Read-Through)旁路缓存(Cache-Aside)浏览器缓存本地对象缓存远程分布式对象缓存各种介质数据访问延迟技术栈各个层次的缓存缓存为什么能显著提升性能缓存时系统性能优化的
JavaEE 企业级分布式高级架构师（五）Redis学习笔记（5）
yangwei2048的博客
08-28 209
Redis学习笔记Java测试redis连通性Jedis连接集群代码实现使用 Spring Java测试redis连通性 添加依赖 <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>3.0.1</version> </dependency> 开放linux
JavaEE 企业级分布式高级架构师（五）Redis学习笔记（6）
yangwei2048的博客
08-04 232
Redis学习笔记高级篇Redis主从复制什么是主从复制主从配置主Redis配置从Redis配置实现原理全量同步增量同步Redis哨兵机制简介哨兵进程的作用故障判定原理分析案例演示Redis集群Redis集群策略Redis-cluster架构图Redis-cluster投票：容错安装Ruby环境安装RedisCluster命令客户端连接集群查看集群的命令维护节点添加主节点hash槽重新分配（数据迁...
JavaEE 企业级分布式高级架构师（五）Redis学习笔记（2）
yangwei2048的博客
08-27 487
Redis学习笔记基础篇Redis数据类型key的设计技巧string类型常用命令赋值取值取值并赋值数值增减递增数字增加指定的整数递减数值减少指定的整数仅当不存在时赋值其他命令向尾部追加值获取字符串长度同时设置/获取多个键值应用场景之自增主键hash类型hash类型介绍常用命令赋值设置一个字段值设置多个字段值当字段不存在时赋值取值获取一个字段值获取多个字段值获取所有字段值删除字段增加数字其他命令string类型和hash类型的区别应用之存储商品信息list类型ArrayList和LinkedList的区别l
JavaEE企业级分布式高级架构师018期 94G
04-10
├─第1章 mybatis从入门到精通 │ │ 第一章第1节： 02-mybatis介绍.mp4 │ │ 第一章第1节： 03-mybatis入门.mp4 │ │ 第一章第1节： 04-mybatis基础应用之mapper代理开发方式.mp4 │ │ 第一章第1节： ...
JavaEE企业级分布式高级架构师培训.zip
12-13
JavaEE企业级分布式高级架构师培训课程主要涵盖了JavaEE技术栈在大型企业中的高级应用，旨在培养具备深厚理论基础和实战经验的分布式系统架构设计师。这个课程内容广泛且深入，通常包括以下几个核心知识点： 1. **...
企业级JavaEE架构设计精深实践教程pdf+架构师视频资源
01-17
《企业级JavaEE架构设计精深实践教程》是一份全面且深入的学习资料，旨在帮助开发者和潜在的架构师掌握在企业环境中构建高效、可扩展、稳定的JavaEE应用系统的技巧和最佳实践。本教程结合了理论与实践，通过PDF文档...
Java面试整理，涵盖基础、JVM、线程并发、框架、MySQL、微服务、Redis、中间件、数据结构与算法等。陆续完善中.zip
07-31
Java面试整理，涵盖基础、JVM、线程并发、框架、MySQL、微服务、Redis、中间件、数据结构与算法等。陆续完善中
chromedriver-mac-x64_121.0.6167.184.zip
最新发布
07-31
chromedriver-mac-x64_121.0.6167.184.zip
【Java面试+Java技术文章汇总】 涵盖大部分Java程序员所需要掌握的核心知识。.zip
07-31
【Java面试+Java技术文章汇总】 涵盖大部分Java程序员所需要掌握的核心知识。
资源管理的艺术：使用MySQL用户资源配额优化性能
07-31
MySQL是一个流行的开源关系型数据库管理系统（RDBMS），广泛用于Web应用程序的后端数据存储。它基于结构化查询语言（SQL）来管理数据，并且是LAMP（Linux, Apache, MySQL, PHP/Python/Perl）技术栈的一部分，这个技术栈常用于构建动态网站和Web应用程序。 MySQL的特点包括： - **开放源代码**：MySQL的源代码是公开的，任何人都可以自由使用和修改。 - **跨平台**：MySQL可以在多种操作系统上运行，包括Linux、Windows、macOS等。 - **高性能**：MySQL以其快速的查询处理和良好的性能而闻名。 - **可靠性**：MySQL提供了多种机制来确保数据的完整性和可靠性，包括事务支持、备份和恢复功能。 - **易于使用**：MySQL提供了简单直观的界面和丰富的文档，便于用户学习和使用。 - **可扩展性**：MySQL支持从小型应用到大型企业级应用的扩展。 - **社区支持**：由于其广泛的使用，MySQL拥有一个活跃的开发者社区，提供大量的资源和支持。 MySQL被广泛应用于各种场景，包括在线事务处理（OL
2024版国内外期刊最全信息库（6万多本期刊）(全新整理)
07-31
1、资源内容地址：https://blog.csdn.net/2301_79696294/article/details/140405010 2、代码特点：今年全新，手工精心整理，放心引用，数据来自权威，相对于其他人的控制变量数据准确很多,适合写论文做实证用 ，不会出现数据造假问题 3、适用对象：大学生，本科生，研究生小白可用，容易上手！！！ 3、课程引用: 经济学，地理学，城市规划与城市研究，公共政策与管理，社会学，商业与管理 数据指标说明 【包含主要内容】 学科分类状态 期刊语言微信公众号定价邮发代码 期刊名称 电话出版区域邮箱 影响因子[知网]复合影响因子简介 主管部门 出版地址网址自引率[知网]综合影响因子 主办单位 主编 投稿网址国内统一刊号所属分区 是否TOP编辑部 官网微信号官网国际标准刊号地址 传真微信公号期刊等级邮编 是否OA期/掼賁浙鎳验刊状态 是否综述
chromedriver-mac-x64_120.0.6099.18.zip
07-31
chromedriver-mac-x64_120.0.6099.18.zip
chromedriver-mac-arm64_128.0.6562.0.zip
07-31
chromedriver-mac-arm64_128.0.6562.0.zip
chromedriver-mac-x64_120.0.6080.0.zip
07-31
chromedriver-mac-x64_120.0.6080.0.zip
chromedriver-mac-arm64_126.0.6478.63.zip
07-31
chromedriver-mac-arm64_126.0.6478.63.zip
开课吧-javaee企业级分布式高级架构师
07-29
开课吧-javaEE企业级分布式高级架构师是一门专注于培养企业级应用开发的高级技术课程。该课程旨在帮助学员全面掌握Java EE企业级开发的技能和知识，培养他们成为具备分布式应用系统设计和架构能力的高级架构师。 在这门课程中，学员将学习Java EE的核心概念和技术，包括Servlet、JSP、JDBC、EJB、JNDI等。同时，学员还将深入学习分布式应用开发的相关技术，如Web服务、消息队列、分布式缓存、负载均衡等。除此之外，课程还将涉及如何使用流行的Java EE开发框架（如Spring、Hibernate等）进行企业应用开发，并介绍分布式系统的设计原则和最佳实践。 通过学习这门课程，学员将能够了解分布式应用架构的基本原理，并具备设计和构建分布式应用系统的能力。他们将熟练掌握Java EE平台的各种技术和工具，能够灵活运用它们开发高性能、可扩展性强的企业级应用系统。此外，通过课程中的实战项目，学员还将锻炼解决实际问题和项目管理的能力。 作为一门高级架构师的课程，它将帮助学员进一步提升自己的职业发展。毕业后，学员可以在企业中担任分布式应用的架构师、系统设计师、技术经理等角色，负责企业级应用系统的设计和开发。此外，他们还可以选择独立开发，提供技术咨询和解决方案。 总之，开课吧-javaEE企业级分布式高级架构师是一门非常有价值的课程，它将帮助学员掌握Java EE企业级开发的核心技术和分布式应用架构的设计原理，培养他们成为具备高级架构师能力的软件开发专业人士。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

讲文明的喜羊羊拒绝pua

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值