redis主从

主从复制：

• 主从复制是Redis中常用的一种数据复制方式，它通过将一个Redis服务器（主节点）的数据复制到多个其他Redis服务器（从节点）上来实现数据的备份和读写分离。
• 主从复制的主要作用是提高数据的可用性和读取性能。主节点负责处理写操作和维护数据一致性，而从节点则负责提供读取服务，可以降低主节点的负载。
• 在主从复制中，所有的数据都存在于主节点上，并且通过异步复制的方式复制到从节点上。从节点可以根据需要进行故障切换，当主节点出现故障时，可以选择一个从节点提升为新的主节点，保证系统的高可用性。

主从数据同步：

1. 首先，从服务器会先向主服务器发送SYNC命令
2. 收到命令后，主服务器会执行BGSAVE命令来生成一个RDB文件，并使用AOF缓冲区来记录在生成期间执行的写命令
3. 完成第二步后，主服务器会将RDB文件发送给从服务器，让从服务器同步RDB文件数据
4. 当然这还没完，主服务器的AOF缓冲区还会发送给从服务器，让它们之间的数据同步至最终状态

在Redis的主从复制中，主节点执行的写入命令会通过命令传播机制传播到所有的从节点，以保持主从节点之间的数据一致性。命令传播的过程分为两个阶段：

1. 命令传播：主节点会将执行的写入命令发送给所有连接的从节点。这些写入命令会以类似于Redis协议的格式发送，通过网络传输到各个从节点。

2. 从节点执行：每个从节点收到主节点传播过来的写入命令后，会执行这些命令以更新自己的数据状态。从节点会按照主节点发送命令的顺序执行，并保持与主节点相同的数据状态。

如果是短时间，主从服务器断线，那怎么处理？

        使用部分重同步。

        当从节点与主节点断开后重新建立连接时，从节点会发送 PSYNC 命令给主节点，请求从上次复制偏移量之后的增量数据。如果主节点的运行 ID 与从节点的期望一致，并且主节点的挤压缓冲区队列中仍然包含从节点所需的数据，则主节点会使用部分重同步机制来向从节点发送丢失的数据，从而实现断线重连后的数据恢复和继续复制。

部分重同步主要包括以下步骤：

1. 断线重连：当从节点与主节点之间的连接断开后，从节点会尝试重新连接到主节点。

2. 发送偏移量（offset）：从节点发送一个带有自己复制偏移量的请求给主节点。这个偏移量表示了从节点上次复制的位置。

3. 主节点响应：主节点收到从节点的请求后，会检查从节点的复制偏移量是否仍然在主节点的复制缓冲区中。如果是，则主节点会发送一个部分重同步的响应给从节点。

4. 发送数据快照：主节点根据从节点的请求，将从上次复制偏移量之后的数据发送给从节点。这通常是一个 RDB 文件的数据快照，以便从节点可以使用这个快照来恢复丢失的数据。

5. 增量复制：除了发送数据快照外，主节点还会将从上次复制偏移量之后的增量数据发送给从节点。这些增量数据通常是写入命令的流水线，从节点会逐条执行这些命令以更新自己的数据状态。

这个偏移量是啥？

在 Redis 主从复制中，偏移量（offset）是指从节点在上一次复制过程中成功接收并处理的最后一条命令的位置。它是一个表示复制进度的标识，用于指示从节点需要从主节点的哪个位置开始复制数据。

具体来说，偏移量表示了从节点已经复制过的数据量。当从节点与主节点建立连接时，从节点会向主节点发送一个包含自己当前复制偏移量的请求，以告知主节点自己上一次复制到的位置。主节点收到这个请求后，会根据从节点的偏移量来判断是否需要进行部分重同步，并决定从哪个位置开始发送数据给从节点。

通过偏移量，Redis 主从复制可以精确地控制复制的进度，确保从节点可以从上一次复制的位置继续复制数据，避免重复或丢失数据。从节点会根据主节点发送的数据来更新自己的数据状态，从而保持与主节点的数据一致性。

