1.再谈Redis三种集群模式：主从模式、主主哨兵模式和Cluster模式
2.redis的从源哨兵模式第一次主从切换成功,再次进行主从切换就不
3.详解Redis 主从复制及主从复制原理
4.Redis 主从复制 - 源码梳理
5.Redis数据持久化机制(备份恢复)、缓存淘汰策略、实现主从同步原理、主主常见规范与优化详解
6.简介redis之主从复制

再谈Redis三种集群模式：主从模式、从源哨兵模式和Cluster模式

       在Redis的实现miniftpserver源码世界里，有三种集群模式供开发者选择：主从模式、主主哨兵模式和Cluster模式。从源每种模式都有其适用场景和特性。实现

       初始的主主主从模式通过主节点写入和从节点读取来构建，虽然基础，从源但在故障恢复上效率较低。实现一旦主节点宕机，主主需人工干预切换。从源哨兵模式则在此基础上提升，实现通过哨兵集群监控主从节点，实现故障自动恢复，提高系统的稳定性和可用性。然而，哨兵模式受限于单节点性能，不适合大规模处理。

       Redis Cluster在3.x版本后引入，通过数据分片和多节点扩展，显著提高内存利用率和写入性能，任务分销网站源码特别适用于高负载和大规模数据处理。它采用去中心化的多主多从架构，确保了数据的高可用性和扩展性。

       部署Redis时，需注意配置和节点设置，如主从节点配置、哨兵配置和Cluster模式的节点分配。在测试阶段，通过客户端和Springboot工程操作，验证数据的正确同步和读写分离。

       哨兵模式和Cluster模式都提供了高可用性和自动故障转移，但各有局限，如哨兵的在线扩容复杂，而Cluster模式对节点配置要求较高。选择哪种模式，需根据具体业务需求和性能指标来决定。

       总的来说，理解并熟练运用这三种模式，能更好地优化Redis集群的性能和稳定性，适应不同规模和复杂度的应用场景。

redis的哨兵模式第一次主从切换成功,再次进行主从切换就不

       Redis的failover命令，提供手动触发主从切换功能。此操作尤其在主服务器需要进行维护或升级时尤为重要。小区出入登记源码通过执行failover命令，可实现主节点与从节点的角色转换。一旦升级完成，执行切回操作恢复原主节点状态。

       基本语法与命令使用范例

       Redis源码版本：6.2.5

       主从切换的核心流程包括：执行failover命令启动切换（设置标记位），接着定期检测从节点的数据同步情况，直至同步完成。同步后，旧主节点与准新主节点建立连接并握手，随后发送psync failover指令，实现准新主节点的角色转换成为新主节点。

       主从切换涉及的关键变量

       深入理解主从切换前，首先要熟悉与切换相关的变量。这些变量在具体场景分析中起到关键作用。

       failover命令处理调用链

       综上所述，从节点完成数据同步的检测调用链是主从切换流程中不可或缺的部分。

       主从切换执行过程

       深入调用链分析，能够全面掌握主从切换的执行过程。

       从节点转变为主节点

       当准新主节点接收到psync failover指令，进行合法性检查（replid一致性），若合法一致，则调用replicationUnsetMaster断开与当前主节点的连接，解除副本状态，react前后端源码从而实现角色转换成为新主节点。

