个人能为公司网站备案吗,建设局是干啥的,wordpress数据库字典,整形网站 源码文章目录 前言一、主从模式1.1 复制流程1.2 优缺点 二、哨兵模式2.1 介绍2.2 哨兵的工作模式 三、集群模式3.1 Cluster集群节点的通讯3.2 Hash Slot插槽算法3.3 Redis Cluster集群3.4 故障转移 前言
如果单机部署Redis服务的话#xff0c;一旦Reids宕机#xff0c;那么整个服… 文章目录 前言一、主从模式1.1 复制流程1.2 优缺点 二、哨兵模式2.1 介绍2.2 哨兵的工作模式 三、集群模式3.1 Cluster集群节点的通讯3.2 Hash Slot插槽算法3.3 Redis Cluster集群3.4 故障转移 前言
如果单机部署Redis服务的话一旦Reids宕机那么整个服务就不可用了这就是我们常说的单点故障问题。Redis为了实现高可用通常的做法是将数据库复制多个副本以部署在不同的服务器上即使其中一台挂了其它Redis实例也可以继续提供服务。Redis实现高可用有三种部署模式主从模式哨兵模式集群模式。
一、主从模式
主从模式中Redis部署在多台机器其中主节点负责读写操作从节点只负责读操作。一个主节点可以有多个从节点但是一个从节点只会有一个主节点也就是所谓的一主多从结构。从节点的数据来自主节点实现原理就是主从复制机制。
1.1 复制流程
主从复制包括全量复制增量复制两种。一般当slave第一次启动连接master或者认为是第一次连接就采用全量复制全量复制流程如下
slave发送sync命令到master。master接收到SYNC命令后执行bgsave命令生成RDB全量文件。master使用缓冲区记录RDB快照生成期间的所有写命令。master执行完bgsave后向所有slave发送RDB快照文件。slave收到RDB快照文件后载入、解析收到的快照。master使用缓冲区记录RDB同步期间生成的所有写的命令。master快照发送完毕后开始向slave发送缓冲区中的写命令;salve接受命令请求并执行来自master缓冲区的写命令
redis2.8版本之后已经使用psync来替代sync因为sync命令非常消耗系统资源psync的效率更高。
slave与master全量同步之后master上的数据如果再次发生更新就会触发增量复制。
当master节点发生数据增减时就会触发replicationFeedSalves()函数接下来在 Master节点上调用的每一个命令会使用replicationFeedSlaves()来同步到Slave节点。执行此函数之前呢master节点会判断用户执行的命令是否有数据更新如果有数据更新的话并且slave节点不为空就会执行此函数。这个函数作用就是把用户执行的命令发送到所有的slave节点让slave节点执行。流程如下
1.2 优缺点
优点
支持主从复制主机会自动将数据同步到从机可以进行读写分离;为了分载Master的读操作压力Slave服务器可以为客户端提供只读操作的服务写服务依然必须由Master来完成;Slave同样可以接受其他Slaves的连接和同步请求这样可以有效地分载Master的同步压力;Master是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间客户端仍然可以提交查询或修改请求;Slave同样是以阻塞的方式完成数据同步。在同步期间如果有客户端提交查询请求Redis则返回同步之前的数据。
缺点
Redis不具备自动容错和恢复功能主机从机的宕机都会导致前端部分读写请求失败需要等待机器重启或者手动切换前端的IP才能恢复;主机宕机宕机前有部分数据未能及时同步到从机切换IP后还会引入数据不一致的问题降低了系统的可用性;如果多个Slave断线了需要重启的时候尽量不要在同一时间段进行重启。因为只要Slave启动就会发送sync请求和主机全量同步当多个Slave重启的时候可能会导致Master IO剧增从而宕机。Redis较难支持在线扩容在集群容量达到上限时在线扩容会变得很复杂;redis的主节点和从节点中的数据是一样的降低的内存的可用性
二、哨兵模式
2.1 介绍
主从模式中一旦主节点由于故障不能提供服务需要人工将从节点晋升为主节点同时还要通知应用方更新主节点地址。显然多数业务场景都不能接受这种故障处理方式。Redis从2.8开始正式提供了Redis Sentinel哨兵架构来解决这个问题。
哨兵模式由一个或多个Sentinel实例组成的Sentinel系统它可以监视所有的Redis主节点和从节点并在被监视的主节点进入下线状态时自动将下线主服务器属下的某个从节点升级为新的主节点。但是呢一个哨兵进程对Redis节点进行监控就可能会出现问题单点问题因此可以使用多个哨兵来进行监控Redis节点并且各个哨兵之间还会进行监控。
简单来说哨兵模式就三个作用
发送命令等待Redis服务器包括主服务器和从服务器返回监控其运行状态哨兵监测到主节点宕机会自动将从节点切换成主节点然后通过发布订阅模式通知其他的从节点修改配置文件让它们切换主机哨兵之间还会相互监控从而达到高可用。
故障切换的过程是怎样的呢
假设主服务器宕机哨兵1先检测到这个结果系统并不会马上进行failover过程仅仅是哨兵1主观的认为主服务器不可用这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用并且数量达到一定值时那么哨兵之间就会进行一次投票投票的结果由一个哨兵发起进行failover操作。切换成功后就会通过发布订阅模式让各个哨兵把自己监控的从服务器实现切换主机这个过程称为客观下线。这样对于客户端而言一切都是透明的。
2.2 哨兵的工作模式
每个Sentinel以每秒钟一次的频率向它所知的MasterSlave以及其他Sentinel实例发送一个 PING命令。如果一个实例instance距离最后一次有效回复PING命令的时间超过down-after-milliseconds选项所指定的值则这个实例会被Sentinel标记为主观下线。如果一个Master被标记为主观下线则正在监视这个Master的所有Sentinel要以每秒一次的频率确认Master的确进入了主观下线状态。当有足够数量的Sentinel大于等于配置文件指定的值在指定的时间范围内确认5. Master的确进入了主观下线状态 则Master会被标记为客观下线。在一般情况下每个Sentinel会以每10秒一次的频率向它已知的所有MasterSlave发送 INFO 命令。当Master被Sentinel标记为客观下线时Sentinel 向下线的Master的所有Slave发送 INFO命令的频率会从10秒一次改为每秒一次。若没有足够数量的 Sentinel同意Master已经下线 Master的客观下线状态就会被移除若Master 重新向 Sentinel 的 PING 命令返回有效回复 Master 的主观下线状态就会被移除。
三、集群模式
哨兵模式基于主从模式实现读写分离它还可以自动切换让系统可用性更高。但是它每个节点存储的数据是一样的造成浪费内存并且不好在线扩容。因此Cluster集群应运而生它在Redis3.0加入的实现了Redis的分布式存储。对数据进行分片也就是说每台Redis节点上存储不同的内容来解决在线扩容的问题。并且它也提供复制和故障转移的功能。
3.1 Cluster集群节点的通讯
一个Redis集群由多个节点组成各个节点之间是怎么通信的呢
Redis Cluster集群通过Gossip协议进行通信节点之前不断交换信息交换的信息内容包括节点出现故障、新节点加入、主从节点变更信息、slot信息等等。常用的Gossip消息分为4种分别是ping、pong、meet、fail。
meet消息通知新节点加入。消息发送者通知接收者加入到当前集群meet消息通信正常完成后接收节点会加入到集群中并进行周期性的ping、pong消息交换。ping消息集群内交换最频繁的消息集群内每个节点每秒向多个其他节点发送ping消息用于检测节点是否在线和交换彼此状态信息。pong消息当接收到ping、meet消息时作为响应消息回复给发送方确认消息正常通信。pong消息内部封装了自身状态数据。节点也可以向集群内广播自身的pong消息来通知整个集群对自身状态进行更新。fail消息当节点判定集群内另一个节点下线时会向集群内广播一个fail消息其他节点接收到fail消息之后把对应节点更新为下线状态。
特别的每个节点是通过集群总线(cluster bus) 与其他的节点进行通信的。通讯时使用特殊的端口号即对外服务端口号加10000。例如如果某个node的端口号是6379那么它与其它nodes通信的端口号是16379。nodes之间的通信采用特殊的二进制协议。
3.2 Hash Slot插槽算法
既然是分布式存储Cluster集群使用的分布式算法是一致性Hash嘛 并不是而是Hash Slot插槽算法。
插槽算法把整个数据库被分为16384个slot槽每个进入Redis的键值对根据key进行散列分配到这16384插槽中的一个。使用的哈希映射也比较简单用CRC16算法计算出一个16 位的值再对16384取模。数据库中的每个键都属于这16384个槽的其中一个集群中的每个节点都可以处理这16384个槽。
集群中的每个节点负责一部分的hash槽比如当前集群有A、B、C个节点每个节点上的哈希槽数 16384/3那么就有
节点A负责0~5460号哈希槽节点B负责5461~10922号哈希槽节点C负责10923~16383号哈希槽
3.3 Redis Cluster集群
Redis Cluster集群中需要确保16384个槽对应的node都正常工作如果某个node出现故障它负责的slot也会失效整个集群将不能工作。
因此为了保证高可用Cluster集群引入了主从复制一个主节点对应一个或者多个从节点。当其它主节点 ping 一个主节点 A 时如果半数以上的主节点与 A 通信超时那么认为主节点 A 宕机了。如果主节点宕机时就会启用从节点。
在Redis的每一个节点上都有两个玩意一个是插槽slot它的取值范围是0~16383。另外一个是cluster可以理解为一个集群管理的插件。当我们存取的key到达时Redis 会根据CRC16算法得出一个16 bit的值然后把结果对16384取模。酱紫每个key都会对应一个编号在 0~16383 之间的哈希槽通过这个值去找到对应的插槽所对应的节点然后直接自动跳转到这个对应的节点上进行存取操作。
虽然数据是分开存储在不同节点上的但是对客户端来说整个集群Cluster被看做一个整体。客户端端连接任意一个node看起来跟操作单实例的Redis一样。当客户端操作的key没有被分配到正确的node节点时Redis会返回转向指令最后指向正确的node这就有点像浏览器页面的302 重定向跳转。
3.4 故障转移
Redis集群实现了高可用当集群内节点出现故障时通过故障转移以保证集群正常对外提供服务。
redis集群通过ping/pong消息实现故障发现。这个环境包括主观下线和客观下线。
主观下线 某个节点认为另一个节点不可用即下线状态这个状态并不是最终的故障判定只能代表一个节点的意见可能存在误判情况。 客观下线 指标记一个节点真正的下线集群内多个节点都认为该节点不可用从而达成共识的结果。如果是持有槽的主节点故障需要为该节点进行故障转移。
假如节点A标记节点B为主观下线一段时间后节点A通过消息把节点B的状态发到其它节点当节点C接受到消息并解析出消息体时如果发现节点B的pfail状态时会触发客观下线流程当下线为主节点时此时Redis Cluster集群为统计持有槽的主节点投票看投票数是否达到一半当下线报告统计数大于一半时被标记为客观下线状态。
流程如下 故障恢复故障发现后如果下线节点的是主节点则需要在它的从节点中选一个替换它以保证集群的高可用。流程如下
资格检查检查从节点是否具备替换故障主节点的条件。准备选举时间资格检查通过后更新触发故障选举时间。发起选举到了故障选举时间进行选举。选举投票只有持有槽的主节点才有票从节点收集到足够的选票大于一半触发替换主节点操作
