网站推广开户,湖南网站推,wordpress与微信连接,南京市高淳区住房与城乡建设局网站Redis保证高可用主要有三种方式#xff1a;主从、哨兵、集群。
主从复制了解吗#xff1f; Redis主从复制简图
主从复制#xff0c;是指将一台 Redis 服务器的数据#xff0c;复制到其他的 Redis 服务器。前者称为 主节点(master)#xff0c;后者称为 从节点(slave)。且…Redis保证高可用主要有三种方式主从、哨兵、集群。
主从复制了解吗 Redis主从复制简图
主从复制是指将一台 Redis 服务器的数据复制到其他的 Redis 服务器。前者称为 主节点(master)后者称为 从节点(slave)。且数据的复制是 单向 的只能由主节点到从节点。Redis 主从复制支持 主从同步 和 从从同步 两种后者是 Redis 后续版本新增的功能以减轻主节点的同步负担。 主从复制主要的作用? 数据冗余 主从复制实现了数据的热备份是持久化之外的一种数据冗余方式。故障恢复 当主节点出现问题时可以由从节点提供服务实现快速的故障恢复 (实际上是一种服务的冗余)。负载均衡 在主从复制的基础上配合读写分离可以由主节点提供写服务由从节点提供读服务 即写 Redis 数据时应用连接主节点读 Redis 数据时应用连接从节点分担服务器负载。尤其是在写少读多的场景下通过多个从节点分担读负载可以大大提高 Redis 服务器的并发量。高可用基石 除了上述作用以外主从复制还是哨兵和集群能够实施的 基础因此说主从复制是 Redis 高可用的基础。
Redis主从有几种常见的拓扑结构
Redis的复制拓扑结构可以支持单层或多层复制关系根据拓扑复杂性可以分为以下三种一主一从、一主多从、树状主从结构。
1.一主一从结构
一主一从结构是最简单的复制拓扑结构用于主节点出现宕机时从节点提供故障转移支持。 2.一主多从结构
一主多从结构又称为星形拓扑结构使得应用端可以利用多个从节点实现读写分离见图6-5。对于读占比较大的场景可以把读命令发送到从节点来分担主节点压力。 3.树状主从结构
树状主从结构又称为树状拓扑结构使得从节点不但可以复制主节点数据同时可以作为其他从节点的主节点继续向下层复制。通过引入复制中间层可以有效降低主节点负载和需要传送给从节点的数据量。
Redis的主从复制原理了解吗
Redis主从复制的工作流程大概可以分为如下几步
保存主节点master信息 这一步只是保存主节点信息保存主节点的ip和port。主从建立连接 从节点slave发现新的主节点后会尝试和主节点建立网络连接。发送ping命令 连接建立成功后从节点发送ping请求进行首次通信主要是检测主从之间网络套接字是否可用、主节点当前是否可接受处理命令。权限验证 如果主节点要求密码验证从节点必须正确的密码才能通过验证。同步数据集 主从复制连接正常通信后主节点会把持有的数据全部发送给从节点。命令持续复制 接下来主节点会持续地把写命令发送给从节点保证主从数据一致性。
说说主从数据同步的方式
Redis在2.8及以上版本使用psync命令完成主从数据同步同步过程分为全量复制和部分复制。 主从数据同步方式
全量复制 一般用于初次复制场景Redis早期支持的复制功能只有全量复制它会把主节点全部数据一次性发送给从节点当数据量较大时会对主从节点和网络造成很大的开销。
全量复制的完整运行流程如下
发送psync命令进行数据同步由于是第一次进行复制从节点没有复制偏移量和主节点的运行ID所以发送psync-1。主节点根据psync-1解析出当前为全量复制回复FULLRESYNC响应。从节点接收主节点的响应数据保存运行ID和偏移量offset主节点执行bgsave保存RDB文件到本地主节点发送RDB文件给从节点从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件对于从节点开始接收RDB快照到接收完成期间主节点仍然响应读写命令因此主节点会把这期间写命令数据保存在复制客户端缓冲区内当从节点加载完RDB文件后主节点再把缓冲区内的数据发送给从节点保证主从之间数据一致性。从节点接收完主节点传送来的全部数据后会清空自身旧数据从节点清空数据后开始加载RDB文件从节点成功加载完RDB后如果当前节点开启了AOF持久化功能 它会立刻做bgrewriteaof操作为了保证全量复制后AOF持久化文件立刻可用。
部分复制 部分复制主要是Redis针对全量复制的过高开销做出的一种优化措施 使用psync{runId}{offset}命令实现。当从节点slave正在复制主节点 master时如果出现网络闪断或者命令丢失等异常情况时从节点会向 主节点要求补发丢失的命令数据如果主节点的复制积压缓冲区内存在这部分数据则直接发送给从节点这样就可以保持主从节点复制的一致性。
当主从节点之间网络出现中断时如果超过repl-timeout时间主节点会认为从节点故障并中断复制连接主从连接中断期间主节点依然响应命令但因复制连接中断命令无法发送给从节点不过主节点内部存在的复制积压缓冲区依然可以保存最近一段时间的写命令数据默认最大缓存1MB。当主从节点网络恢复后从节点会再次连上主节点当主从连接恢复后由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当作psync参数发送给主节点要求进行部分复制操作。主节点接到psync命令后首先核对参数runId是否与自身一致如果一 致说明之前复制的是当前主节点之后根据参数offset在自身复制积压缓冲区查找如果偏移量之后的数据存在缓冲区中则对从节点发送CONTINUE响应表示可以进行部分复制。主节点根据偏移量把复制积压缓冲区里的数据发送给从节点保证主从复制进入正常状态。
主从复制存在哪些问题呢
主从复制虽好但也存在一些问题
一旦主节点出现故障需要手动将一个从节点晋升为主节点同时需要修改应用方的主节点地址还需要命令其他从节点去复制新的主节点整个过程都需要人工干预。主节点的写能力受到单机的限制。主节点的存储能力受到单机的限制。
第一个问题是Redis的高可用问题第二、三个问题属于Redis的分布式问题。
Redis Sentinel哨兵了解吗
主从复制存在一个问题没法完成自动故障转移。所以我们需要一个方案来完成自动故障转移它就是Redis Sentinel哨兵。 Redis Sentinel
Redis Sentinel 它由两部分组成哨兵节点和数据节点
哨兵节点 哨兵系统由一个或多个哨兵节点组成哨兵节点是特殊的 Redis 节点不存储数据对数据节点进行监控。数据节点 主节点和从节点都是数据节点
在复制的基础上哨兵实现了 自动化的故障恢复 功能下面是官方对于哨兵功能的描述
监控Monitoring 哨兵会不断地检查主节点和从节点是否运作正常。自动故障转移Automatic failover 当 主节点 不能正常工作时哨兵会开始 自动故障转移操作它会将失效主节点的其中一个 从节点升级为新的主节点并让其他从节点改为复制新的主节点。配置提供者Configuration provider 客户端在初始化时通过连接哨兵来获得当前 Redis 服务的主节点地址。通知Notification 哨兵可以将故障转移的结果发送给客户端。
其中监控和自动故障转移功能使得哨兵可以及时发现主节点故障并完成转移。而配置提供者和通知功能则需要在与客户端的交互中才能体现。
Redis Sentinel哨兵实现原理知道吗
哨兵模式是通过哨兵节点完成对数据节点的监控、下线、故障转移。 定时监控 Redis Sentinel通过三个定时监控任务完成对各个节点发现和监控 每隔10秒每个Sentinel节点会向主节点和从节点发送info命令获取最新的拓扑结构每隔2秒每个Sentinel节点会向Redis数据节点的__sentinel__hello 频道上发送该Sentinel节点对于主节点的判断以及当前Sentinel节点的信息每隔1秒每个Sentinel节点会向主节点、从节点、其余Sentinel节点发送一条ping命令做一次心跳检测来确认这些节点当前是否可达主观下线和客观下线 主观下线就是哨兵节点认为某个节点有问题客观下线就是超过一定数量的哨兵节点认为主节点有问题。 主观下线 每个Sentinel节点会每隔1秒对主节点、从节点、其他Sentinel节点发送ping命令做心跳检测当这些节点超过 down-after-milliseconds没有进行有效回复Sentinel节点就会对该节点做失败判定这个行为叫做主观下线。 客观下线 当Sentinel主观下线的节点是主节点时该Sentinel节点会通过sentinel is- master-down-by-addr命令向其他Sentinel节点询问对主节点的判断当超过 quorum个数Sentinel节点认为主节点确实有问题这时该Sentinel节点会做出客观下线的决定 领导者Sentinel节点选举 Sentinel节点之间会做一个领导者选举的工作选出一个Sentinel节点作为领导者进行故障转移的工作。Redis使用了Raft算法实现领导者选举。 故障转移 领导者选举出的Sentinel节点负责故障转移过程如下 在从节点列表中选出一个节点作为新的主节点这一步是相对复杂一些的一步Sentinel领导者节点会对第一步选出来的从节点执行slaveof no one命令让其成为主节点Sentinel领导者节点会向剩余的从节点发送命令让它们成为新主节点的从节点Sentinel节点集合会将原来的主节点更新为从节点并保持着对其关注当其恢复后命令它去复制新的主节点
领导者Sentinel节点选举了解吗
Redis使用了Raft算法实 现领导者选举大致流程如下 每个在线的Sentinel节点都有资格成为领导者当它确认主节点主观 下线时候会向其他Sentinel节点发送sentinel is-master-down-by-addr命令 要求将自己设置为领导者。收到命令的Sentinel节点如果没有同意过其他Sentinel节点的sentinel is-master-down-by-addr命令将同意该请求否则拒绝。如果该Sentinel节点发现自己的票数已经大于等于maxquorum numsentinels/21那么它将成为领导者。如果此过程没有选举出领导者将进入下一次选举。
新的主节点是怎样被挑选出来的
选出新的主节点大概分为这么几步 过滤“不健康”主观下线、断线、5秒内没有回复过Sentinel节 点ping响应、与主节点失联超过down-after-milliseconds*10秒。选择slave-priority从节点优先级最高的从节点列表如果存在则返回不存在则继续。选择复制偏移量最大的从节点复制的最完整如果存在则返 回不存在则继续。选择runid最小的从节点。
Redis 集群了解吗
前面说到了主从存在高可用和分布式的问题哨兵解决了高可用的问题而集群就是终极方案一举解决高可用和分布式问题。 数据分区 数据分区 (或称数据分片) 是集群最核心的功能。集群将数据分散到多个节点一方面 突破了 Redis 单机内存大小的限制存储容量大大增加另一方面 每个主节点都可以对外提供读服务和写服务大大提高了集群的响应能力。 高可用 集群支持主从复制和主节点的 自动故障转移 与哨兵类似当任一节点发生故障时集群仍然可以对外提供服务。
集群中数据如何分区
分布式的存储中要把数据集按照分区规则映射到多个节点常见的数据分区规则三种 方案一节点取余分区
节点取余分区非常好理解使用特定的数据比如Redis的键或者用户ID之类对响应的hash值取余hashkey%N来确定数据映射到哪一个节点上。
不过该方案最大的问题是当节点数量变化时如扩容或收缩节点数据节点映射关 系需要重新计算会导致数据的重新迁移。 节点取余分区
方案二一致性哈希分区
将整个 Hash 值空间组织成一个虚拟的圆环然后将缓存节点的 IP 地址或者主机名做 Hash 取值后放置在这个圆环上。当我们需要确定某一个 Key 需 要存取到哪个节点上的时候先对这个 Key 做同样的 Hash 取值确定在环上的位置然后按照顺时针方向在环上“行走”遇到的第一个缓存节点就是要访问的节点。
比如说下面 这张图里面Key 1 和 Key 2 会落入到 Node 1 中Key 3、Key 4 会落入到 Node 2 中Key 5 落入到 Node 3 中Key 6 落入到 Node 4 中。 这种方式相比节点取余最大的好处在于加入和删除节点只影响哈希环中 相邻的节点对其他节点无影响。
但它还是存在问题
缓存节点在圆环上分布不平均会造成部分缓存节点的压力较大当某个节点故障时这个节点所要承担的所有访问都会被顺移到另一个节点上会对后面这个节点造成力。
方案三虚拟槽分区
这个方案 一致性哈希分区的基础上引入了 虚拟节点 的概念。Redis 集群使用的便是该方案其中的虚拟节点称为 槽slot。槽是介于数据和实际节点之间的虚拟概念每个实际节点包含一定数量的槽每个槽包含哈希值在一定范围内的数据。 在使用了槽的一致性哈希分区中槽是数据管理和迁移的基本单位。槽解耦了数据和实际节点 之间的关系增加或删除节点对系统的影响很小。仍以上图为例系统中有 4 个实际节点假设为其分配 16 个槽(0-15)
槽 0-3 位于 node14-7 位于 node2以此类推....
如果此时删除 node2只需要将槽 4-7 重新分配即可例如槽 4-5 分配给 node1槽 6 分配给 node3槽 7 分配给 node4数据在其他节点的分布仍然较为均衡。
能说说Redis集群的原理吗
Redis集群通过数据分区来实现数据的分布式存储通过自动故障转移实现高可用。
集群创建
数据分区是在集群创建的时候完成的。 设置节点 Redis集群一般由多个节点组成节点数量至少为6个才能保证组成完整高可用的集群。每个节点需要开启配置cluster-enabled yes让Redis运行在集群模式下。 节点握手 节点握手是指一批运行在集群模式下的节点通过Gossip协议彼此通信 达到感知对方的过程。节点握手是集群彼此通信的第一步由客户端发起命 令cluster meet{ip}{port}。完成节点握手之后一个个的Redis节点就组成了一个多节点的集群。
分配槽slot Redis集群把所有的数据映射到16384个槽中。每个节点对应若干个槽只有当节点分配了槽才能响应和这些槽关联的键命令。通过 cluster addslots命令为节点分配槽。 分配槽
故障转移
Redis集群的故障转移和哨兵的故障转移类似但是Redis集群中所有的节点都要承担状态维护的任务。
故障发现 Redis集群内节点通过ping/pong消息实现节点通信集群中每个节点都会定期向其他节点发送ping消息接收节点回复pong 消息作为响应。如果在cluster-node-timeout时间内通信一直失败则发送节 点会认为接收节点存在故障把接收节点标记为主观下线pfail状态。 当某个节点判断另一个节点主观下线后相应的节点状态会跟随消息在集群内传播。通过Gossip消息传播集群内节点不断收集到故障节点的下线报告。当 半数以上持有槽的主节点都标记某个节点是主观下线时。触发客观下线流程。 故障恢复
故障节点变为客观下线后如果下线节点是持有槽的主节点则需要在它 的从节点中选出一个替换它从而保证集群的高可用。 故障恢复流程
资格检查 每个从节点都要检查最后与主节点断线时间判断是否有资格替换故障 的主节点。准备选举时间 当从节点符合故障转移资格后更新触发故障选举的时间只有到达该 时间后才能执行后续流程。发起选举 当从节点定时任务检测到达故障选举时间failover_auth_time到达后发起选举流程。选举投票 持有槽的主节点处理故障选举消息。投票过程其实是一个领导者选举的过程如集群内有N个持有槽的主节 点代表有N张选票。由于在每个配置纪元内持有槽的主节点只能投票给一个 从节点因此只能有一个从节点获得N/21的选票保证能够找出唯一的从节点。 替换主节点 当从节点收集到足够的选票之后触发替换主节点操作。 部署Redis集群至少需要几个物理节点 在投票选举的环节故障主节点也算在投票数内假设集群内节点规模是3主3从其中有2 个主节点部署在一台机器上当这台机器宕机时由于从节点无法收集到 3/21个主节点选票将导致故障转移失败。这个问题也适用于故障发现环节。因此部署集群时所有主节点最少需要部署在3台物理机上才能避免单点问题。
说说集群的伸缩
Redis集群提供了灵活的节点扩容和收缩方案可以在不影响集群对外服务的情况下为集群添加节点进行扩容也可以下线部分节点进行缩容。 其实集群扩容和缩容的关键点就在于槽和节点的对应关系扩容和缩容就是将一部分槽和数据迁移给新节点。
例如下面一个集群每个节点对应若干个槽每个槽对应一定的数据如果希望加入1个节点希望实现集群扩容时需要通过相关命令把一部分槽和内容迁移给新节点。 缩容也是类似先把槽和数据迁移到其它节点再把对应的节点下线。
