热门标签 | HotTags
当前位置:  开发笔记 > 编程语言 > 正文

Redis3–集群

文章




文章目录





    • 一. 主从复制



      • 1. 概念

      • 2. 作用

      • 3. 工作流程

      • 4. 常见问题



    • 二. 哨兵



      • 1. 架构搭建

      • 2. 原理简析



    • 三. 集群



      • 1. 存储设计

      • 2. 搭建集群

      • 3. 数据存储



    • 四. 常见问题



      • 1. 缓存预热

      • 2. 缓存雪崩

      • 3. 缓存击穿

      • 4. 缓存穿透







一. 主从复制


1. 概念

采用多台服务器连接的方案,避免单台服务器宕机导致服务不可用问题。
master(主节点):写,收集数据;
slave (从节点):读,提供数据(写数据禁止);
需要解决的问题:数据同步,需要将master中的数据复制到slave中。

在这里插入图片描述


2. 作用



  1. 实现读写分离,提高服务器读写负载能力;

  2. 负载均衡,基于主从结构,配合读写分离,由slave分担master负载,提高redis服务器并发量与数据吞吐量;

  3. 故障恢复,当master出问题,由某一个slave提供服务,当slave出现问题,还有其他的slave;

  4. 数据冗余,实现数据热备份,是持久化之外的数据冗余方式;

  5. 高可用:基于主从复制,构建哨兵模式与集群,实现redis的高可用方案。


3. 工作流程

1. 建立连接;(slave连接master)
在这里插入图片描述
a. 命令行连接

## 在从节点执行,连接主节点
slaveof masterip masterport

b. 配置文件连接

## 在从节点的配置文件中,进行下面的配置
slaveof masterip masterport

2. 数据同步;master同步slave,包括全量复制 + 部分复制两个部分。

全量复制通过 RDB 进行全量复制后同步,部分复制是将 bgsave 过程中存入复制缓冲区的指令同步给从节点。
在这里插入图片描述

在从节点连接上主节点后,数据同步过程会自动执行。

注意,当master数据量很大,bgsave 占用时间过长,导致复制缓冲区指令溢出,则最先存入复制缓冲区的指令将会丢失,后续进行部分复制时发现数据丢失,则redis会重新进行全量复制,导致服务器陷入死循环。因此数据同步尽量避开流量高峰期。

复制缓冲区大小设置:

repl-backlog-size 1mb

3. 命令传播

数据同步之后,后续是通过命令传播来保证数据一致性的。命令传播阶段也可能出现全部复制或部分复制,如网络中断导致数据长时间未同步。

master 接收写指令后,会将指令以字节的形式存储在复制缓冲区(FIFO队列)中,复制缓冲区由偏移量(offset) + 字节值组成,通过offset区分不同slave的数据传播差异。master 记录当前缓冲区的 offset,slave 记录自己接收到数据的 offset。
在这里插入图片描述
数据同步 + 命令传播 详细版:
在这里插入图片描述
心跳机制:
进入命令传播阶段,master 与 slave 需要进行信息交换,使用心跳机制进行维护,实现双方连接保持在线。
master 心跳:ping 指令,用于判断 slave是否在线;
slave 心跳:replconf ack (offset),汇报自己的 offset,并获取最新的同步数据;同时判断 master 是否在线。
在这里插入图片描述


4. 常见问题



  1. 频繁的全量复制
    缓冲区过小,导致经常进行全量复制,可修改复制缓冲区大小;



  2. 频繁的网络中断
    a. master CPU过高,或者 slave 频繁下线。
    slave 接收到了大量慢查询,如 keys,master 发送心跳时 slave 无响应,导致 master 频繁发送连接请求,CPU占用过高。可设置合理的超时时间(repli-timeout),确认是否释放 slave。
    b. slave 与 master 连接断开
    master 发送 ping 指令频度较低,master 设置的超时时长过短,ping指令存在丢包等。



  3. 数据不一致
    多个 slave 数据不同步。可能是网络信息不同步,导致数据发送有延时。
    可优化主从间的网络环境,监控主从节点延时(查看offset)。




