首页 > 文章 > java教程

Redis集群搭建与Java连接实战指南

时间：2025-07-14 09:59:25 312浏览收藏

哈喽！今天心血来潮给大家带来了《Redis集群搭建及Java连接实战教程》，想必大家应该对文章都不陌生吧，那么阅读本文就都不会很困难，以下内容主要涉及到，若是你正在学习文章，千万别错过这篇文章~希望能帮助到你！

Redis集群搭建与Java客户端连接的核心在于部署多实例并使用适配的客户端库。1. 首先创建多个Redis实例目录，配置redis.conf文件启用集群模式、设置端口、日志路径、数据目录等；2. 启动所有实例后使用redis-cli工具创建集群（至少6个节点，3主3从）；3. 使用Jedis或Lettuce作为Java客户端，添加Maven依赖并通过JedisCluster类连接集群，只需提供部分节点信息即可自动发现整个集群拓扑。常见问题包括网络与防火墙配置需开放port和port+10000端口、IP绑定应根据环境选择具体IP或0.0.0.0、nodes.conf文件不可复制避免冲突、确保至少3主节点以支持故障转移、开启持久化防止数据丢失、保持节点时间同步。Java客户端通过CLUSTER SLOTS命令获取集群结构，并在遇到MOVED/ASK重定向时自动更新映射关系；合理配置连接池可优化性能；故障转移由集群内部机制处理，客户端会自动感知新主节点。相比主从模式（单点故障、无法扩展）、哨兵模式（仅实现自动故障转移、写入仍受限），集群模式具备高可用性和水平扩展能力，适用于大规模高并发场景。

Redis集群搭建与Java客户端连接详细教程

Redis集群的搭建与Java客户端的连接，核心在于理解Redis分布式存储的机制，并选择合适的客户端库进行适配。简单来说，你需要部署多台Redis实例，将它们组织成一个高可用、可扩展的集群，然后通过Java客户端（比如Jedis或Lettuce）来感知并操作这个集群。这听起来可能有些复杂，但实际上，只要掌握了关键步骤和一些常见“坑”，整个过程会顺利很多。

解决方案

要搭建Redis集群并用Java客户端连接，我们可以分两步走。

第一步：搭建Redis集群

我通常会在多台机器（或虚拟机，甚至单机多端口模拟）上进行。这里以最常见的单机多端口模拟为例，实际生产环境请部署在不同物理机上。

准备实例目录和配置文件： 为每个Redis实例创建独立的目录，例如：redis-cluster/7000, redis-cluster/7001, redis-cluster/7002, redis-cluster/7003, redis-cluster/7004, redis-cluster/7005。每个目录下放置一份 redis.conf 文件，并进行以下关键配置：

# 端口号，每个实例不同
port 7000
# 启用集群模式
cluster-enabled yes
# 集群配置文件，每个实例独立
cluster-config-file nodes-7000.conf
# 节点超时时间
cluster-node-timeout 5000
# AOF持久化，建议开启
appendonly yes
# 后台运行
daemonize yes
# 日志文件路径
logfile "7000.log"
# 数据目录
dir "/path/to/redis-cluster/7000"
# 绑定IP，如果是多机部署，这里要填实际IP，不能是127.0.0.1
# 如果是单机测试，可以留127.0.0.1，但如果Java客户端在外部，则需绑定0.0.0.0或具体IP
bind 0.0.0.0
# 保护模式，生产环境建议关闭或者配置密码
protected-mode no

依此类推，为7001到7005端口的实例修改对应的 port、cluster-config-file 和 dir。

启动所有Redis实例： 进入每个实例的目录，执行： redis-server redis.conf 确认所有实例都已启动并监听对应端口。
创建Redis集群： 当所有实例都启动后，使用 redis-cli 工具创建集群。我通常会选择至少6个实例，3主3从，这样可以保证高可用性。
```
redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1
```
--cluster-replicas 1 表示每个主节点会有一个从节点。执行命令后，它会提示你如何分配哈希槽和主从关系，输入 yes 确认即可。
验证集群状态：redis-cli -c -p 7000 cluster inforedis-cli -c -p 7000 cluster nodes 确保集群状态正常，所有节点都已连接，且主从关系正确。

第二步：Java客户端连接Redis集群

我个人比较常用Jedis，因为它上手快，社区支持也很好。Lettuce也是一个不错的选择，尤其在响应式编程方面。

添加Maven依赖（以Jedis为例）：


    redis.clients
    jedis
    3.6.0

编写Java代码连接集群：

import redis.clients.jedis.HostAndPort;
import redis.clients.jedis.JedisCluster;
import redis.clients.jedis.JedisPoolConfig;

import java.util.HashSet;
import java.util.Set;

public class RedisClusterClient {

