Redis-Cluster查询不到key

本文探讨了在公司使用RedisCluster架构时遇到的查询不到Value的问题,分析了可能的原因,包括序列化问题、Jedis并发问题、RedisTemplate问题等,并提供了Jedis的示例代码。解决方案包括本地缓存、再次查询数据库以及配置检查。同时,文章提到了连接池的配置和Cluster查询过程。

Redis Cluster的查询不到Vlaue的原因

redis 是什么

什么是Cluster

背景:

​ 公司的Redis使用的架构是Cluster的模式,如下图模式,也是为了可扩展,还有HA,之前的生产环境都是正常的,没有任何问题的,但是最近突然发现,部分KEY 查询不到Redis数据,进行了数据库查询,量级也不是很大的,但是有个部门的新老业务进行替换的过程中,由于为了敏捷开发,快速迭代(省事,偷懒),最新的操作直接对缓存修改,没有更新数据库,如果查询不到noSql数据,就会产生脏数据,很是头疼的问题,所以要快速定位问题并解决,业务上解决也是很简单的.

解决方案

  1. 本地缓存数据 ->Redis ->Mysql
  2. Redis查询不到数据-再次查询数据->Mysql
  3. Redis查询不到数据->Nocos/(Apollo)->Mysql

业务上是可以解决问题了,但是为什么会发生查询不到的情况呢,客户端我们使用的是