二. 哨兵


1. 架构搭建

哨兵是一个分布式系统,用来监控 master 的运行情况,并在 master 宕机以后选择一个 slave 作为 master。哨兵也是一台 redis 服务器,只是不对外提供数据服务。哨兵配置数量为通常为单数,保证投票时不会打平。

创建哨兵的配置文件:

port 26379
dir /tmp
# 表示监控的主节点,2 表示如果有2个哨兵认为主节点宕机则判定为宕机
sentinel monitor mymaster 127.0.0.1 6379 2
# 监控时发现宕机 30s 则被判定为宕机,需要投票选择新的主节点
sentinel down-after-milliseconds mymaster 30000
# 数据同步的线程数
sentinel parallel-syncs mymaster 1
# 超过 180s 算同步超时
sentinel failover-timeout mymaster 180000

分别启动1 个 master、2 个 slave、1 个 sentinel,然后将 master 关闭,日志打印情况如下。可以看到哨兵监测到 master 宕机以后选择了 slave 6381 作为master,并完成了master 与 slave 之间的连接和同步。重新启动 6379 以后,该节点变成了 slave。

master 6379:
在这里插入图片描述
slave 6380 :
在这里插入图片描述
slave 6381:
在这里插入图片描述
sentinel 26379:
在这里插入图片描述
重新启动 6379:
在这里插入图片描述


2. 原理简析



  1. 监控阶段
    哨兵启动后会向 master、slave 获取状态信息,并同步给其他哨兵。



  2. 通知阶段
    哨兵不断向 master、slave 发送心跳确认节点健康状态,收到正常状态返回后同步给其他哨兵。



  3. 故障转移阶段





  • 当 master 宕机以后,sentinel 通知其他 sentinel master 已宕机,当超过半数的 sentinel 都认为 master 宕机后,sentinel 之间会竞选并最后票选出一个哨兵进行故障转移处置。

  • sentinel 从服务器列表中寻找节点,排除不在线、响应慢、与 master 断开时间久的,再按照优先原则(比如 offset 小的、runid 小的)选择某个节点作为新的 master。

  • 之后 sentinel 向新的 master 发送 slave of no one 指令,向其他 slave 发送 slave of 新 IP 端口。


三. 集群

作用:分散单台服务器的访问及存储压力,并降低宕机带来的业务风险。
方式:将各个 master 相连,对外呈现出单机的效果。


1. 存储设计

集群的每个master都会被分配一段槽编号,数据存储时通过算法设计,将要存储的 key 计算出一个槽值,再放入对应的 master(类似于数据库分库分表操作)。每台 redis 服务器都会存储自己的槽编号以及其他服务器的槽编号,根据此编号进行数据存储。


2. 搭建集群

配置三套一主一从建立集群,端口分别为主(从)—— 6379(6382)、6380(6383)、6381(6384)。

1. 集群配置

redis-6379.conf 配置文件中添加以下配置,然后复制成6份:

cluster-enabled yes #开启集群模式。标识该节点是集群的一部分
cluster-config-file node-6379.conf #指定配置文件名
cluster-node-timeout 10000 #节点连接超时多久被认为断线

查看启动情况:

在这里插入图片描述

2. 集群连接

redis 5.0.0 以上版本使用 redis-cli 进行集群连接(以下版本使用 redis-trib.rb 太难装了)。其中 –cluster-replicas 1 表示集群连接是一拖一模式,即一个主节点带一个从节点,create 后面则是所有要互连的主从节点IP端口,前半部分是主节点,后半部分是从节点:

redis-cli --cluster create 127.0.0.1:6379 127.0.0.1:6380 127.0.0.1:6381 127.0.0.1:6382 127.0.0.1:6383 127.0.0.1:6384 --cluster-replicas 1

在这里插入图片描述
执行完以后可以看到 logs 文件夹下已经自动生成了 node-6379.conf 配置文件。集群模式下,主节点下线,从节点将在连接超时后自动晋级为主节点,后续主节点上线后,将重新变成从节点。


3. 数据存储

