无域名网站 能否被百度,网站建设需要服务器么,网站关键字怎么做,百度wordpress插件下载地址目录标题 1、背景及介绍2、 Redis 主从复制2.1、主从复制特点2.2、Redis主从复制原理2.3 PSYNC 工作原理2.3.1、启动或重连判断#xff1a;2.3.2、第一次同步处理#xff1a;2.3.3、断线重连处理#xff1a;2.3.4、主节点响应2.3.5、全量同步触发条件#xff1a;2.3.6、复制… 目录标题 1、背景及介绍2、 Redis 主从复制2.1、主从复制特点2.2、Redis主从复制原理2.3 PSYNC 工作原理2.3.1、启动或重连判断2.3.2、第一次同步处理2.3.3、断线重连处理2.3.4、主节点响应2.3.5、全量同步触发条件2.3.6、复制积压缓冲区的作用2.3.7、数据一致性保障 2.4、Redis 主从模式环境搭建 3、Redis 哨兵机制3.1、概述3.2、Redis哨兵原理3.3、哨兵模式环境搭建 4、Redis Cluster4.1、概述4.2、cluster原理4.2.1、Redis Cluster 节点分配与主从模式4.2.1.1、节点间的哈希槽分配4.2.1.2、数据的保存和获取4.2.1.3、新增或删除主节点4.2.2、Redis Cluster主从模式 4.3、cluster架构 1、背景及介绍
Redis 支持三种不同的集群模式主从模式、哨兵模式和Cluster模式各具特色应对不同的应用场景。
初始阶段Redis 采用主从模式进行集群构建。在此模式中主节点master负责数据写入而从节点slave则用于数据读取和备份。若主节点发生故障需人工介入将某个从节点提升为新的主节点。但这种模式在故障恢复上效率较低无法实现高度自动化。
为了提升系统的高可用性Redis 推出了哨兵模式。在此模式下通过一个哨兵集群来监控主从节点的健康状态。一旦主节点故障被侦测到系统会自动选举出一个从节点晋升为新的主节点从而实现故障恢复的自动化提高系统的稳定性和可靠性。
然而哨兵模式仍然存在一定的局限性例如内存容量和写入性能都受限于单个节点。为了克服这些限制Redis 在 3.x 版本后推出了Cluster模式。这一模式通过数据分片sharding和多节点水平扩展有效提高了内存利用率和写入性能适用于更大规模和更高要求的数据处理场景。总体来说Cluster模式为Redis集群的性能和扩展性提供了重要的支撑。 2、 Redis 主从复制
2.1、主从复制特点
Redis的主从复制架构通过定义主库master和从库slave的角色实现了数据的高效同步和备份具备以下几个显著特点
主库的读写能力主库master是数据操作的中心。它处理所有的写请求并且也能处理读请求。任何在主库上执行的数据修改操作都会实时且自动地同步到所有从库slave。单向数据流数据同步流程是单向的即数据仅从主库流向从库。这种单向流动保证了数据同步的一致性和可靠性。从库的只读特性从库通常被配置为只读模式用于接收并存储从主库传来的数据。这种设计主要用于分担读取负载从而提升整个系统的读取性能。主从关系的配置一个主库可以对应多个从库形成一对多的关系有利于数据冗余备份和读取负载的分散。反之一个从库仅对应一个主库以维护数据同步的一致性。从库的容错能力若某个从库故障其对系统其他部分的影响极小。即使在从库宕机的情况下其他从库仍可提供读服务主库也能继续正常的读写操作。故障的从库在恢复后能自动从主库同步缺失数据。主库故障的影响主库故障可能导致Redis暂停处理新的写请求但已连接的从库可继续提供读服务。主库恢复后Redis将重新提供完整的读写服务。应对主库故障的机制在当前主库故障时系统不会自动在从库中选举新的主库。这需要借助额外的高可用性解决方案例如Redis Sentinel或Redis Cluster来管理主库的选举和故障转移。
Redis的主从复制架构有效地提供了高可用性、数据冗余以及读写分离的功能确保了在保持高性能的同时数据安全和一致性得到保障。
2.2、Redis主从复制原理
在本文档中我们将重点介绍Redis版本2.8及其后续版本的主从复制机制。
无是哪种场景Redis 的主从复制机制均采用异步复制也称为乐观复制因此不能完全保证主从数据的一致性。
不论在什么场景下Redis的主从复制机制都采用了所谓的“异步复制”或“乐观复制”。这种复制方式意味着不能完全保证主库和从库数据的实时一致性。
Redis的主从复制机制可以根据不同的运行场景和条件采取不同的实现方式。以下是一些主要场景及其对应的复制实现和说明
第一次启动在从库第一次连接到主库时将采用psync复制方式进行全量复制。这意味着从库会从头开始复制主库中的全部数据。正常运行期间在正常运行状态下从库通过读取主库的缓冲区来进行增量复制。这个过程涉及复制主库上发生的新的数据变更。从库第二次启动主库缓冲区未溢出 当从库重新启动且主库的缓冲区未溢出时将通过读取主库的缓冲区进行部分复制。这种方式能够快速同步中断期间发生的数据变更而不会对主库造成重大影响。Redis 2.8及以上版本的从库第二次启动针对主库 当从库第二次启动且系统版本为Redis 2.8或以上时将采用psync复制进行全量复制。这种情况通常发生在主库的缓冲区数据无法满足从库需要同步的数据量时。
通过上述不同的复制策略Redis能够在保证数据备份和减少系统负载的同时灵活应对各种运行场景。尽管异步复制机制可能导致主从数据存在短暂的不一致但这种设计在绝大多数应用场景中已被证明是既高效又可靠的。
PS异步复制是Redis的复制方式而psync是实现这种复制方式的具体命令。乐观复制或乐观并发控制则是另一种与Redis的异步复制机制不同的数据库事务处理概念。不少博客或说明介绍异步复制和乐观复制是同一个概念。
2.3 PSYNC 工作原理 PSYNC 命令是Redis中用于从节点与主节点之间数据同步的关键命令。它的工作原理包括以下几个步骤
2.3.1、启动或重连判断
当从节点Slave启动或者与主节点Master的连接断开后重连时从节点需要确定是否曾经同步过。
如果从节点没有保存任何主节点的运行 IDrunnid它将视为第一次连接道主节点。
2.3.2、第一次同步处理
在第一次同步的情况下从节点会发送 PSYNC -1 命令给主节点请求进行全量数据同步。
全量同步是指主节点将其所有数据完整地复制一份给从节点。
2.3.3、断线重连处理
对于之前已经同步过的从节点它会发送 PSYNC runid offset 命令其中runid是主节点的唯一标识符offset是从节点上次同步数据的偏移量。
2.3.4、主节点响应
主节点接收到PSYNC命令后会检查runid是否匹配以及offset是否在复制积压缓冲区的范围内。
如果匹配且offset有效主节点将回复CONTINUE并发送自从节点上次断开连接以来的所有写命令。
2.3.5、全量同步触发条件
如果runid不匹配或offset超出了积压缓冲区的范围主节点将通知从节点执行全量同步回复FULLRESYNC runid offset。
2.3.6、复制积压缓冲区的作用
主节点会在处理写命令的同时将这些命令存入复制积压队列同时记录队列中存放命令的全局offset。当从节点断线重连且条件允许时它可以通过offset从积压队列中进行增量复制而不是全量复制。
2.3.7、数据一致性保障
PSYNC机制允许从节点在网络不稳定或其他意外断开连接的情况下能够以增量方式重新同步数据保持主从节点数据的一致性。
2.4、Redis 主从模式环境搭建
在Redis的主从架构中主节点的数据更新会自动被复制到从节点确保数据的一致性。这种设置既是一种数据备份策略——从节点存储了主节点的数据备份也提高了数据安全性。此外通过主从架构实现读写分离主节点负责处理写请求而读请求可以分散到一个或多个从节点这样既提高了系统的处理能力又优化了资源的利用。
3、Redis 哨兵机制
3.1、概述
在本文档中我们将重点介绍Redis版本2.8及其后续版本的哨兵机制。
哨兵模式是主从复制模式的一种进阶形式继承了主从复制的所有优势如数据一致性和读写分离。它的核心优点在于能够自动实现主从切换和故障转移从而提升了系统的可用性和稳定性。在哨兵模式下系统能够从手动切换转变为自动切换极大地增强了系统的自动化程度和稳定性。然而哨兵模式也存在一定的局限性特别是在在线扩容方面。当集群容量接近或达到上限时进行扩容操作相对较为复杂和困难。
注意事项Redis 在 Windows 平台上不受官方支持Redis 官方只提供了源码包zip、tar.gz 格式。
Redis 官网地址redis.io/ Redis源码地址github.com/redis/redis
3.2、Redis哨兵原理
自Redis 2.8版本起官方引入了Sentinel哨兵架构旨在提升系统的高可用性。哨兵模式主要通过后台监控机制来确保Redis服务的稳定性。在这一模式中哨兵负责实时监控主节点的运行状况。一旦主节点出现故障哨兵将基于预设的投票机制自动将某个从节点晋升为新的主节点以保持服务的连续性和数据的可用性。
**哨兵本身是一个独立的进程运行在Redis本身进程之外。它通过周期性地向Redis节点发送命令并等待节点的响应来判断被监控的Redis实例是否正常运行。**通过这种方式哨兵能够监控和管理一个或多个Redis实例确保整个Redis服务的高可用性和稳定性。 3.3、哨兵模式环境搭建 4、Redis Cluster
4.1、概述
Redis Cluster采用了去中心化的多主多从架构以提高数据的可用性和伸缩性。这一架构使得Redis Cluster能够在保持高性能的同时支持更大规模的数据存储和管理。以下是Redis Cluster的几个关键特点和优势的详细阐述
去中心化的多主多从架构 每个从节点都复制主节点的数据但不直接参与读写操作主要用于数据备份和故障恢复。这种架构使得每个节点都可以在需要时承担主节点的角色从而提高了整体系统的可靠性和容错能力。 数据处理与性能 Redis Cluster在处理涉及多个键的操作时可能面临性能挑战尤其是在数据量大和高并发的场景下。这是因为多key操作可能需要跨多个节点进行从而增加了操作的复杂性。 然而对于单key操作Redis Cluster能够保持其一贯的高性能特别是在读操作上。 动态扩容和收缩能力 Redis Cluster支持动态地添加或移除节点这意味着可以根据实际需求调整集群的规模无需停机或中断服务。这一特性对于处理不断变化的负载和数据量非常重要使得Redis Cluster在大型应用中更具弹性。 节点间的通信与故障转移 在Redis Cluster中主节点之间会进行定期的健康检查和状态同步确保数据的一致性。当主节点出现故障时其他主节点可以通过选举机制快速选出新的主节点实现故障的自动转移从而确保服务的连续性。
4.2、cluster原理
4.2.1、Redis Cluster 节点分配与主从模式
Redis Cluster 通过高效的节点分配和稳健的主从模式确保了数据的高可用性和稳定性。以下是对其核心机制的详细解释
4.2.1.1、节点间的哈希槽分配
Redis Cluster 使用哈希槽hash slot机制来分配数据。假设我们有三个主节点A、B、C它们可以部署在同一台机器的不同端口上或分布在三台不同的服务器上。在这种设置下16384个哈希槽将被如下分配
节点A负责管理0至5460号槽节点B负责管理5461至10922号槽节点C负责管理10923至16383号槽。
在 Redis Cluster 中节点之间通过 gossip 协议进行通信并通过选举机制实现故障转移。
Gossip 协议 Redis Cluster 使用 Gossip 协议来实现节点之间的通信。Gossip 协议是一种去中心化的通信协议每个节点定期与其他节点交换信息从而在整个集群中传播状态信息。
具体步骤如下
心跳消息 每个节点会定期向其他节点发送心跳消息HELO 消息。心跳消息包含发送节点的状态信息如节点 ID、IP 地址、端口号、槽位分配情况等。 信息传播 接收到心跳消息的节点会更新自己的状态表并将这些信息进一步传播给其他节点。这种多对多的通信方式确保了信息在整个集群中的快速传播。 节点发现 新加入集群的节点会通过初始配置或现有节点的推荐来发现其他节点。一旦发现其他节点新节点会开始发送心跳消息逐步融入集群。 节点状态监控 每个节点都会定期检查其他节点的状态。如果一个节点在一段时间内没有收到某个节点的心跳消息它会标记该节点为疑似故障PFAIL。 集群共识 当多个节点标记某个节点为 PFAIL 时其中一个节点会发起一次投票询问其他节点是否也认为该节点故障。如果大多数节点同意则该节点被标记为已知故障FAIL。
4.2.1.2、数据的保存和获取
存入数据例如存储一个键值对键名为“key”其哈希值按照 CRC16(‘key’) % 16384 6782 计算。根据这个哈希槽号数据将被存储在节点B上。获取数据无论连接哪个节点A、B、C获取键名为“key”的数据时都会根据同样的哈希算法路由到节点B上提取数据。 CRC16(‘key’) % 16384 是 Redis Cluster 中用于确定键key所属槽位的计算公式。CRC16Cyclic Redundancy Check 16是一种常用的校验算法用于检测数据传输中的错误。在 Redis Cluster 中CRC16 用于生成一个 16 位的哈希值这个哈希值可以唯一标识一个键。计算 CRC16(‘key’) 会得到一个 16 位的整数。 通过这个公式可以将键均匀地分布到 16384 个槽位中。每个槽位最终会被分配给集群中的某个主节点。
4.2.1.3、新增或删除主节点
新增节点假设新增一个节点DRedis Cluster 会将部分哈希槽从其他节点迁移至D节点。这可能导致哈希槽分布如下调整
节点A1365-5460节点B6827-10922节点C12288-16383节点D0-13645461-682610923-12287
为了平衡负载需要将一些哈希槽从现有节点A、B、C迁移到新节点 D。
删除节点删除节点时其管理的哈希槽会被迁移到其他节点上。迁移完成后该节点即可被安全移除。
4.2.2、Redis Cluster主从模式
主从的重要性为了保障数据的高可用性Redis Cluster 引入了主从模式。在这种模式下每个主节点都有一个或多个从节点。主节点处理所有的读写操作而从节点主要负责数据备份。如果主节点发生故障从节点中的一个将被提升为新的主节点以确保集群的稳定运行。未设置从节点的风险以ABC三个主节点的集群为例如果这些主节点都没有配置从节点当其中一个如B发生故障时整个集群的可用性将受到影响。A和C节点的哈希槽也将无法访问。
实例说明 在建立集群时为每个主节点配置从节点是非常重要的。例如集群包含主节点A、B、C及其对应的从节点A1、B1、C1。这样即使B节点出现故障B1节点可以被提升为新的主节点保证集群的持续运行。当B节点恢复时它将成为B1的从节点。然而需要注意的是如果B节点和其对应的从节点B1同时出现故障Redis Cluster 将无法提供服务。 4.3、cluster架构
