济南高品质网站制作,在线浏览器网页版入口,wordpress服务框,儿童玩具网站建设策划书目录
Redis集群方案
主从复制
主从复制的基本原理
主从复制的工作流程
乐观复制
主从复制的优势
哨兵机制
哨兵的关键作用
服务状态监控
哨兵选举Master规则
分片集群
分片集群中的数据读写
数据写入
数据读取
一致性哈希和客户端分片 Redis集群方案
微服务时代…目录
Redis集群方案
主从复制
主从复制的基本原理
主从复制的工作流程
乐观复制
主从复制的优势
哨兵机制
哨兵的关键作用
服务状态监控
哨兵选举Master规则
分片集群
分片集群中的数据读写
数据写入
数据读取
一致性哈希和客户端分片 Redis集群方案
微服务时代背景下现实中我们的项目往往需要多台Redis服务器的支持 结构上单个Redis容易引发单点故障一台服务器需要承载所有请求。所以需要多个节点同步复制。 容量上单个Redis的内存很容易成为存储瓶颈。所以需要进行数据分片。
针对Redis的集群方案常见的有主从复制、哨兵模式、分片集群。
主从复制
Redis的主从复制是一种常见的数据复制和高可用性的机制。它通过将一个Redis节点的数据复制到其他节点实现数据的备份和读写分离。 主从复制的基本原理 全量复制 初始阶段从节点会向主节点发送一次SYNC命令主节点会将自己的数据库快照发送给从节点。从节点接收到快照后会清空自己的数据库然后将接收到的快照数据加载到自己的数据库中完成全量复制。 Replication Id简称replid是数据集的标记id一致则说明是同一数据集。每一个master都有唯一的replidslave则会继承master节点的replid。 offset偏移量随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset说明slave数据落后于master需要更新。 增量复制 一旦从节点完成全量复制主节点会继续将自己的写操作写命令发送给从节点。这样从节点就能保持自己的数据库和主节点保持一致。增量复制通过主节点将执行的写命令传播给从节点来实现。 主从复制的工作流程 从节点连接到主节点 从节点通过发送PING命令或PSYNC命令与主节点建立连接。PSYNC命令是增量复制的一部分它用于在断线重连时从节点告知主节点自己的复制偏移量。 主节点创建快照 一旦从节点连接到主节点主节点会执行BGSAVE命令创建一个RDB快照。这个快照包含了当前主节点数据库的全部数据。 从节点加载快照 主节点创建快照后会将快照数据传输给从节点。从节点接收到快照后会清空自己的数据库然后加载主节点传来的快照数据完成全量复制。 增量复制 从节点完成全量复制后主节点会将自己的写操作写命令发送给从节点。从节点接收到写命令后会执行相同的写操作保持与主节点数据的一致性。 心跳和断线重连 主节点和从节点会通过心跳机制保持连接。如果从节点与主节点的连接断开从节点会尝试重新连接并使用PSYNC命令告知主节点自己的复制偏移量主节点会根据从节点的复制偏移量发送缺失的写命令从而实现断线重连时的增量同步。
乐观复制
乐观复制Optimistic Replication通常是指一种基于版本控制的复制策略其核心思想是节点在进行数据复制时不需要先获取到全局锁而是通过版本号等机制来进行冲突的检测和解决。在Redis中乐观复制并非官方的特性但是可以通过一些手段实现类似的效果。 版本号 在Redis中你可以使用自定义的版本号通过 INCR 等命令来增加节点的版本号。在写操作时将写操作和对应的版本号发送给其他节点。 冲突检测 在节点接收到写操作时检查接收到的写操作的版本号是否比自己的版本号大。如果大执行写操作并更新版本号如果小则发生冲突需要进行冲突解决。 冲突解决 冲突解决可以采用一些策略例如最后一次写操作覆盖之前的写操作或者保留所有冲突的写操作等。
需要注意的是这种自定义的乐观复制机制需要谨慎设计因为在分布式环境中冲突的发生是不可避免的需要考虑如何解决冲突、保证数据的一致性等问题。另外Redis本身提供的主从复制和哨兵机制已经能够满足大部分应用场景使用官方提供的复制机制通常更为稳妥。
主从复制的优势 数据备份 主从复制可以用作数据的备份机制当主节点发生故障时从节点可以升级为主节点确保数据的可用性。 读写分离 从节点可以处理读请求实现读写分离分担主节点的读负载提高系统的并发处理能力。 容灾性 当主节点发生故障时可以快速切换到从节点提高系统的容灾性。 故障恢复 当主节点恢复正常工作时可以将从节点重新配置为主节点的从节点实现故障恢复。
哨兵机制
Redis提供了哨兵Sentinel机制哨兵通过协调多个哨兵进程的工作来实现主从集群的自动故障恢复。 哨兵的关键作用 监控 哨兵负责监控Redis主节点和从节点的健康状态。它通过周期性的检查节点的状态包括网络连接状态、是否存活等。 故障检测 当哨兵发现某个Redis节点不可用时它会将这一信息广播给其他哨兵和客户端。哨兵根据一定的条件来判断一个节点是否处于不可用状态例如在规定时间内未响应等。 故障转移 在主节点不可用时哨兵会自动进行故障转移。它会通过选举的方式选择一个从节点升级为新的主节点保证系统的可用性。 自动发现 哨兵可以通过 SENTINEL 命令进行自动发现不需要手动配置所有哨兵的信息。这使得系统更加灵活能够适应节点的动态变化。
服务状态监控
Sentinel基于心跳机制监测服务状态每隔1秒向集群的每个实例发送ping命令 主观下线如果某sentinel节点发现某实例未在规定时间响应则认为该实例主观下线。 客观下线若超过指定数量quorum的sentinel都认为该实例主观下线则该实例客观下线。quorum值最好超过Sentinel实例数量的一半。
哨兵选举Master规则
Redis哨兵进行主节点选举时遵循一定的规则和条件以确保选出的新主节点是可用的。以下是哨兵选举Master的基本规则 Quorum仲裁 选举需要达到QuorumQuorum的计算方式为 (哨兵总数 / 2) 1。只有得到足够多的哨兵投票选举才能生效。 Quorum的引入是为了防止因为网络分裂等问题导致多个主节点同时被选举。 哨兵优先级 每个哨兵节点都有一个配置的优先级可以通过 sentinel.conf 文件中的 sentinel myid priority 配置项设置。默认为100。 哨兵在选举时会选择优先级最高的哨兵作为领导者由领导者发起主节点选举。 最高优先级的Slave 如果有多个从节点具有相同的优先级哨兵将选择复制偏移量replication offset最大的从节点作为新的主节点。 复制偏移量是指从节点的复制进度选择复制偏移量最大的从节点有助于保持数据的一致性。 选举超时和投票 当一个哨兵发现主节点不可用后它会发起一轮选举设定一个选举超时时间。在这个时间内哨兵会收集其他哨兵的投票。 哨兵通过相互通信进行选举投票包括对自身的投票。哨兵节点可以投票给自己也可以投票给其他哨兵。 领导者发起选举 选举开始时哨兵中优先级最高的节点成为领导者由领导者发起主节点选举。 领导者向其他哨兵广播自己的选票其他哨兵在收到选票后进行投票。 多轮投票 选举可能进行多轮直到某个哨兵得到Quorum的支持为止。在每一轮选举中哨兵都会尝试发起并参与投票。 新主节点确认 当一个哨兵获得Quorum的支持后它会确认选出的新主节点。其他哨兵节点收到确认后会更新配置并将新的主节点信息广播给其他节点。 客户端更新 一旦新的主节点选出哨兵将通知客户端更新连接信息使客户端连接到新的主节点。
通过这些规则Redis哨兵确保了在主节点发生故障时能够选出一个优先级高、复制偏移量最大的从节点作为新的主节点从而确保系统的高可用性。
分片集群
主从和哨兵可以解决高可用、高并发读的问题。但是依然有两个问题没有解决 海量数据存储问题 高并发写的问题
使用分片集群可以解决上述问题分片集群特征 集群中有多个master每个master保存不同数据 每个master都可以有多个slave节点 master之间通过ping监测彼此健康状态 客户端请求可以访问集群任意节点最终都会被转发到正确节点 分片集群中的数据读写
Redis分片集群使用了哈希槽Hash SlotRedis分片集群将整个数据集划分为16384个哈希槽每个槽都有一个唯一的编号。这些哈希槽用于存储数据同时也用于管理数据的分片。数据的键通过哈希算法映射到某个哈希槽上决定了数据应该由哪个节点负责存储。
数据写入 计算哈希槽 当客户端向Redis集群发送写入请求时Redis首先计算键对应的哈希槽。通过哈希算法确定键属于哪个哈希槽。 选择节点 哈希槽确定后根据哈希槽和集群中的节点分布选择负责处理该哈希槽的节点。这个节点被称为槽的持有者。 发送写请求 客户端将写请求发送给被选择的节点。如果该节点是主节点它将负责处理写请求如果是从节点写请求将被转发给主节点。 写入数据 主节点接收到写入请求后将数据写入自己的数据存储。然后主节点会将写入操作通过集群总线广播给其他从节点以保持数据的一致性。
数据读取 计算哈希槽 当客户端向Redis集群发送读取请求时同样需要计算键对应的哈希槽确定数据所在的槽。 选择节点 根据哈希槽和节点分布选择负责处理该哈希槽的节点。这个节点可能是主节点也可能是从节点。 发送读请求 客户端将读请求发送给被选择的节点。如果是主节点它将直接处理读请求如果是从节点读请求可能会被转发到主节点。 读取数据 节点处理读请求如果是主节点直接从自己的数据存储中读取数据并返回给客户端如果是从节点它可能会从主节点获取最新的数据并返回给客户端。
一致性哈希和客户端分片 为了在节点变动时保持哈希槽的一致性Redis使用一致性哈希算法。这确保了在节点加入或退出时只有少量的槽需要迁移而不是整个数据集。 客户端也需要进行分片以确保请求被正确发送到负责处理对应数据分片的节点。通常客户端使用一致性哈希算法或其他分片策略来选择正确的节点。
通过上述过程Redis分片结构实现了数据的分散存储和读写负载均衡同时通过哈希槽的管理和一致性哈希算法保障了系统的一致性和可用性。
