关于后端:Redis系列三深入解读Redis主从同步机制

首发博客地址

https://blog.zysicyj.top/

Redis高牢靠靠什么保障？

为什么要提这个呢，因为Redis主从库目标呢其实就是为了实现高牢靠。上篇文章中咱们说过Redis的AOF、RDB日志其实就是为了缩小数据失落，这是高牢靠的一部分。

这篇文章呢，咱们聊聊Redis实现高牢靠的另一方面：尽量减少服务中断。这里Redis是怎么做的呢？Redis的做法是减少正本冗余，将一份数据同时保留在多个实例上。这样某个实例挂掉并不影响其它实例提供对外服务，保障咱们的业务失常运行。

Redis有哪些伎俩进步高可用呢？

1. 数据长久化：Redis 反对多种数据长久化形式，包含快照（snapshotting）和日志（append-only file）。快照会定期将内存中的数据保留到磁盘文件，而日志会记录每次写操作，以便在重启时进行复原。这些长久化形式能够确保即便服务器意外敞开，数据也不会失落。
2. 主从复制：Redis 反对主从复制机制，其中一个 Redis 实例作为主节点，负责写操作，而其余实例作为从节点，负责复制主节点的数据。这种形式能够实现数据的备份和负载平衡，从而进步可靠性和性能。
3. Sentinel 哨兵：Redis Sentinel 是一个监控和主动故障复原零碎，能够监控 Redis 实例的衰弱状态并在主节点故障时主动进行故障切换。它能够确保零碎在主节点产生故障时可能主动切换到备用的从节点，保障服务的连续性。
4. Cluster 集群：Redis Cluster 是一种分布式系统，将数据分布在多个节点上，以进步可用性和扩展性。每个节点都持有局部数据，并且能够容忍局部节点的故障。当节点产生故障时，集群能够主动重新分配数据，确保服务的可靠性和高可用性。

如何保障正本数据统一？

首先咱们要晓得，Redis提供了主从库模式，以保障正本统一，主从库之间采纳的是读写拆散的形式。

Redis中的读写拆散基本原理和步骤

Redis 读写拆散是一种架构设计，将读操作和写操作别离路由到不同的 Redis 节点上，以进步性能和扩展性。在 Redis 读写拆散中，通常会有一个主节点负责写操作，多个从节点负责读操作。

1. 主节点（写节点）：

   • 主节点负责解决所有的写操作，包含写入、更新和删除等。
   • 写操作在主节点上执行，而后主节点将写操作的后果同步到所有从节点。

2. 从节点（读节点）：

   • 从节点负责解决读操作，例如获取数据、查问等。
   • 从节点从主节点复制数据，并在本地保留一份与主节点雷同的数据正本。

3. 读写拆散的实现：

   • 客户端依据须要的操作类型将申请散发到主节点或从节点。
   • 读操作能够通过负载平衡策略，将申请散发到不同的从节点，实现负载分担。
   • 写操作依然发送给主节点，确保数据的一致性和完整性。

须要留神的是，Redis 读写拆散并不是齐全的数据实时同步，因为从节点的数据可能会有肯定的提早。另外，读写拆散实用于大多数场景下的负载平衡和性能优化，但在一些特定状况下，例如有序汇合等简单数据结构的查问，依然须要拜访主节点。

实现 Redis 读写拆散须要正确配置主从节点的关系，以及在客户端中应用适合的策略进行读写操作的路由。同时，须要留神主节点和从节点之间的数据同步和故障解决，以确保零碎的稳定性和可靠性。

Redis主从库第一次同步是如何实现的？

1. 建设连贯： 从服务器会向主服务器发送 PSYNC 命令，示意要进行同步。主服务器收到 PSYNC 命令后，会创立一个专门用于复制的后盾线程（replication thread），并期待从服务器的连贯。

2. 全量复制（第一次同步）： 当从服务器连贯到主服务器后，主服务器会将本人的数据发送给从服务器。这个过程叫做全量复制，主服务器会遍历本人的数据集，将所有数据发送给从服务器。

   • 主服务器会在一个 RDB 文件中保留以后数据集的快照，而后将这个 RDB 文件发送给从服务器。从服务器接管到 RDB 文件后，会加载这个文件，将本人的数据集替换成主服务器的数据集。
   • 在 RDB 文件传输的过程中，主服务器会将在传输期间的写操作记录下来，称为命令流传（command propagation）。这样一来，主服务器就可能在发送完 RDB 文件后，将期间的写操作从新发送给从服务器，以保障从服务器的数据集与主服务器保持一致。
