Redis集群模式—主从集群、哨兵集群、分片集群

主从集群

        主从模式中，包括一个主节点（Master）和一个或多个从节点（Slave）。主节点负责处理所有写操作和读操作，而从节点则复制主节点的数据，并且只能处理读操作。当主节点发生故障时，可以将一个从节点升级为主节点，实现故障转移（需要手动实现）。

以下是实现Redis主从集群的基本步骤：

1. 安装Redis

相信学到这里的人已经安装了redis，就不演示了。

2. 配置主服务器

编辑主服务器的配置文件（通常是redis.conf），确保以下设置（如果已经设置，则无需更改）：

bind：指定Redis服务器绑定的IP地址。

port：Redis服务器监听的端口号，默认为6379。

logfile：指定日志文件的路径。

dir：指定Redis数据库文件的存储目录。

daemonize yes ： 守护进程，修改为yes后即可后台运行

requirepass sdg734：密码，设置后访问Redis必须输入密码

3. 配置从服务器

对于每个从服务器，编辑其配置文件，并执行下面的命令：

slaveof <masterip> <masterport>：这里<masterip>是主服务器的IP地址，<masterport>是主服务器监听的端口号。

其他配置（如bind、requiredpass）根据需要进行设置。

4. 启动Redis服务器

在所有服务器上启动Redis服务。你可以使用Redis自带的启动脚本，或者通过命令行直接启动Redis服务器。

5. 验证配置

在主服务器上，使用INFO replication命令查看复制信息，确认没有错误。

在从服务器上，同样使用INFO replication命令，查看从服务器是否成功连接到主服务器，并正在接收数据。

总结：主从复制的有点在于好构建，简单易用，适合用于读多写少的场景。缺点在于不具备故障自动转移的能力，没有容错和不能做恢复。

哨兵集群

        为了解决主从模式的无法自动容错及恢复的问题，Redis 引入了一种哨兵模式的集群架构。
哨兵模式是在主从复制的基础上加入了哨兵节点。哨兵节点是一种特殊的 Redis 节点，用于监控主节点和从节点的状态。当主节点发生故障时，哨兵节点可以自动进行故障转移，选择一个合适的从节点升级为主节点，并通知其他从节点和应用程序进行更新。

1. 配置Redis实例

在每台选定的Redis服务器上，安装Redis。修改redis.conf文件，设置不同的端口号（例如6379, 6380, 6381等），以及配置持久化（如RDB或AOF，根据你的需求）。配置从服务器以连接到主服务器。在从服务器的redis.conf文件中添加slaveof <master-ip> <master-port>。

配置持久化：

# 开启RDB
# save ""
save 3600 1 
save 300 100
save 60 10000

# 关闭AOF
appendonly no

2. 配置哨兵

在每台选定的哨兵服务器上，创建哨兵配置文件（例如sentinel.conf）。

在哨兵配置文件中，为每个哨兵实例定义要监控的主Redis服务器。例如：

sentinel monitor mymaster <master-ip> <master-port> <quorum>

其中<quorum>是执行故障转移操作所需的最小哨兵数。

设置哨兵的其他相关参数，如down-after-milliseconds（哨兵认为Redis服务器不可用的时间），failover-timeout（故障转移超时时间）等。确保所有哨兵配置文件都是一致的。

3. 启动Redis实例和哨兵

在每台Redis服务器上启动Redis实例。

在每台哨兵服务器上启动哨兵进程，通常是通过运行redis-sentinel sentinel.conf命令。

4. 验证和测试

使用redis-cli连接到哨兵实例，并使用SENTINEL masters命令查看哨兵监控的主服务器列表。故意停止主Redis服务器，观察哨兵是否会自动将其中一个从服务器提升为主服务器，并更新其他从服务器和哨兵的配置。使用SENTINEL slaves mymaster查看当前主服务器的从服务器列表，验证从服务器是否已正确连接到新的主服务器。

5. 原理

哨兵节点定期向所有主节点和从节点发送 PING 命令，如果在指定的时间内未收到 PONG 响应，哨兵节点会将该节点标记为主观下线。如果一个主节点被多数（默认是超过哨兵节点数的一半）哨兵节点标记为主观下线，那么它将被标记为客观下线。

当主节点被标记为客观下线时，哨兵节点会触发故障转移过程。它会从所有健康的从节点中选举一个新的主节点，

并将所有从节点切换到新的主节点，实现自动故障转移。同时，哨兵节点会更新所有客户端的配置，指向新的主节点。

