redisCluster集群搭建 完全分布式
三台机器上搭建一个 Redis 分布式集群（Redis Cluster）。这个过程包括环境准备、Redis安装、配置修改、集群创建与验证
架构概述
假设我们有三台机器，IP地址分别为：
192.168.88.104 (Node1)
192.168.88.105 (Node2)
192.168.88.106 (Node3)
方法1：临时停止防火墙
# 停止防火墙服务
sudo systemctl stop firewalld
# 禁用防火墙开机自启
sudo systemctl disable firewalld
# 检查防火墙状态
sudo systemctl status firewalld
方法2：永久禁用防火墙
# 永久禁用防火墙服务
sudo systemctl disable firewalld
# 停止当前运行的防火墙
sudo systemctl stop firewalld
# 屏蔽防火墙服务（防止被其他服务启动）
sudo systemctl mask firewalld
验证防火墙状态
# 检查防火墙是否运行
sudo systemctl is-active firewalld
# 检查防火墙是否启用开机自启
sudo systemctl is-enabled firewalld
# 查看所有服务状态
sudo systemctl list-unit-files | grep firewalld
如果需要重新启用防火墙
# 取消屏蔽
sudo systemctl unmask firewalld
# 启用开机自启
sudo systemctl enable firewalld
# 启动防火墙
sudo systemctl start firewalld
注意事项：
安全风险：关闭防火墙会使系统更容易受到网络攻击
生产环境：不建议在生产环境中完全关闭防火墙，应该只开放必要的端口
替代方案：如果只是为了测试，可以考虑只开放特定端口而不是完全关闭防火墙
# 开放特定端口（例如开放80端口）
sudo firewall-cmd --permanent --add-port=80/tcp
sudo firewall-cmd --reload
Redis Cluster 要求至少 3个主节点 才能正常工作。为了实现高可用，我们为每个主节点配置一个从节点，这样总共需要6个Redis实例。
我们采用 三主三从 的架构，在每个节点上运行两个Redis实例（一个主，一个从，但端口不同）
物理机器 Redis实例 (主/从) 端口
192.168.88.104 Master1 6379
Slave1 (备份 Master2) 6380
192.168.88.105 Master2 6379
Slave2 (备份 Master3) 6380
192.168.88.105 Master3 6379
Slave3 (备份 Master1) 6380
注意：在实际生产中，主从交叉部署可以避免单台机器宕机导致多个主节点不可用
第一步：环境准备（所有节点）
系统要求
CentOS 7/8 或 Ubuntu 18.04+
确保三台机器网络互通，并且防火墙开放了相应的端口（6379, 6380, 以及集群总线端口 16379, 16380）。
测试环境 直接关闭防火墙
三台机器都执行
安装依赖
# CentOS/RHEL
yum install -y gcc tcl wget
下载、编译并安装 Redis
# 下载 Redis 稳定版 (请检查官网获取最新版本)
wget http://download.redis.io/releases/redis-7.2.4.tar.gz
# 解压
tar -xzvf redis-7.2.4.tar.gz
cd redis-7.2.4
# 编译并安装到 /usr/local/redis 目录
make && make install PREFIX=/usr/local/redis
===========================================================
创建实例目录
我们为每个Redis实例创建独立的目录，用于存放配置文件和持久化文件
mkdir -p /opt/redis/cluster/{6379,6380}
第二步：配置Redis实例（所有节点）
我们需要为每个端口（6379和6380）创建配置文件。
以 Node1 (192.168.88.104) 上的 6379 端口为例：
创建并编辑配置文件 /opt/redis/cluster/6379/redis.conf
vim /opt/redis/cluster/6379/redis.conf
# 端口
port 6379
# 绑定IP，改为本机IP，0.0.0.0代表允许所有连接（生产环境建议绑定内网IP）
bind 0.0.0.0
# 以守护进程运行
daemonize yes
# PID文件路径
pidfile /var/run/redis_6379.pid
# 数据持久化目录
dir /opt/redis/cluster/6379/
# 日志文件
logfile "/opt/redis/cluster/6379/redis.log"
# 开启集群模式
cluster-enabled yes
# 集群节点信息配置文件（由Redis自动生成和维护）
cluster-config-file nodes-6379.conf
# 集群节点超时时间（毫秒）
cluster-node-timeout 15000
# 开启AOF持久化
appendonly yes
# 设置密码（可选，但生产环境强烈建议设置，所有节点密码需一致）
requirepass wa123456
masterauth wa123456
vim /opt/redis/cluster/6380/redis.conf
# 端口
port 6380
# 绑定IP，改为本机IP，0.0.0.0代表允许所有连接（生产环境建议绑定内网IP）
bind 0.0.0.0
# 以守护进程运行
daemonize yes
# PID文件路径
pidfile /var/run/redis_6380.pid
# 数据持久化目录
dir /opt/redis/cluster/6380/
# 日志文件
logfile "/opt/redis/cluster/6380/redis.log"
# 开启集群模式
cluster-enabled yes
# 集群节点信息配置文件（由Redis自动生成和维护）
cluster-config-file nodes-6380.conf
# 集群节点超时时间（毫秒）
cluster-node-timeout 15000
# 开启AOF持久化
appendonly yes
# 设置密码（可选，但生产环境强烈建议设置，所有节点密码需一致）
requirepass wa123456
masterauth wa123456
同样地，为 6380 端口创建配置文件 /opt/redis/cluster/6380/redis.conf
内容与上面基本相同，只需将所有的 6379 替换为 6380。
在 Node2 和 Node3 上重复此步骤。
Node2: 修改 bind 为 192.168.88.105 (或 0.0.0.0)
Node3: 修改 bind 为 192.168.88.106 (或 0.0.0.0)
启动所有Redis实例（所有节点）
在每个节点上，分别启动两个Redis实例。
# 启动 6379 端口的实例
/usr/local/redis/bin/redis-server /opt/redis/cluster/6379/redis.conf
# 启动 6380 端口的实例
/usr/local/redis/bin/redis-server /opt/redis/cluster/6380/redis.conf
检查进程是否启动成功：
ps -ef | grep redis
你应该看到两个 redis-server 进程。
检查日志文件是否有错误：
tail -f /opt/redis/cluster/6379/redis.log
=============================
创建Redis集群
现在所有6个Redis实例都已运行，我们需要使用 redis-cli 工具将它们组成一个集群。
只需在任意一个节点上执行以下命令即可（例如在 Node1 上执行）：
/usr/local/redis/bin/redis-cli --cluster create \
192.168.88.104:6379 \
192.168.88.105:6379 \
192.168.88.106:6379 \
192.168.88.104:6380 \
192.168.88.105:6380 \
192.168.88.106:6380 \
--cluster-replicas 1 缺少AUTH 会报错 需要加 -a 选项加上秘密
/usr/local/redis/bin/redis-cli --cluster create \
192.168.88.104:6379 \
192.168.88.105:6379 \
192.168.88.106:6379 \
192.168.88.104:6380 \
192.168.88.105:6380 \
192.168.88.106:6380 \
--cluster-replicas 1 \
-a wa123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
>>> Performing hash slots allocation on 6 nodes...
Master[0] -> Slots 0 - 5460
Master[1] -> Slots 5461 - 10922
Master[2] -> Slots 10923 - 16383
Adding replica 192.168.88.105:6380 to 192.168.88.104:6379
Adding replica 192.168.88.106:6380 to 192.168.88.105:6379
Adding replica 192.168.88.104:6380 to 192.168.88.106:6379
M: 061d9d2f9ffbcbafa6c576a5d3b071e39dd4d512 192.168.88.104:6379
slots:[0-5460] (5461 slots) master
M: cda6ec0717f1b5a550cc2ebe6d8db5e23db7bf66 192.168.88.105:6379
slots:[5461-10922] (5462 slots) master
M: a5de3d0801eaae5ef92d190cddac776931b70fa7 192.168.88.106:6379
slots:[10923-16383] (5461 slots) master
S: 89c11306d0cf5074b220e3550f19c3cb6b567050 192.168.88.104:6380
replicates a5de3d0801eaae5ef92d190cddac776931b70fa7
S: d518a7478d1264b1576be5cdaaa67d3461eb0411 192.168.88.105:6380
replicates 061d9d2f9ffbcbafa6c576a5d3b071e39dd4d512
S: cce0de0b56f0f3d819d134dd084e9df284096437 192.168.88.106:6380
replicates cda6ec0717f1b5a550cc2ebe6d8db5e23db7bf66
Can I set the above configuration? (type 'yes' to accept): yes
>>> Nodes configuration updated
>>> Assign a different config epoch to each node
>>> Sending CLUSTER MEET messages to join the cluster
Waiting for the cluster to join
.
>>> Performing Cluster Check (using node 192.168.88.104:6379)
M: 061d9d2f9ffbcbafa6c576a5d3b071e39dd4d512 192.168.88.104:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
S: d518a7478d1264b1576be5cdaaa67d3461eb0411 192.168.88.105:6380
slots: (0 slots) slave
replicates 061d9d2f9ffbcbafa6c576a5d3b071e39dd4d512
M: cda6ec0717f1b5a550cc2ebe6d8db5e23db7bf66 192.168.88.105:6379
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: cce0de0b56f0f3d819d134dd084e9df284096437 192.168.88.106:6380
slots: (0 slots) slave
replicates cda6ec0717f1b5a550cc2ebe6d8db5e23db7bf66
M: a5de3d0801eaae5ef92d190cddac776931b70fa7 192.168.88.106:6379
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
S: 89c11306d0cf5074b220e3550f19c3cb6b567050 192.168.88.104:6380
slots: (0 slots) slave
replicates a5de3d0801eaae5ef92d190cddac776931b70fa7
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered. 表示 集群启动成功
连接集群并测试
使用 -c 参数以集群模式连接，它会自动重定向请求。
检查集群状态
/usr/local/redis/bin/redis-cli --cluster check 192.168.88.104:6379 -a wa123456
[root@hadoop cluster]# /usr/local/redis/bin/redis-cli --cluster check 192.168.88.104:6379 -a wa123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.88.104:6379 (34e80961...) -> 0 keys | 5461 slots | 1 slaves.
192.168.88.105:6379 (e3218340...) -> 0 keys | 5462 slots | 1 slaves.
192.168.88.106:6379 (94567c0c...) -> 0 keys | 5461 slots | 1 slaves.
[OK] 0 keys in 3 masters.
0.00 keys per slot on average.
>>> Performing Cluster Check (using node 192.168.88.104:6379)
M: 34e80961ede5527e48041f13381b37cf9253a97f 192.168.88.104:6379
slots:[0-5460] (5461 slots) master
1 additional replica(s)
S: 8fa68a6dd3579b1017dc24f9c094b78e1d23ad73 192.168.88.106:6380
slots: (0 slots) slave
replicates e32183406569ce72de499bb1ee4f13e02ab6e86d
S: 13808419666a0c374f6c8547bdc4271459f9a8f0 192.168.88.104:6380
slots: (0 slots) slave
replicates 94567c0cdf8ff7acf4f34a579eff21fcdcea0366
M: e32183406569ce72de499bb1ee4f13e02ab6e86d 192.168.88.105:6379
slots:[5461-10922] (5462 slots) master
1 additional replica(s)
S: 8745d4e47ef94628c7d6ec2e18773bce375f2755 192.168.88.105:6380
slots: (0 slots) slave
replicates 34e80961ede5527e48041f13381b37cf9253a97f
M: 94567c0cdf8ff7acf4f34a579eff21fcdcea0366 192.168.88.106:6379
slots:[10923-16383] (5461 slots) master
1 additional replica(s)
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[OK] All 16384 slots covered.
/usr/local/redis/bin/redis-cli -c -h 192.168.88.104 -p 6379
/usr/local/redis/bin/redis-cli -c -h 192.168.88.104 -p 6379
192.168.88.104:6379> 登录 不带警告是因为之前 export 了CLI的环境变量
[root@hadoop cluster]# /usr/local/redis/bin/redis-cli -c -h 192.168.88.104 -p 6379
192.168.88.104:6379> exit 登出
/usr/local/redis/bin/redis-cli -c -h 192.168.88.104 -p 6379 -a wa123456
[root@hadoop cluster]# /usr/local/redis/bin/redis-cli -c -h 192.168.88.104 -p 6379 -a wa123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
192.168.88.104:6379> 这样会带信息
查看集群节点信息
192.168.88.104:6379> cluster nodes
34e80961ede5527e48041f13381b37cf9253a97f 192.168.88.104:6379@16379 myself,master - 0 1762415700000 1 connected 0-5460
8fa68a6dd3579b1017dc24f9c094b78e1d23ad73 192.168.88.106:6380@16380 slave e32183406569ce72de499bb1ee4f13e02ab6e86d 0 1762415701248 2 connected
13808419666a0c374f6c8547bdc4271459f9a8f0 192.168.88.104:6380@16380 slave 94567c0cdf8ff7acf4f34a579eff21fcdcea0366 0 1762415699000 3 connected
e32183406569ce72de499bb1ee4f13e02ab6e86d 192.168.88.105:6379@16379 master - 0 1762415698000 2 connected 5461-10922
8745d4e47ef94628c7d6ec2e18773bce375f2755 192.168.88.105:6380@16380 slave 34e80961ede5527e48041f13381b37cf9253a97f 0 1762415700242 1 connected
94567c0cdf8ff7acf4f34a579eff21fcdcea0366 192.168.88.106:6379@16379 master - 0 1762415699228 3 connected 10923-16383
常用命令
# 连接到集群
redis-cli -c -h 192.168.88.104 -p 6379 -a wa123456
# 在Redis CLI中执行以下命令：
# 查看所有节点信息
cluster nodes
# 查看集群状态
cluster info
# 查看键所在的槽位
cluster keyslot mykey
# 查看槽位分布
cluster slots
# 查看当前节点ID
cluster myid
# 手动故障转移（在从节点执行）
cluster failover
数据操作示例
基本数据读写测试
# 连接到集群
redis-cli -c -h 192.168.88.104 -p 6379 -a wa123456
# 写入数据（会自动重定向到正确的节点）
set user:1001 "张三"
set user:1002 "刘亦菲"
set product:2001 "笔记本电脑"
# 读取数据
get user:1001
get user:1002
# 查看键所在的槽位
cluster keyslot user:1001
cluster keyslot user:1002
cluster keyslot product:2001
可视化客户端下载:
https://gitee.com/qishibo/AnotherRedisDesktopManager/releases
redis 中文在线文档
https://www.redisio.com/commands/Append.html
redis 提供了哨兵模式（Sentinel）和集群模式（Cluster），这两种模式都是为了解决 Redis 在单机模式下的一些局限性，比如单点故障、数据扩展和负载均衡等问题。下面是这两种模式的优缺点分析：
1. 哨兵模式（Sentinel）
优点：
高可用性：通过多个哨兵节点监控主节点的状态，当主节点出现故障时，自动将一个从节点晋升为主节点，保证服务的可用性。
自动故障转移：当主节点失效时，哨兵会选举出一个新的主节点，这个过程对用户透明，不需要人工干预。
监控与通知：哨兵可以监控 Redis 服务器并提供通知机制，例如通过邮件、短信等方式通知管理员。
缺点：
有限的读写扩展性：虽然提供了高可用性，但在读写扩展性方面，哨兵模式仍然受限于单个 Redis 节点的能力。如果要处理大量的读写请求，仍然需要增加更多的从节点来分担读请求。
配置复杂：相对于单机模式，配置哨兵模式需要更多的设置和考虑，比如哨兵节点的数量、配置文件等。
2. 集群模式（Cluster）
优点：
数据分片：通过数据分片，可以将数据分布在多个节点上，从而线性地扩展存储能力和处理能力。
读写分离：客户端可以连接到任一节点进行读写操作，系统内部会自动将数据路由到正确的节点。
自动故障转移：当某个节点失效时，集群会自动将该节点的数据迁移到其他节点，保证服务的持续可用。
灵活的扩容：可以动态地添加或删除节点，无需停机。
缺点：
网络开销：数据在多个节点间传输需要网络通信，这可能会增加一定的网络延迟和开销。
复杂性和配置：相比于哨兵模式，Redis 集群模式的配置更为复杂，包括节点的分配、数据的分片等。
键的重新分配：在集群中重新分配键（例如在添加或删除节点时），可能会导致暂时的性能下降。
总结
选择 Redis 的哨兵模式还是集群模式主要取决于应用的需求：
如果你的应用需要高可用性和自动故障转移，但不那么关心读写扩展性，可以选择哨兵模式。
如果你的应用需要处理大量数据和请求，并且需要线性扩展性能和存储能力，那么 Redis 集群模式是更好的选择。
在实际部署中，也可以根据具体情况采用混合模式，例如在需要高可用的部分使用哨兵模式，而在需要扩展的部分使用集群