3. 增量复制： 在实现全量复制后，主从服务器之间会放弃一个 TCP 连贯，主服务器会将本人的写操作发送给从服务器，从服务器执行这些写操作，从而保持数据一致性。增量复制的数据同步是异步的，但通过记录写操作，主从服务器之间的数据最终会达到统一状态。

须要留神的是，在第一次全量复制的过程中，可能会有一些网络故障、主从服务器负载等状况影响同步。为了进步稳定性和安全性，Redis 提供了一些配置选项和机制，如长久化、复制偏移量、主服务器验证等，来确保主从复制的失常进行。

PSYNC命令

当 Redis 主从复制中的从服务器（Slave）须要与主服务器（Master）进行数据同步时，能够应用 PSYNC（Partial SYNC）命令。PSYNC 命令在 Redis 2.8 版本引入，用于进步数据同步的效率和可靠性。

PSYNC 命令包含两种模式：齐全同步（Full Sync）和局部同步（Partial Sync）。

1. 齐全同步（Full Sync）：
   齐全同步在以下状况下产生：

   • 从服务器首次连贯主服务器时。
   • 从服务器须要进行首次同步，或者复制偏移量与主服务器的偏移量差距较大时。
   • 主服务器没有保留 RDB 快照文件，所以无奈进行局部同步。

   齐全同步的过程如下：

   • 从服务器向主服务器发送一条 PSYNC 命令，并附带上本人的复制积压缓冲区的偏移量（offset）和 replid（复制 ID）。
   • 主服务器应用bgsave命令，生成RDB文件，接着将文件发给从库。
   • 从库接管到RDB文件后，会先清空以后数据库，而后加载RDB文件。

2. 局部同步（Partial Sync）：
   局部同步在以下状况下产生：

   • 从服务器曾经复制了一部分数据，并且复制偏移量与主服务器的偏移量差距较小时。

   局部同步的过程如下：

   • 主库将后续所有写操作记录到内存中的replication buffer中
   • 从服务器向主服务器发送一条 PSYNC 命令，并附带上本人的复制积压缓冲区的偏移量和 replid。
   • 主库将所有保留的写操作发送给从库，具体来说，就是当RDB发送实现后，就会把此时replication buffer中的批改发给从库，从库再从新执行这些操作。这样一来，主从库就实现同步了

PSYNC 命令的指标是在保证数据一致性的前提下，尽可能地缩小数据同步所需的数据传输量，从而进步复制效率。齐全同步和局部同步的抉择取决于从服务器与主服务器之间的复制状态和数据差距。

主库的懊恼

这里咱们能剖析失去主库做全量同步时的两个耗时操作：

1. 生成RDB文件
2. 传输RDB文件

这里构想一个场景，如果是一主多从的架构，那么主节点就要生成多份RDB并传输给从节点，很显然，这种操作是十分耗时的。这里次要占用两块资源

1. 通过fork子过程生成RDB快照会阻塞主线程解决申请
2. 传输RDB文件会占用网络带宽

那么有什么办法能够解决这些问题呢？
这里呀，咱们就引入了“主-从-从”架构，很容易了解，就是主库只须要同步一份给某从库A，其余从库从从库A同步数据。

如何了解 主-从-从 架构？

主从（Master-Slave）架构是一种常见的数据库复制和数据备份计划。在这种架构中，存在一个主数据库（主服务器）和一个或多个从数据库（从服务器），主数据库负责解决写操作和读操作，从数据库负责复制主数据库的数据，以提供读取操作和备份。

主从架构的工作形式如下：

1. 主数据库（主服务器）：

   • 主数据库是零碎的次要数据库，负责解决所有的写操作（数据的插入、更新、删除）和局部读操作。
   • 当主数据库接管到写操作时，会将这些写操作记录到本人的日志文件（例如 MySQL 的二进制日志）中，并发送给从数据库。
   • 主数据库也会保留一个复制积压缓冲区（replication backlog buffer），其中存储了一部分的写操作数据，用于满足局部同步和断线重连的需要。