详解Redis 主从复制及主从复制原理

       

        Redis是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从年3月日起，Redis的开发工作由VMware主持。从年5月开始，Redis的开发由Pivotal赞助。

        概述

        在现有企业中%公司大部分使用的是redis单机服务，在实际的场景当中单一节点的redis容易面临风险。

        2、容量瓶颈。当我们有需求需要扩容 Redis 内存时，从 G 的内存升到 G，单机肯定是满足不了。当然，你可以重新买个 G 的新机器。

        解决办法

        要实现分布式数据库的更大的存储容量和承受高并发访问量，我们会将原来集中式数据库的数据分别存储到其他多个网络节点上。

        Redis 为了解决这个单一节点的问题，也会把数据复制多个副本部署到其他节点上进行复制，实现 Redis的高可用，实现对数据的冗余备份，从而保证数据和服务的高可用。

        主从复制

        什么是主从复制

        主从复制，是指将一台Redis服务器的数据，复制到其他的Redis服务器。前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。

        默认情况下，每台Redis服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

        主从复制的作用

        1、数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

        2、故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。

        3、负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应用连接主节点，读Redis数据时应用连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以大大提高Redis服务器的并发量。

        4、读写分离：可以用于实现读写分离，主库写、从库读，读写分离不仅可以提高服务器的负载能力，同时可根据需求的变化，改变从库的数量。

        5、高可用基石：除了上述作用以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis高可用的基础。

        主从复制启用

        从节点开启主从复制，有3种方式：

        1、配置文件：在从服务器的配置文件中加入 slaveof<masterip><masterport>。

        2、启动命令：redis-server启动命令后加入 --slaveof<masterip><masterport>。

        3、客户端命令：Redis服务器启动后，直接通过客户端执行命令 slaveof<masterip><masterport>，则该Redis实例成为从节点。

        通过 info replication 命令可以看到复制的一些信息。

        主从复制原理

        主从复制过程大体可以分为3个阶段：连接建立阶段（即准备阶段）、数据同步阶段、命令传播阶段。

        在从节点执行 slaveof 命令后，复制过程便开始运作，下面图示可以看出复制过程大致分为6个过程。

        主从配置之后的日志记录也可以看出这个流程。

        1、保存主节点（master）信息

        执行 slaveof 后 Redis 会打印如下日志：

        2、从节点与主节点建立网络连接

        从节点（slave）内部通过每秒运行的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与该节点建立网络连接。

        从节点与主节点建立网络连接。

        从节点会建立一个 socket 套接字，从节点建立了一个端口为的套接字，专门用于接受主节点发送的复制命令。从节点连接成功后打印如下日志：

        如果从节点无法建立连接，定时任务会无限重试直到连接成功或者执行 slaveofnoone 取消复制。

        关于连接失败，可以在从节点执行 info replication 查看 master_link_down_since_seconds 指标，它会记录与主节点连接失败的系统时间。从节点连接主节点失败时也会每秒打印如下日志，方便发现问题：

        3、发送 ping 命令

        连接建立成功后从节点发送 ping 请求进行首次通信， ping 请求主要目的如下：

        如果发送 ping 命令后，从节点没有收到主节点的 pong 回复或者超时，比如网络超时或者主节点正在阻塞无法响应命令，从节点会断开复制连接，下次定时任务会发起重连。

        从节点发送的 ping 命令成功返回，Redis 打印如下日志，并继续后续复制流程：

        4、权限验证

        如果主节点设置了 requirepass 参数，则需要密码验证，从节点必须配置 masterauth 参数保证与主节点相同的密码才能通过验证。如果验证失败复制将终止，从节点重新发起复制流程。

        5、同步数据集

        主从复制连接正常通信后，对于首次建立复制的场景，主节点会把持有的数据全部发送给从节点，这部分操作是耗时最长的步骤。

        6、命令持续复制

        当主节点把当前的数据同步给从节点后，便完成了复制的建立流程。接下来主节点会持续地把写命令发送给从节点，保证主从数据一致性。

        作者：LoyaltyLu

        链接：/a/