集群模式下,需要使用 redis-cli -c 参数,否则,如果key hash 后计算出的槽值不属于当前连接的主节点,将无法set,-c 之后将会自动重定向到对应的主节点:
在这里插入图片描述


四. 常见问题


1. 缓存预热

在 redis 作为数据库缓存的情况下,当 redis 刚启动时,由于 redis 中没有数据,如果此时请求量较大,容易对数据库造成压力。
缓存预热就是将一些高频访问的数据提前加载到 redis 中,避免大量请求同时访问数据库。实际操作过程可以使用脚本导入。


2. 缓存雪崩

缓存雪崩是指系统在运行过程中短时间内出现大量过期 key,redis 无数据向数据库获取数据,从而对数据库造成压力。数据库无法及时响应,从而 redis 请求堆积,数据库请求激增而崩溃,接着 redis 崩溃,应用服务器崩溃。重启无法解决上述问题,因为雪崩的本质是由于 redis 中无缓存数据可用,必须从数据库获取。

解决方式:



  • 构造多级缓存(Nginx + redis + ehcache);

  • 错开 key 的过期时间,比如设置过期时间为某个时间 + 随机数;

  • 监控 key 的访问量,刷新过期时间;

  • 超热数据使用永久 key;

  • 加锁限流(不推荐)或其他限流方式。


3. 缓存击穿

与缓存雪崩不同的是,缓存击穿是指某个时刻单个高热 key 过期,导致大量请求同时访问数据库中的同一数据,从而对数据库造成压力。

解决方式与雪崩类似:



  • 预先错开高峰期的高热 key 过期;

  • 监控 key 的访问量,刷新过期时间;

  • 多级缓存设置不同的 key 过期时间;

  • 加锁限流(不推荐)或其他限流方式。


4. 缓存穿透

缓存穿透通常是短时间内出现大量未命中 key,而这些数据在数据库中也不存在。由于获取不到值这些 key 访问之后也不会存储在 redis 中,下次请求时还将继续请求数据库,导致数据库崩溃。

解决方式:



  • 将未获取到的值以 null 的形式存储,可解决单一错误 key 的访问攻击;

  • 设置数据白名单,正常数据放行,错误数据拒绝;(比如bitmaps、布隆过滤器,加在 redis 与数据库中间);

  • 监控未命中率,使用黑名单防控;

  • 对 key 值加密,不符合加密规则的 key 直接过滤(在 redis 前处理)。