哨兵节点通过发布订阅功能来通知客户端有关主节点状态变化的消息。客户端收到消息后，会更新配置，将新的主节点信息应用于连接池，从而使客户端可以继续与新的主节点进行交互。

分片集群

        Redis将数据自动分片到多个部分，每个部分都有一个主节点和多个从节点。

1. 准备Redis配置文件

在每台服务器上，你都需要一个Redis配置文件（通常是redis.conf）。你可以从Redis的源代码或安装目录复制一个配置文件作为起点。

示例配置文件（redis-6379.conf）:

# 绑定到服务器的IP地址（或者注释掉这一行以监听所有地址） 
# bind 127.0.0.1 

# 设置端口 
port 6379 

# 开启集群模式 
cluster-enabled yes 

# 集群配置文件名称（Redis会自动创建和更新这个文件） 
cluster-config-file nodes-6379.conf 

# 集群节点超时时间 
cluster-node-timeout 5000 

# 开启AOF或RDB持久化（根据你的需求选择） 
appendonly yes 

 

你需要为每台服务器上的Redis实例修改port和cluster-config-file的值，以确保它们不会冲突。

2. 启动Redis实例

在每台服务器上，使用redis-server命令启动Redis实例，并指定配置文件。

# 在服务器1上 
redis-server /path/to/redis-6379.conf 

# 在服务器2上 
redis-server /path/to/redis-6380.conf 
...

3. 创建Redis集群

在任意一台服务器上，使用redis-cli的--cluster选项来创建集群。你需要指定所有Redis实例的地址和端口。

# 假设所有服务器都可以通过IP地址192.168.x.y访问，并且Redis实例分别运行在6379, 6380, ..., 6384端口 
redis-cli --cluster create 192.168.x.1:6379 192.168.x.2:6380 192.168.x.3:6381 192.168.x.4:6382 192.168.x.5:6383 192.168.x.6:6384 --cluster-replicas 1

这里的--cluster-replicas 1表示我们想要每个主节点有一个从节点。Redis Cluster会自动分配从节点到主节点。

4. 验证集群

在任意Redis实例上，使用redis-cli连接到集群，并检查集群的状态。

	redis-cli -c -h 192.168.x.1 -p 6379 

	CLUSTER INFO 

	CLUSTER NODES

-c选项表示启用集群模式，允许redis-cli自动重定向命令到正确的节点。

为了测试集群是否配置正确，你可以尝试在集群中设置和获取键值对。

	SET mykey "Hello, Redis Cluster!" 

	GET mykey

 5. 原理

在 Redis 的 分片集群模式中，使用哈希槽（hash slot）的方式来进行数据分片，将整个数据集划分为多个槽，每个槽分配给一个节点。客户端访问数据时，先计算出数据对应的槽，然后直接连接到该槽所在的节点进行操作，在该模式下，提供了自动故障转移、数据迁移和扩缩容等功能，能够比较方便地管理一个大规模的 Redis 集群。

 整个数据集划分为 16384 个槽，每个槽都有一个编号（0～16383），集群的每个节点可以负责多个 hash 槽，客户端访问数据时，先根据 key 计算出对应的槽编号，然后根据槽编号找到负责该槽的节点，向该节点发送请求。

在 Redis 的每一个节点上，都有这么两个东西，一个是槽（slot），它的的取值范围是：0-16383。还有一个就是 cluster，可以理解为是一个集群管理的插件。当我们的存取的 Key 的时候，Redis 会根据 CRC16 算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

redis的分片集群具有以下特点：
1.提升性能和吞吐量：通过在多个节点上分散数据，可以并行处理更多的操作，从而提升整体的性能和吞吐量。这在高流量场景下尤其重要，因为单个节点可能无法处理所有请求。
2.提高可扩展性：分片使得 Redis 可以水平扩展。可以通过添加更多节点扩展数据库的容量和处理能力。
3.更好的资源利用：分片允许更有效地利用服务器资源。每个节点只处理数据的一部分，这降低了单个节点的内存和计算需求。
4.避免单点故障：在没有分片的情况下，如果唯一的 Redis 服务器发生故障，整个服务可能会停止。在分片的环境中，即使一个节点出现问题，其他节点仍然可以继续运行。
5.数据高可用性：在某些分片策略中，如 Redis 集群，每个分片的数据都可以在集群内的其他节点上进行复制。这意味着即使一个节点失败，数据也不会丢失，从而提高了系统的可用性。