Redis 进阶_redis luo-CSDN博客

本文链接：https://blog.csdn.net/luo_cc/article/details/119376568

这一块内容建议结合教学视频与官网进行学习，这里只提及一些关键词的说明

主从复制 Replication

一般搭建redis集群时使用，集群搭建一主节点（master）多个从节点(slave),从节点不可写，只能从主节点进行复制。

配置从节点

默认conf配置中启动的都是主节点，可以通过修改配置文件，主要见 Replication 一块的配置，通过配置每次启动（意外宕机重启）都会默认为从节点并链接主节点
通过命令 slaveof host port，配置当前的主节点，（每次重启都需要输入命令）

slaveof 192.168.1.1 6379

当没有主节点的节点，都是主节点（master）,

只要有主节点的节点，都是从节点（slave）

复制分类

全量复制：每次当从节点连接到主节点，都会将主节点的数据全部覆盖到从节点
增量复制：每次当主节点写入新数据时，都会同步到各个从节点

在使用 Redis 复制功能时的设置中，强烈建议在 master 和在 slave 中启用持久化。当不可能启用时，例如由于非常慢的磁盘性能而导致的延迟问题，应该配置实例来避免重置后自动重启。

slave 不会过期key，只会等待master过期进行同步

Redis 并不能保证数据的强一致性. 这意味这在实际中集群在特定的条件下可能会丢失写操作.

主从复制模型，一般最少一主二从， 3个进程

哨兵模式 Sentinel

一般做redis集群不会使用上面的基础主从复制，而是使用哨兵模式。

因为如果是集群，当master宕机或永久性挂掉时，这时候就要人员手动去设置新的master

(slave取消命令 slaveof no one)，再修改其他slave连接新的master,这样普遍不可控，并造成一段时间无法写入操作数据。

于是就出现了自动去设置master的哨兵模式。

配置启用

哨兵模式是会作为一个单独的进程去监控master,定时发送心跳,默认当master大于60秒没有回复，

自动故障迁移：

哨兵会自动认为该master宕机了（多数哨兵确认后），并发起投票，让所有哨兵进行投选出新的master(投票算法)，并将其他slave连接到新的master,当以前宕机的节点重启后，也会连接到新的master

首先需要配置一个 sentinel.conf， 具体需要见官方文件，（主要是redis实例节点的配置、心跳频率等），以下是启用哨兵最少的配置

# 监控mymaster实例，至少两个哨兵确认（如果只有一个哨兵认为宕机，不会发起投票）
sentinel monitor mymaster 127.0.0.1 6379 2
# 认为服务器已经断线所需的毫秒数
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
# 在执行故障转移时， 最多可以有多少个从服务器同时对新的主服务器进行同步， 这个数字越小， 完成故障转移所需的时间就越长。
sentinel parallel-syncs mymaster 1

sentinel monitor resque 192.168.1.3 6380 4
sentinel down-after-milliseconds resque 10000
sentinel failover-timeout resque 180000
sentinel parallel-syncs resque 5

再直接使用 redis-sentinel conf的路径进行启用哨兵，

哨兵建议至少3个且单数，双数可能会投票一致，单哨兵是怕哨兵宕机后便再无哨兵机制了，多哨兵也可互相发送心跳以确定对方是否宕机

主观下线（Subjectively Down，简称 SDOWN）指的是单个 Sentinel 实例对服务器做出的下线判断。
客观下线（Objectively Down，简称 ODOWN）指的是多个 Sentinel 实例在对同一个服务器做出 SDOWN 判断，并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后，得出的服务器下线判断。（一个 Sentinel 可以通过向另一个 Sentinel 发送 SENTINEL is-master-down-by-addr 命令来询问对方是否认为给定的服务器已下线。）

哨兵模式，一般最少一主二从三哨兵 6进程

分区 Cluster

分区主要用于数据的分片存储：

Redis 集群的数据分片

Redis 集群没有使用一致性hash, 而是引入了 哈希槽的概念.

Redis 集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽.集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:

节点 A 包含 0 到 5500号哈希槽.
节点 B 包含5501 到 11000 号哈希槽.
节点 C 包含11001 到 16384号哈希槽.

这种结构很容易添加或者删除节点. 比如如果我想新添加个节点D, 我需要从节点 A, B, C中得部分槽到D上. 如果我想移除节点A,需要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可. 由于从一个节点将哈希槽移动到另一个节点并不会停止服务,所以无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态.

具体配置与使用可以见官方文档

当一个分区宕机时，可能会造成数据缺失，redis会自动认为整个服务不可用，所以需要有一个从节点补上进行工作

分区模式一般最少三主三从 6进程