Redis 主从复制 - 源码梳理

       本文主要剖析Redis主从复制机制中的核心组件之一——复制积压缓冲区（Replication Buffer），旨在为读者提供一个对Redis复制流程和缓冲区机制深入理解的平台，以下内容仅基于Redis版本7.0.，若读者在使用过程中发现偏差，欢迎指正。

       复制积压缓冲区在逻辑上可理解为一个容量最大的位整数，其初始值为1，由offset、master_repl_offset和repl_backlog-histlen三个变量共同决定缓冲区的有效范围。offset表示缓冲区内命令起始位置，master_repl_offset代表结束位置，二者之间的长度由repl_backlog-histlen表示。

       每当主节点执行写命令，新生成的积压缓冲区大小增加，同时增加master_repl_offset和repl_backlog-histlen的值，直至达到预设的最大容量（默认为1MB）。一旦所有从节点接收到命令并确认同步无误，缓冲区内过期的命令将被移除，并调整offset和histlen以维持积压区容量的稳定性。

       为实现动态分配，复制积压缓冲区被分解成多个block，以链表形式组织。小狗社区源码程序每个block采用引用计数管理策略，初始值为0，每当增加或删除从节点对block的引用时，计数值相应增减。新生成block时，将master_repl_offset+1设置为block的repl_offset值，并将写入命令拷贝至缓冲区内，与此同时，master_repl_offset和repl_backlog-histlen增加。

       通过循环遍历所有从节点，为每个从节点设置ref_repl_buf_node指向当前block或最后一个block，确保主从复制能够准确传递命令。当主节点接收到从节点的连接请求时，将开始填充积压缓冲区。在全量复制阶段，从slave-replstate为WAIT_BGSAVE_START至ONLINE，表示redis从后台进程开始执行到完成RDB文件传输和加载，命令传播至此阶段正式开始。

       针对每个从节点，主节点从slave-ref_block_pos开始发送积压缓冲区内的命令，每发送成功，slave-ref_block_pos相应更新。当积压缓冲区超过预设阈值，即复制积压缓冲区中的有效长度超过repl-backlog-size（默认1MB）时，主节点将清除已发送的缓冲区，释放内存。如果主节点写入命令频繁或从节点断线重连时间长，则需合理调整缓冲区大小（推荐值为2 * second * write_size_per_second）以保持增量复制的稳定运行。

       当最后一个从节点与主节点的连接断开超过repl-backlog-ttl（默认为秒）时，主节点将释放repl_backlog和复制积压缓冲区以确保资源的有效使用。不过需要注意的是，从节点的释放操作依赖于节点是否可能成为新的主节点，因此在最后处理逻辑上需保持谨慎。

Redis数据持久化机制(备份恢复)、缓存淘汰策略、主从同步原理、常见规范与优化详解

       Redis 提供了 RDB 和 AOF 两种持久化方式，其中默认开启的是 RDB 模式。为了开启 AOF 模式，需要手动修改配置文件。RDB 是一种周期性将内存数据以快照形式保存到硬盘的机制，采用二进制压缩存储。而 AOF 以文本日志形式记录每条写入、删除请求，以追加方式写入，写入速度快，文件不易损坏。RDB 优点包括生成多个数据文件，对性能影响小，数据恢复速度快；缺点是可能导致部分数据丢失，且大文件会导致客户端卡顿。AOF 优点为数据丢失风险低，文件读取性能高，支持数据恢复；缺点是文件体积大，会降低 QPS。RDB 适合做冷备，AOF 适合做热备。在生产环境中，通常结合使用 RDB 和 AOF，先用 RDB 进行全量持久化，再用 AOF 进行增量持久化，确保在 Redis 重启时能快速恢复服务状态。对于持久化中 save 和 bgsave 的区别，save 是阻塞方式，直接保存数据，阻塞 Redis 主进程处理请求；而 bgsave 是非阻塞方式，通过 fork 子进程进行持久化，主进程继续处理请求，直到子进程完成并发送信号通知。AOF 重写机制则定期根据内存最新数据生成新 AOF 文件，以减少文件大小并提高性能。混合持久化机制在 Redis 4.0 引入，结合 RDB 和 AOF 的优点，通过在重写时生成 RDB 快照并合并增量修改，提高 Redis 启动速度。数据备份与恢复可以通过手动执行 bgsave 或 bgrewriteaof 指令，将内存数据持久化到硬盘。对于过期键的清除，Redis 提供三种策略：被动删除、主动删除和缓存淘汰策略，后者在内存使用超过 maxmemory 限制时触发。主从同步是 Redis 实现读写分离的基础，包含全量复制与增量复制两种方式。全量复制在从节点首次启动时进行，增量复制则在断开重连后仅同步部分数据，以避免大量数据传输。当主从连接断开后，Redis 会自动重连并自动补充缺少的数据，确保一致性。常见规范包括合理设计 key 命名、优化命令使用（如使用 hscan、sscan、zscan 替代 O(N)命令）、禁用对业务有负面影响的命令（如 keys、flushall）、合理使用 Redis 的多数据库功能及批量操作（如 mget、mset 或 pipeline）以提高效率，避免过多依赖 Redis 事务功能，可使用 Lua 脚本替代。线程池最大连接数设计时需考虑 Redis 的处理能力，合理设置以优化性能。