那积压缓冲区队列呢？

在 Redis 主从复制中，挤压缓冲区队列（Backlog Buffer）是指主节点上用于存储写命令的缓冲区。这个缓冲区用于保存主节点接收到的写命令，以便在从节点断线重连后，能够重新发送丢失的写命令给从节点进行复制。

具体来说，挤压缓冲区队列的工作流程如下：

1. 写命令缓存：主节点接收到客户端的写命令后，会先将这些写命令保存到自己的挤压缓冲区队列中，然后再执行这些写命令来更新自己的数据状态。

2. 复制传播：同时，主节点会将这些写命令传播给所有连接的从节点。从节点接收到这些写命令后，会执行这些命令来更新自己的数据状态。

3. 断线重连：如果从节点与主节点之间的连接断开，从节点会尝试重新连接到主节点。在这种情况下，从节点会向主节点发送一个带有自己复制偏移量的请求，请求主节点重新发送从该复制偏移量之后的写命令。

4. 部分重同步：主节点收到从节点的请求后，会检查从节点的复制偏移量是否仍然在主节点的挤压缓冲区队列中。如果是，则主节点会将从该偏移量之后的写命令重新发送给从节点，以进行部分重同步。

那redis节点的服务器运行id是干嘛用的？

Redis 节点的服务器运行 ID（Server Run ID）是用来唯一标识一个 Redis 服务器实例的。每个 Redis 服务器在启动时都会生成一个随机的运行 ID，并在运行期间保持不变，直到服务器被关闭或重新启动。

运行 ID 主要用于以下几个方面：

1. 节点识别：运行 ID 可以用来唯一标识一个 Redis 节点，使得集群中的各个节点能够相互识别和区分。这对于集群管理、故障诊断和监控都非常重要。

2. 复制配置：在主从复制中，主节点会将自己的运行 ID 发送给从节点，以帮助从节点识别和连接主节点。从节点在连接主节点时，会使用主节点的运行 ID 来验证身份和建立复制连接。

3. 集群配置：在 Redis 集群中，每个节点都会使用自己的运行 ID 来标识自己，并在集群配置中使用这个运行 ID 来管理节点的状态和数据分片信息。

4. 监控和诊断：运行 ID 可以用于监控和诊断 Redis 服务器的运行状态。通过运行 ID，管理员可以跟踪特定服务器的运行情况，识别和解决问题。

总的来说，运行 ID 是用来唯一标识一个 Redis 服务器实例的，并在节点识别、复制配置、集群配置以及监控诊断等方面发挥着重要的作用。

那什么是redis心跳检测？

从服务器默认会每秒一次向主服务器发送命令，如果主服务器超过1s没有收到replconf命令，说明主从服务器的网络连接有问题了。

REPLCONF ACK ＜replication_offset＞

同时这个心跳检测命令还会附带传送一个复制偏移量，也就是replication_offset。

如果心跳检测时，主服务器发现他们的复制偏移量不一致，就会通过该偏移量找到从服务器丢失的写命令，发送给从服务器保持同步。

心跳检测也有检测命令丢失的功能。

总结：

其实主从主要抓住主从之间的数据同步，分为完全重同步和部分重同步。刚开始的时候是部分重同步，通过RDB文件和AOF文件进行同步，这是数据库刚启动的时候做的操作，还有一种可能是部分重同步（发送PSYNC命令）的时候发送的数据库运行id和主id不一样，说明主数据库已经换了，要跟新的主服务数据同步。数据库运行起来后，那就是通过命令传播，将写数据的命令同步到各个从服务器中，实现数据同步，在这个功能中，各个从数据库中会维护一个偏移量（offset），用于记录当前服务器同步数据的最后一条命令的位置；主数据库中，会维护一个积压缓冲区，用于存储写命令的缓冲区。这个缓冲区用于保存主节点接收到的写命令，以便在从节点断线重连后，能够重新发送丢失的写命令给从节点进行复制。