2. 从数据库（从服务器）：

   • 从数据库是主数据库的复制正本，负责从主数据库复制数据以供读取操作和备份。
   • 从数据库会连贯到主数据库，并发送复制申请（如 PSYNC 命令）以获取主数据库的数据更新。
   • 从数据库会继续地复制主数据库的写操作，将写操作利用到本人的数据正本中，以放弃与主数据库的数据一致性。
   • 从数据库能够解决读取申请，从而加重主数据库的读取压力。

主从架构的劣势：

• 负载平衡： 通过将读操作分发给从数据库，能够分担主数据库的读取压力，进步整体零碎的吞吐量。
• 高可用性： 当主数据库呈现故障时，能够将其中一个从数据库晋升为新的主数据库，从而实现疾速故障切换。
• 数据备份： 从数据库能够作为主数据库的数据备份，用于复原数据和劫难复原。
• 数据分析： 从数据库能够用于读取操作，以进行数据分析、报表生成等工作，而不影响主数据库的性能。

须要留神的是，主从架构并不是齐全实时的，因为从数据库须要工夫来同步主数据库的数据更新。因而，在思考应用主从架构时，须要衡量数据一致性和性能之间的需要。

如何配置主从从架构呢

1. 装置和配置主服务器（Master）：

   • 装置Redis主服务器并确保主服务器失常运行。

   • 在主服务器的配置文件（redis.conf）中开启长久化（通常应用RDB快照或AOF日志）和监听端口，确保配置项如下：

     port 6379
     save 900 1
     appendonly yes  # 如果应用AOF日志

   • 如果须要对外提供拜访，确保防火墙或网络设置容许拜访主服务器的6379端口。

2. 装置和配置第一个从服务器（Slave1）：

   • 在从服务器1上装置Redis数据库。

   • 在从服务器1的配置文件中配置主从关系。在配置文件中增加相似如下的内容，其中masterauth是主服务器的明码，master是主服务器的IP和端口：

     slaveof master_ip master_port
     masterauth your_master_password

   • 重启从服务器1使配置失效。

3. 装置和配置第二个从服务器（Slave2）：

   • 在从服务器2上装置Redis数据库。
   • 在从服务器2的配置文件中配置主从关系，与从服务器1类似。确保配置项不抵触。
   • 重启从服务器2使配置失效。

4. 重启主服务器：

   • 在主服务器上查看主服务器的信息，如IP和端口。通常应用以下命令：

     INFO server

5. 测试主从从架构：

   • 在主服务器上进行写操作，如插入、更新或删除数据。
   • 查看从服务器1和从服务器2是否同步了主服务器的数据。

须要留神的是，Redis的主从从架构在部署和配置上与主从架构相似，只是须要在从服务器上再次配置主从关系。另外，Redis还能够配置更多高可用性的性能，如哨兵（Sentinel）和集群（Cluster），以实现更弱小的架构。具体配置细节可能会因版本和需要而有所不同，倡议参考官网文档或相干资源进行具体理解和配置。

主从库间网络断了怎么办？

在 Redis 2.8 之前，如果主从库在命令流传时呈现了网络闪断，那么，从库就会和主库从新进行一次全量复制，开销十分大。

2.8之后呢是反对增量同步的，那么Redis是怎么实现增量同步的呢？
当Redis主从库之间的网络断开后，网络复原时从库须要进行增量同步，以获取在网络断开期间主库中的更新数据。Redis实现增量同步的形式是通过Redis复制机制，具体流程如下：

1. 保留主服务器的数据： 主服务器会将更新的数据写入内存，并在内存中保留一份正本。同时，主服务器会将更新的数据写入AOF（Append-Only File）日志文件，以便在断电或宕机状况下可能进行数据恢复。
2. 记录复制偏移量： 在主服务器的复制过程中，主服务器会记录一个复制偏移量（replication offset），示意从服务器在主服务器中的数据地位。这个偏移量会随着数据的更新而递增。
3. 网络复原： 当网络复原时，从服务器会尝试连贯主服务器并申请进行复制。
4. 发送SYNC命令： 从服务器会发送SYNC命令给主服务器。如果是首次连贯复制，从服务器发送的SYNC命令中不蕴含任何参数。如果是增量同步，从服务器会发送带有偏移量参数的SYNC命令。

