非法网站怎么推广,服务器 wordpress 邮件,网站怎么做音乐外链,网站群项目建设实施进度计划高可用#xff08;主从复制、哨兵模式、分片集群#xff09; 高可用性Redis如何实现高可用架构#xff1f;主从复制原理1. 全量同步2. 命令传播3. 增量同步 Redis Sentinel#xff08;哨兵模式#xff09;为什么要有哨兵模式#xff1f;哨兵机制是如何工作的#xff1f;… 高可用主从复制、哨兵模式、分片集群 高可用性Redis如何实现高可用架构主从复制原理1. 全量同步2. 命令传播3. 增量同步 Redis Sentinel哨兵模式为什么要有哨兵模式哨兵机制是如何工作的故障检测由哪个哨兵进行主从故障转移主从故障转移的过程是怎样的 集群脑裂导致数据丢失怎么办什么是脑裂解决方案 Redis Cluster(分片集群)为什么需要Redis ClusterRedis Cluster 是如何分⽚的为什么 Redis Cluster 的哈希槽是 16384 个?Redis Cluster中的节点是怎么进行通信的Gossip 协议节点间的数据交换 高可用性
Redis如何实现高可用架构
Redis 官方提供了三种分布式部署模式
主从复制通过 slaveof 命令可以让任意的节点成为对应的节点的从节点主节点通过主从复制机制向从主节点同步数据。其中主节点提供读写功能而从节点只提供读功能。当主节点出现故障时需要手动进行主从切换完成故障转移。Sentinel 哨兵模式哨兵模式是主从的增强版本它在主从模式的基础上添加了哨兵节点哨兵节点通过心跳监控节点健康状态并在主节点出现故障后自动通过投票机制选举出新的主节点并完成故障转移。不过哨兵本身也需要做保证高可用因此一般也会同时部署多个哨兵节点组成哨兵集群。Cluster 集群模式Redis Cluster 一般也叫分片集群它是 Redis 提供的一个去中心化的集群部署方案。它将全部数据划分为 16394 个哈希槽由集群中的每个节点负责其中的一部分槽位使用时 Key 将通过哈希取模并最终指派到某个特定的槽位。在集群中不同的 Redis 节点间通过 Gossip 协议与其他节点保持通信每个主节点都将可以具备多个从节点从节点不提供服务当主节点出现故障时将会自动投票选举出新的主节点并且完成故障转移。
此外在 Redis Cluster 之前也有一些基于中间代理路由或客户端路由的 Redis 的解决方案比如 Jedis 自带的 ShardedJedis或者推特的 Twemproxy。
主从复制
当 Redis 的访问量以及数据量随着随着业务规模一起扩大单机部署的一些问题就逐渐体现出来比如
服务器一旦宕机所有 Redis 服务都不可用。读写请求全打到单个 Redis 实例上会遇到性能瓶颈。
为了解决这些问题Redis 中提供了主从复制replication的机制。简单的来说当我们有多个 Redis 实例时它们会被划分为两类节点
Master 主节点负责处理客户端的读写请求以及数据的修改操作。Slave 从节点通过复制主节点的数据提供备份和读取服务。 也就是说所有的数据修改只在主服务器上进行然后将最新的数据同步给从服务器这样就使得主从服务器的数据是一致的。
原理
当从节点初次连接到主节点或者掉线重连后进度落后较多时会进行一次全量数据同步。此时主节点会生成 RDB 快照并传输给从节点在此期间主节点接受到的增量命令将会先写入 replication_buffer 缓冲区等到从节点加载完 RDB 快照的数据后再将缓冲区的命令传输给从节点以次完成初次同步。
当从节点掉线重连后如果进度落后的不多将会进行增量同步。主节点内部维护了一个环形的固定大小的 repl_backlog_buffer 缓冲区它用于记录最近传播的命令。其中主节点和从节点会分别在该缓冲区维护一个 offset 用于表示自己的写进度和读进度。当从节点掉线重连后将会检查主节点和从节点 offset 之差是否小于缓冲区大小如果确实小于说明从节点同步进度落后不多则主节点将该缓冲区中的两 offset 之间的增量命令发送给从节点完成增量同步。
当主从节点完成初次同步后将会建立长连接进行命令传播。简单的来说就是每当主节点执行一条命令它就会写入 replication_buffer 缓冲区随后再将缓冲区的命令通过节点间的长连接发送给对应的从节点。
1. 全量同步
一般来说当两个节点第一次建立主从关系的时候一定会触发一次全量同步。整个过程大致分为四步
从节点向主节点发送 psync 请求获取 runID 和 offset主节点返回自己的 runID 与该从节点的 offset主节点生成 RDB 文件并传输给从节点从节点加载文件后获取全量数据。主节点确认从节点加载完 RDB 文件后将这期间缓存的增量命令发送给从节点从节点加载完毕后结束第一次同步。 1.获取 runID 与 offset
当我们对一个 Redis 实例使用 replicaof 让指定从节点与主节点构成主从关系时从节点将会根据你指定的 host 和端口号请求对应的服务实例并向主节点发送 psync {runID} {offset} 请求。
其中runID 是主节点启动时生成的标识 ID而 offset 则表示当前从节点从主节点复制数据的偏移量也就是复制进度。最开始的时候由于是第一次同步因此从节点并不知道主节点的 runID因此 runID 为 ?由于也还没有复制过数据因此 offset 为 -1。
当主节点响应请求时将会返回主节点自己的 runID 和当前从节点的复制进度 offset。并且因为是首次同步因此主节点会返回 FULLRESYNC 响应表示从节点需要进行全量同步。
2.加载 RDB 数据
在前文 Redis 的持久化部分我们提到过Redis 恢复数据或者进行主从同步的时候是通过 RDB 文件完成的实际上指的就是全量同步。
在从节点接受了响应以后主节点将会执行 bgsave 去生成一个 RDB 文件——这个流程与正常生成 RDB 文件一致——并发送给从节点从节点接受后由于是全量同步因此会先清空自己的已有数据然后再加载 RDB 文件中的数据。
此时从节点已经同步过来了主节点的大部分数据不过由于 RDB 实际上只是一个快照因此在生成 RDB 文件期间主节点的增量数据实际上还没有被从节点获取。
获取增量数据
在主节点生成 RDB 文件期间由于 RDB 文件是通过子进程异步生成的因此在这个过程中主节点仍然还在正常的处理请求这部分的增量命令将会写入 replication buffer 缓冲区。
当从节点加载完 RDB 中的数据后将会向主节点发送确认消息此时主节点会再将缓冲区中的命令发送给从节点从节点执行完这部分增量命令后数据即与主节点基本一致则全量同步完成。
不过由于主从的更新已有延迟因此无论如何数据是很难保证完全一致的不过这就是后面命令的正常传播和增量同步的事情了。
2. 命令传播
当主从之间根据 psync 请求完成第一次全量或增量同步后就会保持长连接此后将会通过长连接进行命令传播。
在这个过程中主节点将会在每次执行完一个命令后分别写两个缓冲区
replication_buffer主从复制缓冲区主节点每拥有一个从节点就会有一个对应的缓冲区要传播给从节点的命令会先写入该缓冲区随后在通过长连接发送给从节点。repl_backlog_buffer最近传播命令缓冲区一个主节点只有一个用于记录主节点最近传播出去的命令主节点和全部从节点都会分别在上面维护一个 offset用于表示自己已经写入或读取的命令进度。 3. 增量同步 repl_backlog_buffer 是主节点中一个比较特殊的缓冲区和每个从节点都有一个 replication_buffer 不同一个主节点只会有一个 repl_backlog_buffer 。
repl_backlog_buffer 是一个固定大小的“环形”区域当主节点写入数据时它会使用 master_offset 记录自己当前已经写到哪个字节对应的从节点也会有一个 slave_offset表示从节点已经读到的哪个字节。当主节点写的数据超过缓冲区大小后它将会覆盖最早写过的内容。 因此当从节点要与主节点进行同步时仅需要在 psync 请求时给出自己的 slave_offset 即可主节点将计算其与 master_offset 的差值
如果差值大于 repl_backlog_buffer 的大小说明两者数据已经差了很多那么需要重新进行全量同步。如果查找小于 repl_backlog_buffer 的大小说明数据差还在容许范围内则主节点将返回 CONTINUE 响应让从节点准备进行增量同步并把 repl_backlog_buffer 中的差值部分写入 replication_buffer 并发送给从节点让从节点把同步进度追上来。
简单的来说如果从节点最后一次读取的命令可以在上面找到那么说明从节点的数据没有落后太多因此可以增量同步否则就需要进行全量同步。 当主从链接断开后从节点会重新发送 psync 请求向主节点要求同步数据在 2.8 之前总是会使用全量同步而在 2.8 及以后的版本将会使用增量同步。 综上我们不难意识到如果你的网络不太稳定那么最好把 repl_backlog_buffer 调大一些这样可以尽可能的避免从节点掉线重连后需要频繁的进行全量同步。
Redis Sentinel哨兵模式
为什么要有哨兵模式
Redis 默认提供的主从模式不具备故障转移的能力当主节点宕机后需要用户手动的进行主从切换在这段时间内整个集群实际上处于不可用的状态。为了解决这个问题Redis 在 2.8 及以上版本提供了哨兵模式。
哨兵机制是如何工作的
简单的来说哨兵模式与普通的主从复制相比新增了一类哨兵节点它是一个特殊的 Redis 进程哨兵节点本身不对外提供任何读写服务它的作用是
监控与通知与所有节点保持心跳监控它们的监控状况。自动故障转移当主节点故障后自动选举新的主节点并完成主从切换实现自动故障转移。通知告警用户可以通过哨兵节点的 API 订阅消息从而在节点状态异常时获得通知又或者在完成主从切换后得知新的主节点地址。
故障检测
当哨兵节点启动以后每隔 1 秒它将会向集群中的主从节点与其他的哨兵节点发送 ping 请求以确认对方的健康状况。如果在指定的超时时间 down-after-millisenconds 内没有收到响应那么它就会认为没有响应的那个节点已经掉线将其标记为 sdown。这种这种下线状态称为“主观下线”。 如果下线的是从节点或者其他哨兵节点那么直到其重新上线为止哨兵都会认为其已经不可用。如果下线的是主节点那么哨兵为了防止因为网络波动导致的误判会向其他的哨兵节点发送 sentinel is-master-down-by-addr 请求确认对方是否也认定该节点下线。当整个哨兵集群中有足够数量的哨兵该值通过配置文件中的 quorum 进行配置节点确认主节点主观下线那么主节点就会被认定为“客观下线”并标记为 odown。 由哪个哨兵进行主从故障转移
在一切开始前哨兵集群会从所有的哨兵节点中挑选一个领头哨兵领头哨兵将用来代表其他节点完成重新选主和主从切换的任务。
Redis 基于 Raft 分布式共识算法来实现领头哨兵的选举这个过程大致如下
确认主节点客观下线的哨兵将成为候选者它先投自己一票然后邀请其他哨兵向自己投票其他哨兵如果尚未投票则会将把赞同票投给邀请它投票的候选哨兵否则就不投票所有的候选哨兵都统计自己的得票数当得票数满足下述两条件时该节点当选为领头哨兵 当得票数超过哨兵集群中节点数量的一半即 n/21得票数且超过了认定节点客观下线所要求的哨兵数量即配置文件中的 quorum 配置 如果在规定时间内或投票结束后都没有选出领头哨兵则再进行一轮投票直到选出领头哨兵为止。
由于选举机制需要保证有一个节点可以拿到超半数票因此为了保证哨兵集群的高可用一个最小的哨兵集群至少需要有三个节点这样当任意一个节点下线后哨兵集群仍然可以正常选举出领头哨兵去做故障转移。
此外我们可以注意到由于故障检测只受 quorum 影响而不受哨兵数量的影响。因此当 quorum 被设置了一个过小的值 —— 比如为低于 n/21——的时候可能会出现虽然哨兵确认节点客观下线了但是却由于在线的哨兵数量不足以选举出领头哨兵最终无法进行故障转移尴尬局面。
比如我们有一个由五个节点组成的哨兵集群当我们把 quorum 设置为 2 时如果挂掉了三个哨兵节点此时哨兵集群可以确认主节点已经客观下线但是由于哨兵节点数量不足无法选出领头哨兵所以即使发现了问题也无法完成故障转移。
主从故障转移的过程是怎样的
在哨兵集群中通过投票的方式选举出了哨兵 leader 后就可以进行主从故障转移的过程了如下图 主从故障转移操作包含以下四个步骤
第一步在已下线主节点旧主节点属下的所有「从节点」里面挑选出一个从节点并将其转换为主节点。第二步让已下线主节点属下的所有「从节点」修改复制目标修改为复制「新主节点」第三步将新主节点的 IP 地址和信息通过「发布者/订阅者机制」通知给客户端第四步继续监视旧主节点当这个旧主节点重新上线时将它设置为新主节点的从节点
选举出领头哨兵后它将从被自己监控的所有从节点中先排除下述节点
排除所有已经掉线的从节点排除五秒内没有响应哨兵的 INFO 命令的从节点当出现主节点客观下线后哨兵对节点的 INFO 命令已经变为一秒请求一次。排除与主节点断连超过 down-after-milliseconds * 10 毫秒的从节点down-after-milliseconds即为主节点的超时时间。
然后剩下的节点都有资格参与选举此时哨兵再根据以下条件选择出优先级最高的节点作为新的主节点
优先级配置先尝试根据 slave-priority 配置选出一个优先级最高的节点数据同步进度如果所有节点优先级配置均相同则从中挑选出一个复制进度最高的即主从复制中提到的从节点的 offset启动时间如果所有的节点复制进度均相同则挑选一个 runID 最小的节点即最新的从节点。
当选出一个新的主节点后领头哨兵将会发送 slave no one 命令将该节点真正的升级为主节点然后向其他的从节点发送 slaveof 命令让它们成为这个新主节点的从节点至此故障转移的就完成了。
需要注意的是在这个过程中由于主从复制延迟当主从切换后旧的主节点尚未同步从节点的数据可能就会丢失。
集群脑裂导致数据丢失怎么办
什么是脑裂
在正常情况下当发生主从切换时客户端将会从哨兵收到主节点切换的通知然后与旧的主节点断开连接并连接到新的主节点。不过如果有的客户端与哨兵也断开了连接那么它将无法意识到主节点已经切换并且还是连接到旧的主节点。此时整个 Redis 集群实际上同时有两个主节点在工作这就是脑裂问题。
解决方案
我们可以通过调整两个参数防止这种情况出现
min-replicas-to-write主节点必须要有至少 x 个从节点连接如果小于这个数主节点会禁止写数据。min-replicas-max-lag主从数据复制和同步的延迟不能超过 x 秒如果超过主节点会禁止写数据。
分别给它们设置一定的阈值假设为 N 和 T。
这两个配置项组合后的要求是主库连接的从库中至少有 N 个从库和主库进行数据复制时的 ACK 消息延迟不能超过 T 秒否则主库就不会再接收客户端的写请求了。
如此一来当主节点掉线时我们就可以让客户端能够及时发现问题然后重新向哨兵确认当前的主节点。在最大限度的避免的数据不一致问题后当旧的主节点节点重新上线就可以放心的让它去当从节点而不必担心数据丢失的问题。
不过有得必有失为了避免主节点“罢工”min-replicas-to-write 调的越高从节点就需要部署的越多min-replicas-max-lag 调的越小那主从节点间的网络就要越稳定。因此实际使用时还是需要结合自己的业务需求来衡量要采用什么样的配置。
Redis Cluster(分片集群)
为什么需要Redis Cluster
高并发场景下使⽤ Redis 主要会遇到的两个问题
缓存的数据量太⼤ 实际缓存的数据量可以达到⼏⼗ G甚至是成百G并发量要求太大虽然 Redis 号称单机可以⽀持 10w 并发
主从复制和 Redis Sentinel 这两种⽅案本质都是通过增加主库master的副本slave数量的⽅式来提⾼ Redis 服务的整体可⽤性和读吞吐量都不⽀持横向扩展来缓解写压⼒以及解决缓存数据量过⼤的问题。
Redis 切⽚集群 就是部署多台 Redis 主节点master这些节点之间平等并没有主从之说同时对外提供读写服务。缓存的数据库相对均匀地分布在这些 Redis 实例上客户端的请求通过路由规则转发到⽬标 master 上。
总结⼀下 Redis Cluster 的主要优势
可以横向扩展缓解写压⼒和存储压⼒⽀持动态扩容和缩容具备主从复制、故障转移内置了 Sentinel 机制⽆需单独部署 Sentinel 集群等开箱即⽤的功能。
Redis Cluster 是如何分⽚的
Redis Cluster 并没有使⽤⼀致性哈希采⽤的是 哈希槽分区 每⼀个键值对都属于⼀个 hash slot哈希槽 。
Redis Cluster 通常有 16384 个哈希槽 要计算给定 key 应该分布到哪个哈希槽中我们只需要先对每个 key 计算 CRC-16XMODEM 校验码然后再对这个校验码对 16384(哈希槽的总数) 取模得到的值即是 key 对应的哈希槽。 为什么 Redis Cluster 的哈希槽是 16384 个?
CRC16 算法产⽣的校验码有 16 位理论上可以产⽣ 655362^160 ~ 65535个值。为什么 Redis Cluster 的哈希槽偏偏选择的是 163842^14个呢
Redis Cluster 的哈希槽的数量选择 16384 ⽽不是 65536 的主要原因
哈希槽太⼤会导致⼼跳包太⼤消耗太多带宽哈希槽总数越少对存储哈希槽信息的 bitmap 压缩效果越好Redis Cluster 的主节点通常不会扩展太多16384 个哈希槽已经⾜够⽤了。
Redis Cluster中的节点是怎么进行通信的
由于 Redis 的集群是去中心化的这意味着集群中实际上没有一个类似注册中心一样的角色所以每个节点都需要通过 Gossip 协议与其他节点保持通信这个通信端口通常是默认的服务端口加 10000比如默认的服务端口是 6379那么集群通信端口就是 16379。
Gossip 协议
尽管我们常说节点之间会“保持通信”但实际上Redis 集群并不要求每个节点都必须一直与其他所有节点同时保持连接这要归功于 Redis 使用的 Gossip 协议Gossip 可以译为流言或者八卦这很好的反映了这个协议的特点。
举个例子假如现在有一个新节点 D 要加入
C 邀请 D 加入集群现在 C 知道了 D 的存在B 与 C 进行 ping pong通过 C 得知 D 加入了集群现在 B 知道了 D 的存在A 与 B 进行 ping pong通过 B 得知 D 加入了集群现在 A 也知道了 D 的存在。
可见当有一个新的事件发生后它会逐步的在集群中传播即使中间有节点挂掉只要消息的传播路径没有完全被切断那么其他节点也会最终会被通知到比如新节点的加入或者节点下线……等。
当然实际上 Redis 也不是完全依赖这种方式传播消息对于一些时效性要求比较强的消息 —— 比如节点下线或者主从切换 —— 则会直接通过广播的方式进行通知。
节点间的数据交换
组群后每个 Redis 实例都会在本地维护一个集群实例列表然后定期从中挑选节点发送 ping 消息而另一个节点收到了之后会回以 pong 响应。两个节点通过这个步骤来确认彼此健康状态并传递其其他节点的下线状态以及交换彼此持有的槽位信息等数据。
需要注意的是ping 的目标并不是完全随机的它遵循两个规则
默认情况下Redis 实例每隔一秒都会从已知的集群节点中挑选出 5 个实例然后再从中挑选出一个最久没有 ping 过的节点发送消息。每隔一段时间Redis 将会检查其他节点对当前节点请求的响应情况如果发现有节点最近一次响应距今已接近超时时间 cluster-node-timeout那么它会立刻向该节点发起 ping 请求若再无响应则会标记为主观下线。