[https://github.com/xetorthio/jedisJedis,]:

官方首选推荐的客户端,Maven 的包是

Jedis 介绍

在这里插入图片描述

<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.9.0</version>
    <type>jar</type>
    <scope>compile</scope>
</dependency>

官方的提供的Demo

    @Test
    public void ConnectionTest(){
   
   
        //1. Connecting to Redis server on localhost
        Jedis jedis = new Jedis("localhost");
        System
<think>好的,我现在需要回答用户关于Redis Cluster的高可用实现方式的问题。用户已经提供了一些参考资料,我需要结合这些资料和之前的知识来构建一个结构清晰、内容详实的回答。 首先,用户的问题集中在Redis Cluster的高可用配置及实现方式。根据引用中的信息,我需要涵盖架构设计、数据分片、节点通信、故障转移、扩容缩容等方面。同时,用户之前的问题是关于source命令的使用,这可能意味着他们现在在深入学习Redis集群,可能需要比较基础的讲解,但也不排除需要深入技术细节的可能。 首先,我需要回顾Redis Cluster的基本架构。根据引用[1]和[3],Redis Cluster采用去中心化结构,每个节点保存数据和集群状态,通过Gossip协议通信。数据分片使用哈希槽(hash slot)机制,共16384个槽位。高可用性主要依赖于主从复制和故障转移机制。每个主节点有一个或多个从节点,当主节点故障时,从节点能提升为主节点,保证服务不中断。 接下来,故障转移的具体流程需要详细说明。引用[1]提到Redis Cluster的故障转移过程,当节点失效时,其他节点通过PING/PONG消息检测到,超过半数主节点确认后,触发故障转移。从节点通过选举成为新主节点,更新集群配置。这个过程需要引用中的信息来支持,比如引用[3]提到投票容错机制需要超过半数节点确认故障,所以至少需要3个主节点来组成集群,防止脑裂问题。 然后是数据分片和一致性。数据分片使用哈希槽,客户端根据CRC16算法计算键的哈希值,映射到对应的槽位。节点负责处理特定槽位的数据,这确保了数据的分布和负载均衡。数据一致性方面,Redis Cluster采用异步复制,主节点写入后同步到从节点,可能存在短暂不一致,但保证了可用性。需要引用[4]中提到的配置文件设置,如cluster-config-file参数,说明节点如何维护集群状态。 扩容和缩容也是高可用的一部分。引用[2]和[4]提到了使用redis-cli工具进行集群的创建和节点的添加。扩容时,添加新节点并重新分配哈希槽;缩容时,迁移槽位并移除节点。需要详细说明步骤,如使用CLUSTER ADDSLOTS分配槽位,CLUSTER MEET添加节点,以及resharding的过程。 配置步骤方面,引用[4]给出具体的配置文件调整和启动命令,比如修改端口号、pid文件路径、目录设置等。需要整理这些配置步骤,说明如何准备节点配置文件,启动各个实例,然后使用redis-cli --cluster create命令初始化集群,并设置副本数,如引用[2]中的--cluster-replicas 1。 另外,网络分区处理是Redis Cluster高可用性的重要部分。当发生网络分区时,可能出现脑裂情况。Redis通过配置项cluster-node-timeout和cluster-slave-validity-factor来控制节点失效检测和从节点提升的时机,防止不一致。需要解释这些参数的作用,以及如何通过多数派原则解决分区问题。 最后,总结Redis Cluster如何通过上述机制实现高可用,并指出实际部署中的注意事项,如节点数量、硬件配置、监控等。同时,根据用户提供的相关问题,生成相关的扩展问题,帮助用户进一步学习。 在组织回答时,需要按照逻辑顺序,从架构设计到具体实现,再到配置步骤,逐步展开。使用用户要求的Markdown格式,分章节,使用列表和代码块示例,确保内容清晰易读。同时,正确添加引用标记,如[^1]、[^2]等,对应到用户提供的引用资料。</think>### Redis Cluster高可用实现详解 #### 一、架构设计原理 1. **去中心化架构** Redis Cluster采用去中心化设计,所有节点(主节点和从节点)通过`Gossip协议`直接通信,每个节点保存完整的数据分片信息和集群状态[^1]。 2. **数据分片机制** - **哈希槽(Hash Slot)**: 将数据划分为$16384$个槽位,通过`CRC16(key) % 16384`计算键的归属槽[^1]。 - **槽分配规则**: 每个主节点负责一部分槽位,例如: ```bash redis-cli --cluster add-node new_node_ip:port existing_node_ip:port --cluster-slots 0-5500 ``` 3. **主从复制与故障转移** - 每个主节点至少配置一个从节点(如`--cluster-replicas 1`指定副本数)[^2]。 - 主节点故障时,从节点通过**多数派投票**(需超过半数主节点确认故障)触发故障转移,提升为新主节点[^3]。 --- #### 二、高可用核心机制 1. **节点通信与心跳检测** - 节点间通过`PING/PONG`消息交换状态信息,默认每秒一次。 - 若节点在`cluster-node-timeout`(默认15秒)内无响应,标记为疑似下线(`PFail`);若超半数主节点确认,则标记为下线(`Fail`)[^1]。 2. **自动故障转移流程** ```mermaid graph TD A[主节点A失效] --> B{从节点检测到PFail} B --> C[发起投票请求] C --> D[半数主节点确认Fail] D --> E[从节点选举为新主] E --> F[更新集群元数据] ``` 3. **数据一致性保障** - **异步复制**:主节点写入后异步同步到从节点,可能丢失最后一次写入,但保障高可用[^1]。 - **读写分离**:客户端可配置从从节点读取,但需注意数据延迟风险。 --- #### 三、高可用配置步骤(以6节点为例) 1. **节点配置** 修改每个节点的`redis.conf`,关键参数: ```bash port 7001 cluster-enabled yes cluster-config-file nodes-7001.conf # 集群元数据文件[^4] cluster-node-timeout 15000 # 节点超时时间(毫秒) ``` 2. **启动集群** ```bash # 启动所有节点 redis-server /path/to/redis-7001.conf ... # 初始化集群(3主3从) redis-cli --cluster create \ 172.25.254.10:6379 172.25.254.20:6379 172.25.254.30:6379 \ 172.25.254.110:6379 172.25.254.120:6379 172.25.254.130:6379 \ --cluster-replicas 1 -a 123 # 设置副本数及密码[^2] ``` 3. **验证集群状态** ```bash redis-cli -c -p 7001 cluster nodes | grep master # 查看主节点 redis-cli -c -p 7001 cluster info # 检查集群健康状态 ``` --- #### 四、扩容与缩容操作 1. **扩容流程** - **添加新主节点**: ```bash redis-cli --cluster add-node new_node_ip:port existing_node_ip:port ``` - **迁移槽位**: ```bash redis-cli --cluster reshard existing_node_ip:port --cluster-from <old_node_id> --cluster-to <new_node_id> --cluster-slots 1000 ``` 2. **缩容流程** - **迁移槽位至其他节点**: ```bash redis-cli --cluster reshard existing_node_ip:port --cluster-from <target_node_id> --cluster-to <other_node_id> --cluster-slots 1000 ``` - **删除节点**: ```bash redis-cli --cluster del-node existing_node_ip:port <node_id> ``` --- #### 五、网络分区处理 1. **多数派原则** 若集群分裂为多个子集群,只有**持有半数以上主节点**的子集群可继续写入,防止数据冲突[^3]。 2. **恢复策略** - 网络恢复后,节点通过`Gossip协议`自动合并状态。 - 若出现数据冲突,需人工介入修复。 --- ### 相关问题 1. Redis Cluster如何通过Gossip协议优化节点通信效率? 2. 如何手动触发Redis Cluster的故障转移过程? 3. Redis Cluster与Sentinel模式在高可用实现上有何本质区别? 4. 如何监控Redis Cluster的槽位分配均衡性? 5. Redis Cluster在跨机房部署时需要注意哪些问题? --- : Redis Cluster通过数据分片和主从复制实现高可用,节点间通过Gossip协议通信[^1]。 [^2]: 使用`redis-cli --cluster create`命令初始化集群时需指定副本数[^2]。 [^3]: 至少需要3主3从共6个节点以保证故障转移的可靠性[^3]。 [^4]: 每个节点的`cluster-config-file`保存集群元数据,用于故障恢复[^4]。
评论 3
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值