    public static void main(String[] args) {
        Set jedisClusterNodes = new HashSet<>();
        // 只需要提供部分集群节点信息，JedisCluster会自动发现其他节点
        jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7000));
        jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7001));
        jedisClusterNodes.add(new HostAndPort("127.0.0.1", 7002));

        // 配置连接池，生产环境非常重要
        JedisPoolConfig poolConfig = new JedisPoolConfig();
        poolConfig.setMaxTotal(100); // 最大连接数
        poolConfig.setMaxIdle(20);  // 最大空闲连接数
        poolConfig.setMinIdle(5);   // 最小空闲连接数
        poolConfig.setTestOnBorrow(true); // 借用连接时是否测试
        poolConfig.setTestOnReturn(true); // 归还连接时是否测试
        poolConfig.setTestWhileIdle(true); // 空闲时是否测试

        JedisCluster jc = null;
        try {
            // 构造JedisCluster实例，传入节点信息和连接池配置
            // timeout参数是连接超时和读写超时，单位毫秒
            jc = new JedisCluster(jedisClusterNodes, 2000, 2000, 5, "your_password_if_any", poolConfig);

            // 进行一些操作
            jc.set("mykey", "Hello Redis Cluster!");
            String value = jc.get("mykey");
            System.out.println("Get 'mykey': " + value);

            jc.set("anotherkey", "This is distributed!");
            System.out.println("Get 'anotherkey': " + jc.get("anotherkey"));

            // 测试不同哈希槽的key
            jc.set("{user}:1001", "User A Data");
            jc.set("{user}:1002", "User B Data"); // 这两个key会因为哈希标签在同一个槽位

            System.out.println("Get '{user}:1001': " + jc.get("{user}:1001"));
            System.out.println("Get '{user}:1002': " + jc.get("{user}:1002"));

        } catch (Exception e) {
            System.err.println("Error connecting to Redis Cluster: " + e.getMessage());
            e.printStackTrace();
        } finally {
            if (jc != null) {
                try {
                    jc.close(); // 关闭连接，将连接返回连接池
                } catch (Exception e) {
                    System.err.println("Error closing JedisCluster: " + e.getMessage());
                }
            }
        }
    }
}

请注意，JedisCluster 的构造函数只需要提供集群中任意几个可达的节点即可，它会自动发现整个集群的拓扑结构。这很方便，你不需要列出所有节点。

Redis集群搭建有哪些常见问题或坑点？

在实际操作Redis集群时，我遇到过不少让人头疼的问题，这里我总结了一些比较常见的“坑”和它们的解决思路。

1. 网络与防火墙： 这是最常见的，也是最容易被忽视的问题。Redis集群节点之间需要互相通信，不仅需要开放你配置的 port (例如 6379)，还需要开放 port + 10000 的端口 (例如 16379) 用于集群总线通信。如果你的服务器有防火墙（如firewalld、ufw或云服务商的安全组），请务必放行这两个端口范围。我曾有一次因为云服务器安全组没开全，导致集群一直无法正常握手，排查了半天。

2. IP绑定与NAT问题： 在 redis.conf 中，bind 参数至关重要。

如果你是单机测试，bind 127.0.0.1 通常没问题。
但如果是多机部署，或者你的Java客户端不在Redis服务器本机，那么 bind 127.0.0.1 就会导致外部无法连接。你应该绑定服务器的实际IP地址，或者直接 bind 0.0.0.0 (允许所有IP连接，生产环境慎用，或配合防火墙)。
更复杂的是NAT（网络地址转换）环境。如果你的Redis节点在Docker容器内或者在一个有NAT的私有网络中，它们对外暴露的IP地址和端口可能与它们内部看到的IP地址和端口不同。这时你需要使用 cluster-announce-ip 和 cluster-announce-port 参数来告诉其他节点或客户端，自己对外应该如何被访问。这个就比较高级了，但一旦遇到，会让你抓狂。

3. nodes.conf 文件问题： 每个Redis集群节点都有一个 nodes.conf 文件，它记录了集群的拓扑结构、节点ID、IP、端口等信息。

权限问题： 确保Redis进程有权限读写这个文件所在的目录。
重复利用： 绝对不要在不同的节点之间复制 nodes.conf 文件。每个节点启动时，如果这个文件不存在，它会生成一个新的节点ID并创建文件；如果存在，它会尝试根据文件内容加入集群。如果你复制了，可能会导致节点ID冲突或集群状态混乱。
删除重建： 如果集群配置出现严重问题，或者想彻底重建集群，你需要停止所有Redis实例，删除所有实例目录下的 nodes.conf 文件，然后重新启动并创建集群。

4. 节点数量不足： Redis集群至少需要3个主节点才能正常工作（因为集群需要大多数主节点同意才能进行故障转移）。如果你只有1个或2个主节点，集群将无法创建或在节点故障时无法提供高可用性。建议至少部署3主3从共6个节点。

5. 持久化与数据丢失： 虽然集群提供了高可用性，但如果节点都宕机且没有持久化，数据还是会丢失。务必开启 appendonly yes (AOF) 或配置RDB快照，并定期备份。在集群环境中，数据分散在不同节点，单个节点的持久化配置对整个集群的健壮性至关重要。