简介redis之主从复制

        redis的高可靠性体现在:

        1.数据尽量少丢失

        2.服务尽量少中断

        前者体现在AOF日志和RDB快照的数据可持久化手段上，而后者是增加副本的冗余量，即将一份数据保存在多个实例上(即使一个实例挂掉，其他实例也能对外服务，也就是主从复制)

        实验（一主一从）

        准备:相同的redis.conf文件

        文件夹创建:

        编写master.sh和slave.sh（注意slave.sh修改端口 -p或者不加）

        启动master容器并验证

        退出记录容器IP

        进入slave文件夹修改redis.conf

        运行slave容器并进入查看slave的实例有没有name键

        查看master和slave日志

        提示success

        根据master日志我们看看

        1.Ready to accept connections，Replica ..0.3: asks for synchronization

        2.Full resync requested by replica ..0.3:

        .

        3.RDB: 6 MB of memory used by copy-on-write

        试试向主库写入数据

        redis的解决方案就是使用增量复制

        实验

        查看日志

        我们看到从库宕机重连后并没有进行再一次的全量复制，而是将增加后的数据发给从库。

        当主从断连后，主库会把断链期间收到的写命令写入replication buffer(上面有提到)，同时也会写入repl_backlog_buffer这个缓冲区。

        repl_backlog_buffer是一个环形缓冲区(类似mysql的redolog)，主库记录自己写到的位置，从库记录自己读到的位置。

        从repl_backlog_buffer偏移位置出发:

        1.刚开始主从库都位于repl_backlog_buffer的起始位置

        2.主库不断接受写操作，主库的repl_backlog_buffer位置发生偏移master_repl_offset

        3.从库复制写命令也不断偏移slave_repl_offset

        4.从库断开连接后重连，除了发送psync命令还会发送slave_repl_offset

        5.主库计算master_repl_offset和slave_repl_offset偏移差，并将期间的命令发送给从库(set sex 1)

        因为是环形的，那么写满后再写入，那么最先写入repl_backlog_buffer的就会被覆盖，出现主从数据不一致的情况

如何设置配置中的repl_backlog_size就显得很重要

        -主从复制第一次采用全量复制当从库数量太多，如何分担主库压力

Redis 哨兵模式 - 源码梳理

       本文以Redis 7.0.版本为基准，如有不妥之处，敬请指正。

       哨兵模式的代码流程逻辑如下：哨兵节点每秒（主从切换时为1秒）向已知的主节点和从节点发送info命令。接收到主节点的info回复后，解析其中的slave字段信息，进而创建相应的从节点instance。收到从节点的info回复后，解析其中的slave_master_host、slave_master_port、slave_master_link_status、slave_priority、slave_repl_offset、replica_announced等信息（步骤2和sentinelInfoReplyCallback）。

       在sentinel.masters的初始数据中，来自于sentinel.conf中的monitor，利用info命令探测主节点及其所属的从节点。通过订阅__sentinel__:hello频道，获取其他哨兵节点的信息。其中，link->act_ping_time表示最早一次未收到回复的ping请求发送时间，收到回复后其会被重置为0。因此，其不为0时，表示有未收到回复的ping请求。link->last_avail_time表示最近一次收到对ping有效回复的时间，link->last_pong_time表示最近一次收到对ping回复（有效和无效）的时间，link->pc_last_activity表示最近一次收到publish的消息，ri->role_reported_time表示最近一次收到info且回复中role相比于上次发生改变的时间。

       Raft一致性算法

       thesecretlivesofdata.com...