推荐阅读
  • 在过去,我曾使用过自建MySQL服务器中的MyISAM和InnoDB存储引擎(也曾尝试过Memory引擎)。今年初,我开始转向阿里云的关系型数据库服务,并深入研究了其高效的压缩存储引擎TokuDB。TokuDB在数据压缩和处理大规模数据集方面表现出色,显著提升了存储效率和查询性能。通过实际应用,我发现TokuDB不仅能够有效减少存储成本,还能显著提高数据处理速度,特别适用于高并发和大数据量的场景。 ... [详细]
  • 揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节
    揭秘腾讯云CynosDB计算层设计优化背后的不为人知的故事与技术细节 ... [详细]
  • 从无到有,构建个人专属的操作系统解决方案
    操作系统(OS)被誉为程序员的三大浪漫之一,常被比喻为计算机的灵魂、大脑、内核和基石,其重要性不言而喻。本文将详细介绍如何从零开始构建个人专属的操作系统解决方案,涵盖从需求分析到系统设计、开发与测试的全过程,帮助读者深入理解操作系统的本质与实现方法。 ... [详细]
  • Spring框架的核心组件与架构解析 ... [详细]
  • Redis 主从复制机制详解及其工作原理
    主从复制机制在 Redis 中具有重要作用,能够实现读写分离、提升系统性能并提供快速的灾难恢复能力。具体实现方面,以一主两从的架构为例,需要创建三个独立的配置文件(.conf),分别用于主节点和两个从节点的设置。通过这种方式,可以从主节点同步数据到从节点,确保数据的一致性和高可用性。此外,还可以利用从节点进行读操作,减轻主节点的压力,进一步提高系统的整体性能。 ... [详细]
  • 为了向用户提供虚拟应用程序,通常会在基础架构中部署StoreFront或Web Interface。为了确保安全的远程访问,通常需要在DMZ中配置Secure Gateway或Access Gateway。本文详细对比了这两种界面工具的功能特性,包括用户管理、安全性、性能优化等方面,为企业选择合适的解决方案提供了全面的参考。 ... [详细]
  • 在项目开发过程中,掌握一些关键的Linux命令至关重要。例如,使用 `Ctrl+C` 可以立即终止当前正在执行的命令;通过 `ps -ef | grep ias` 可以查看特定服务的进程信息,包括进程ID(PID)和JVM参数(如内存分配和远程连接端口);而 `netstat -apn | more` 则用于显示网络连接状态,帮助开发者监控和调试网络服务。这些命令不仅提高了开发效率,还能有效解决运行时的各种问题。 ... [详细]
  • 如果程序使用Go语言编写并涉及单向或双向TLS认证,可能会遭受CPU拒绝服务攻击(DoS)。本文深入分析了CVE-2018-16875漏洞,探讨其成因、影响及防范措施,为开发者提供全面的安全指导。 ... [详细]
  • 基于域名、端口和IP的虚拟主机构建方案
    本文探讨了在单台物理服务器上构建多个Web站点的虚拟主机方案,详细介绍了三种主要的虚拟主机类型:基于域名、基于IP地址和基于端口的虚拟主机。每种类型的实现方式及其优缺点均进行了深入分析,为实际应用提供了全面的技术指导。 ... [详细]
  • 本文详细探讨了MySQL并发参数的优化与调整方法,旨在帮助读者深入了解如何通过合理配置这些参数来提升数据库性能。文章不仅介绍了常见的并发参数及其作用,还提供了实际操作中的调整策略和最佳实践,适合希望提高数据库管理技能的技术人员阅读。 ... [详细]
  • 机顶盒,即数字电视机顶盒(Digital TV Set-Top Box,简称STB),是一种放置在电视机旁的设备。它主要用于将数字信号转换为电视能够识别的模拟信号,从而实现高质量的视频和音频播放。机顶盒不仅支持基本的电视节目接收功能,还具备多种增值服务,如互动点播、网络浏览等。随着技术的发展,现代机顶盒集成了更多的智能功能,成为家庭娱乐的重要组成部分。 ... [详细]
  • 【并发编程】全面解析 Java 内存模型,一篇文章带你彻底掌握
    本文深入解析了 Java 内存模型(JMM),从基础概念到高级特性进行全面讲解,帮助读者彻底掌握 JMM 的核心原理和应用技巧。通过详细分析内存可见性、原子性和有序性等问题,结合实际代码示例,使开发者能够更好地理解和优化多线程并发程序。 ... [详细]
  • 我正在使用 Ruby on Rails 构建个人网站。总体而言,RoR 是一个非常出色的工具,它提供了丰富的功能和灵活性,使得创建自定义页面变得既高效又便捷。通过利用其强大的框架和模块化设计,我可以轻松实现复杂的功能,同时保持代码的整洁和可维护性。此外,Rails 的社区支持也非常强大,为开发过程中遇到的问题提供了丰富的资源和解决方案。 ... [详细]
  • 如何在Oracle ASM_Diskgroup中重命名现有磁盘
    如何在Oracle ASM_Diskgroup中重命名现有磁盘 ... [详细]
  • 深入解析 Django 中用户模型的自定义方法与技巧 ... [详细]
author-avatar
默然b并不是我的选择
这个家伙很懒,什么也没留下!
PHP1.CN | 中国最专业的PHP中文社区 | DevBox开发工具箱 | json解析格式化 |PHP资讯 | PHP教程 | 数据库技术 | 服务器技术 | 前端开发技术 | PHP框架 | 开发工具 | 在线工具
Copyright © 1998 - 2020 PHP1.CN. All Rights Reserved | 京公网安备 11010802041100号 | 京ICP备19059560号-4 | PHP1.CN 第一PHP社区 版权所有