6. 时间同步： 所有Redis集群节点的时间必须保持同步，否则可能导致集群内部对节点状态的判断出现偏差，影响故障转移的准确性。使用NTP服务同步时间是一个好习惯。

Java客户端如何高效连接Redis集群并处理故障转移？

Java客户端在连接Redis集群和处理故障转移方面，其实做得相当智能，这大大减轻了我们开发者的负担。

1. 客户端如何发现所有节点？ 像JedisCluster这样的客户端，你只需要在初始化时提供集群中任意几个（通常是3-5个就足够了）可达的节点信息。客户端拿到这些“种子”节点后，会通过这些节点去执行 CLUSTER SLOTS 命令。这个命令会返回整个集群的哈希槽分布情况，以及每个哈希槽由哪个主节点负责，其从节点又是谁。客户端拿到这个完整的集群拓扑图后，就会在内部维护一个最新的映射关系：哪个哈希槽对应哪个主节点。当集群拓扑发生变化（比如节点下线、上线、主从切换、槽位迁移），客户端会定期或在遇到MOVED/ASK重定向时更新这个拓扑图。

2. 连接池的重要性： 无论是连接单机Redis还是集群，连接池都是性能优化的关键。每次创建TCP连接和进行身份验证都是有开销的。

JedisPoolConfig 允许你配置连接池的最大连接数、最大空闲连接数、最小空闲连接数、连接测试策略等。
setMaxTotal (最大连接数)： 控制同时活跃的连接总数。设置得太小可能导致请求等待，设置得太大可能耗尽服务器资源。
setMaxIdle 和 setMinIdle： 决定了连接池中保持空闲连接的数量。保持一定数量的空闲连接可以避免频繁创建和销毁连接的开销。
setTestOnBorrow、setTestOnReturn、setTestWhileIdle： 这些测试策略可以确保你从连接池获取到的连接是“活”的，避免使用到已经失效的连接。虽然会带来一些额外开销，但在生产环境中，为了稳定性通常是值得的。我个人建议至少开启 setTestWhileIdle。

3. 读写操作与哈希槽重定向： 当Java客户端需要对一个key进行操作时，它会先计算这个key对应的哈希槽（通过CRC16算法），然后根据内部维护的槽位-节点映射关系，将请求发送到负责该槽位的主节点。

MOVED重定向： 如果客户端发送请求的节点发现这个key所属的槽位已经迁移到其他节点了（例如在集群扩容或缩容时），它会返回一个 MOVED 错误，并告诉客户端新的负责节点地址。客户端收到 MOVED 后，会更新自己的槽位映射，然后将请求重定向到正确的节点。这个过程对应用是透明的。
ASK重定向： 在槽位迁移过程中，可能会出现 ASK 重定向。这表示槽位正在迁移中，但目标key可能还在源节点上。客户端收到 ASK 后，会先连接到目标节点，发送一个 ASKING 命令，然后再发送实际的命令。这通常是临时的，用于平滑迁移。

4. 故障转移处理： Redis集群的故障转移是内置的，客户端对此是感知并适应的。

当一个主节点下线时，集群的从节点会通过Raft算法（或类似机制）选举出一个新的主节点。
客户端在尝试连接失败或收到错误时，会触发内部的集群拓扑更新机制。它会重新向集群中的其他节点发起 CLUSTER SLOTS 请求，获取最新的拓扑信息。
一旦新的主节点被选举出来并被客户端感知，所有对原来故障主节点槽位的请求都会被自动路由到新的主节点上。整个过程，应用程序通常不需要做任何修改，除非是极端情况下的网络分区或集群完全不可用。这就是Redis集群的魅力所在，它在一定程度上实现了自愈。

Redis集群模式与主从模式、哨兵模式有何不同，我该如何选择？

在Redis的世界里，高可用和可扩展性有几种不同的实现路径：主从复制、哨兵模式，以及我们今天讨论的集群模式。理解它们的区别，能帮助你根据实际业务需求做出最合适的选择。

1. 主从复制模式 (Master-Slave Replication)：

特点： 最基础的模式。一个主节点负责读写，多个从节点只负责读，并从主节点同步数据。
优点： 配置简单，读写分离，可以提高读的并发能力。
缺点： 主节点发生故障时，需要手动干预才能切换到从节点，存在单点故障。数据量受到单个主节点内存的限制，无法水平扩展。
适用场景： 对高可用性要求不高，数据量不大，或者读多写少、可以接受短暂服务中断的小型应用。

2. 哨兵模式 (Sentinel Mode)：

特点： 在主从模式的基础上，引入了“哨兵”进程。哨兵会监控主节点和从节点的状态，当主节点故障时，它能自动将一个从节点提升为新的主节点，并通知其他从节点和客户端更新配置。
优点： 实现了主节点的自动故障转移，提高了高可用性。配置相对主从复杂一些，但比集群简单。
缺点： 依然是单主节点写入，无法解决写入的水平扩展问题。数据量仍受限于单个主节点的内存。
适用场景： 对高可用性有要求，但数据量和写入并发量不是特别

今天关于《Redis集群搭建与Java连接实战指南》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！