5. 全量复制或局部复制： 依据状况，主服务器会执行全量复制或局部复制：

   • 全量复制（首次连贯）： 如果是首次连贯复制，主服务器会执行全量复制。它会创立一个RDB快照（数据库快照），将数据库中的数据快照发送给从服务器。这样从服务器就可能领有主服务器的残缺数据集。
   • 局部复制（增量同步）： 如果是增量同步，主服务器会从记录的偏移量处开始，将从偏移量后的所有更新数据发送给从服务器。这样从服务器就可能获取在断开网络期间主服务器的更新数据。
6. 复制数据传输： 主服务器会将全量数据或增量数据通过网络传输给从服务器。从服务器会接管并解决这些数据，更新本人的数据集。
7. 复制过程持续： 一旦复制数据传输实现，从服务器会继续地与主服务器放弃连贯，接管来自主服务器的增量更新。这样，主从库之间的数据放弃同步。

须要留神的是，当网络断开工夫较长或断开期间数据更新较大时，增量同步可能会导致从服务器落后于主服务器。在网络复原后，从服务器须要足够的工夫来接管和解决更新数据，以放弃与主服务器的数据同步。

个别的排查流程

1. 查看网络连接问题： 首先，确保网络连接问题确实是造成主从库通信中断的起因。查看网络配置、防火墙规定、路由等设置，确保主从库之间能够相互拜访。
2. 从新连贯网络： 如果网络问题是临时的，你能够尝试复原网络连接，让主从库之间复原通信。
3. 查看主从状态： 在主从库网络连接复原后，应用INFO replication命令查看主从库的同步状态。确保主库已将数据同步到从库。

4. 手动从新同步： 如果主从库之间的网络断开工夫较长，能够思考进行手动从新同步：

   • 在从库上，应用SLAVEOF NO ONE命令解除从库状态。
   • 在从库上，删除长久化文件（RDB文件或AOF文件）。
   • 在从库上，执行SLAVEOF master_ip master_port命令，将其从新设置为主库的从库。
   • 在主库上，执行SLAVEOF NO ONE命令解除主库状态。
   • 在主库上，执行SLAVEOF slave_ip slave_port命令，将其从新设置为从库的主库。
5. 手动复制数据： 如果网络断开工夫较长且从新同步不可行，你可能须要手动复制数据。在主库上导出数据，并在从库上导入数据。
6. 备份和复原： 如果网络问题无奈解决，你可能须要在网络复原后思考从主库从新备份数据，而后在从库上进行数据恢复。

总结

文章中介绍了Redis主从库架构以及如何配置、保护和解决主从库网络断开的问题。以下是文章中波及到的次要内容：

1. Redis主从库架构及其保障的高可靠性：

   • Redis主从库的目标是实现高可靠性，通过数据长久化、主从复制、Sentinel哨兵和Cluster集群等形式来保障数据的安全性和可用性。

2. 如何保障正本数据统一：

   • Redis通过全量复制和局部复制（增量同步）来保障主从库之间的数据一致性。复制偏移量和复制积压缓冲区等机制用于记录和传输数据。

3. 主从库第一次同步的过程：

   • 主从库之间的第一次同步波及主服务器创立RDB快照，发送给从服务器，以及记录期间的写操作进行命令流传。

4. PSYNC命令和增量同步：

   • PSYNC命令用于主从库网络断开后的增量同步。齐全同步用于首次连贯，局部同步用于增量同步，从而缩小数据传输量。

5. 主从从架构及其劣势：

   • 主从从架构是在主从架构根底上的扩大，通过级联的形式加重主服务器的复制压力，实现更高的可用性和负载平衡。

6. 配置主从从架构的步骤：

   • 装置和配置主服务器，从服务器1和从服务器2。
   • 重启主服务器，查看主服务器信息。
   • 进行测试，验证主从库之间是否同步。

7. 解决主从库间网络断开问题：

   • 查看网络连接问题，确保主从库之间能够相互拜访。
   • 从新连贯网络，复原通信。
   • 查看主从状态，确保同步。
   • 手动从新同步，尝试复原数据一致性。
   • 手动复制数据或备份复原数据。

本文由mdnice多平台公布