1、主从模式
- 主节点(Master):负责处理所有的写操作。
- 从节点(Slave):从主节点同步数据,可以处理读操作,提供数据冗余。
优点
- 数据冗余:通过从节点备份数据,增加数据的冗余性。
- 读写分离:从节点可以分担主节点的读取压力,提高系统的读取性能。
- 简单易用:配置和管理相对简单。
缺点
- 手动故障恢复:如果主节点故障,需要手动将一个从节点提升为主节点,无法自动切换。
- 数据丢失风险:如果主节点在数据同步过程中故障,可能会丢失部分数据。
- 单点故障:主节点是单点故障点,一旦主节点故障,整个系统可能不可用。
主从同步
从节点向主节点发送请求携带replacationid和offset,判断id是否相同,不同则做全量同步且将id更改为Redis生成的心的id,相同则做增量同步
- 全量同步:从节点启动时,会发送
PSYNC
命令(或SYNC
命令)给主节点,请求全量同步。主节点会生成一个RDB文件并通过网络发送给从节点,从节点加载RDB文件。 - 增量同步:从节点加载完RDB文件后,会记录主节点的偏移量(offset),只对offset值后面的记录进行同步,并继续接收主节点的写操作命令,保持数据的一致性。
2、哨兵模式
基本概念
- 哨兵节点(Sentinel):监控主节点和从节点的运行状态,并在主节点故障时自动进行故障转移。
- 主节点(Master):负责处理所有的写操作。
- 从节点(Slave):从主节点同步数据,可以处理读操作。
工作原理
- 监控:
-
- 哨兵节点定期向主节点和从节点发送心跳包,检测它们的健康状况。
- 哨兵节点之间也会互相通信,共享监控信息。
- 故障检测:
-
- 如果哨兵节点在一定时间内没有收到主节点的响应,会认为主节点可能故障。
- 多个哨兵节点会通过投票机制确认主节点是否真的故障。
- 故障转移和通知:
-
- 哨兵节点之间通过投票机制选举一个哨兵作为领导者。
- 领导者哨兵会选择一个从节点晋升为主节点,并通知其他哨兵和从节点更新配置。
- 哨兵节点会更新客户端的配置,使客户端能够透明地切换到新的主节点。
配置示例
- 哨兵节点配置(
sentinel.conf
):
port 26379
sentinel monitor mymaster 127.0.0.1 6379 3
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 60000
sentinel parallel-syncs mymaster 1
-
sentinel monitor mymaster 127.0.0.1 6379 2
:监控名为mymaster
的主节点,地址为127.0.0.1:6379
,需要个3哨兵节点确认主节点故障。sentinel down-after-milliseconds mymaster 5000
:如果主节点在5000毫秒内没有响应,认为主节点可能故障。sentinel failover-timeout mymaster 60000
:故障转移的超时时间为60000毫秒。sentinel parallel-syncs mymaster 1
:在故障转移时,最多允许1个从节点同时进行数据同步。
优点
- 自动故障转移:哨兵节点可以自动检测主节点故障并进行故障转移,提高系统的可用性。
- 客户端透明:客户端可以通过哨兵节点获取当前主节点的信息,实现透明的故障切换。
- 多哨兵节点:多个哨兵节点可以提高故障检测的准确性和可靠性。
缺点
- 资源消耗:哨兵节点需要额外的资源和维护,增加了系统的复杂性。
- 数据不一致:在故障转移过程中,新的主节点可能会有一段时间的数据不一致,影响数据的准确性。
- 配置复杂:哨兵模式的配置和管理相对复杂,需要配置多个哨兵节点和主从节点。
3. 集群模式(Cluster)
基本概念
- 主节点(Master):负责处理部分槽的数据读写操作。
- 从节点(Slave):作为主节点的副本,用于数据冗余和故障恢复。
- 槽(Slot):Redis集群将数据空间划分为16384个槽,每个槽可以分配给一个主节点。
Hash Slot插槽算法
既然是分布式存储,Cluster集群使用的分布式算法是一致性Hash嘛?并不是,而是Hash Slot插槽算法。
插槽算法把整个数据库被分为16384个slot(槽),每个进入Redis的键值对,根据key进行散列,分配到这16384插槽中的一个。使用的哈希映射也比较简单,用CRC16算法计算出一个16 位的值,再对16384取模。数据库中的每个键都属于这16384个槽的其中一个,集群中的每个节点都可以处理这16384个槽。
集群中的每个节点负责一部分的hash槽,比如当前集群有A、B、C个节点,每个节点上的哈希槽数 =16384/3,那么就有:
- 节点A负责0~5460号哈希槽
- 节点B负责5461~10922号哈希槽
- 节点C负责10923~16383号哈希槽
工作原理
- 数据分布:
-
- 客户端通过计算键的哈希值,确定数据应该存储在哪个槽上,进而路由到对应的主节点。
- 每个主节点可以管理多个槽,槽的分配可以通过
CLUSTER ADDSLOTS
命令进行。
- 主从复制:
-
- 每个主节点可以有一个或多个从节点,从节点会定期从主节点同步数据。
- 从节点可以通过
CLUSTER REPLICATE
命令指定要复制的主节点。
- 故障检测:
-
- 节点之间通过Gossip协议定期交换心跳信息,检测其他节点的健康状况。
- 如果一个节点在一定时间内没有收到某个节点的心跳信息,会认为该节点可能故障。
- 故障转移:
-
- 当主节点故障时,集群会自动选举一个从节点晋升为主节点,继续提供服务。
- 选举过程通过Raft一致性算法实现,确保选举的公平性和一致性。
- 动态扩缩容:
-
- 可以动态地向集群中添加新的节点,新节点会自动分配部分槽,分担现有节点的压力。
- 可以动态地从集群中移除节点,现有节点会重新分配槽,确保数据的完整性和一致性。
配置示例
- 节点配置(
redis.conf
):
port 7000
cluster-enabled yes
cluster-config-file nodes-7000.conf
cluster-node-timeout 5000
appendonly yes
- 创建集群:
redis-cli --cluster create 192.168.1.1:7000 192.168.1.2:7000 192.168.1.3:7000 --cluster-replicas 1
-
--cluster-replicas 1
:每个主节点有一个从节点。
优点
- 数据分布:通过槽分配机制,将数据均匀分布在多个节点上,实现水平扩展。
- 高可用性:通过主从复制和自动故障转移,确保系统的高可用性。
- 动态扩缩容:支持动态添加和移除节点,确保系统的扩展性和灵活性。
- 客户端透明:客户端可以通过集群模式自动路由到正确的节点,实现透明的故障切换。
缺点
- 配置复杂:集群模式的配置和管理相对复杂,需要管理多个节点。
- 某些操作受限:多键操作和事务可能会受到限制,因为它们需要在多个节点上协调。
- 网络要求高:节点之间需要频繁的通信,对网络的要求较高。