Redis主从复制原理详解

Redis主从复制原理详解

小编为大家说一说Redis主从复制原理详解的相关话题，如有不对的地方欢迎指正！

众所周知，一个数据库系统想要实现高可用，主要从以下两个方面来考虑：

1. 保证数据安全不丢失
2. 系统可以正常提供服务

而 Redis 作为一个提供高效缓存服务的数据库，也不例外。

上期我们提到的 Redis 持久化策略，其实就是为了减少服务宕机后数据丢失，以及快速恢复数据，也算是支持高可用的一种实现。

除此之外，Redis 还提供了其它几种方式来保证系统高可用，业务中最常用的莫过于主从同步（也称作主从复制）、Sentinel 哨兵机制以及 Cluster 集群。

同时，这也是面试中出现频率最高的几个主题，这期我们先来讲讲 Redis 的主从复制。

2. 主从复制简介

Redis 同时支持主从复制和读写分离：一个 Redis 实例作为主节点 Master，负责写操作。

其它实例（可能有 1 或多个）作为从节点 Slave，负责复制主节点的数据。

2.1 架构组件

主节点Master

数据更新：Master 负责处理所有的写操作，包括写入、更新和删除等。

数据同步：写操作在 Master 上执行，然后 Master 将写操作的结果同步到所有从节点 Slave 上。

从节点Slave

数据读取：Slave 负责处理读操作，例如获取数据、查询等。

数据同步：Slave 从 Master 复制数据，并在本地保存一份与主节点相同的数据副本。

2.2 为什么要读写分离

1）防止并发

从上图我们可以看出，数据是由主节点向从节点单向复制的，如果主、从节点都可以写入数据的话，那么数据的一致性如何保证呢？

有聪明的小伙伴可能已经想到了，那就是加锁！

但是主、从节点分布在不同的服务器上，数据跨节点同步时又会出现分布式一致性的问题。而在高频并发的场景下，解决加锁后往往又会带来其它的分布式问题，例如写入效率低、吞吐量大幅下降等。

而对于 Redis 这样一个高效缓存数据库来说，性能降低是难以忍受的，所以加锁不是一个优秀的方案。

那如果不加锁，使用最终一致性方式呢？

这样 Redis 在主、从库读到的数据又可能会不一致，带来业务上的挑战，用户也是难以接受的。

业务为用户服务，技术为业务服务。

所以，为了权衡数据的并发问题和用户体验，我们只允许在主节点上写入数据，从节点上读取数据。