tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

Release Notes and Announcements
Release Notes
Announcements
User Tutorial
Product Introduction
Overview
Product Strengths
Use Cases
Storage Engine
Product Series
Product Versions
Specifications and Performance
Read/Write Separation
Multi-AZ Deployment
Regions and AZs
Terms
Service Regions and Service Providers
Purchase Guide
Billing Overview
Pricing Center
Instance Purchasing
Renewal (Yearly/Monthly Subscription)
Refund (Yearly/Monthly Subscription)
Overdue Payments
Switching from Pay-as-You-Go to Yearly/Monthly Subscription
Getting Started
Quickly Creating an Instance
Connecting to Redis Instance
Operation Guide
Operation Overview
Connecting to a Database Instance
Managing Instances
Upgrade Instance
Management Node (Redis/ValKey Edition)
Multi-AZ Deployment Management
Backup and Restoration
Managing Accounts
Parameter Configuration
Slow Query
Access Management
Network and Security
Monitoring and Alarms
Event Management (Redis/ValKey Edition)
Data Migration
Global Replication for Redis Edition
Database Audit
Performance Optimization
Sentinel Mode
Development Guidelines
Naming Rules
Basic Usage Guidelines
Design Principles of Key and Value
Command Usage Guidelines
Design Principles of Client Programs
Connection Pool Configuration
Command Reference
Command Reference Overview
Redis Edition and Valkey Edition Command Compatibility
Version Command Usage Differences
Differences Between the Proxy Architecture and Direct Connection Mode
More Command Operations (Redis/Valkey Edition)
Memcached Edition Command Compatibility
Practical Tutorial
Building TencentDB for Redis® Client Monitoring Based on Spring Boot
Redis Client Connection Configuration Policy and Practice
Global SCAN Guide for Cluster Architecture
Eliminating Instances Securely
Hot Key and Big Key
AZ Migration Scheme
Troubleshooting
Connection Exception
Exception Analysis and Solution of Redisson Client Timeout Reconnection
Performance Troubleshooting and Fine-Tuning
API Documentation
History
Introduction
API Category
Making API Requests
Instance APIs
Parameter Management APIs
Other APIs
Backup and Restoration APIs
Region APIs
Monitoring and Management APIs
Log APIs
Data Types
Error Codes
FAQs
General
Connection and Login
Purchase
Service Agreement
Service Level Agreement
Terms of Service
Glossary
Contact Us

Recommended Version

PDF
フォーカスモード
フォントサイズ
最終更新日: 2026-03-17 18:23:48
Lettuce is a high-performance, asynchronous, non-blocking Redis Java client. It supports multiple Redis data structures and commands, significantly improving the operation performance and response speed of Redis. It is particularly suitable for high-concurrency scenarios.
Note:
Tencent Cloud uses a VPC IP proxy layer to uniformly shield the complexity (sharding/high availability) of the underlying Redis architecture. When accessing a Tencent Cloud Redis instance, clients can directly connect to the unified entry (VPC IP) provided by Tencent Cloud, without needing to configure a cluster or sentinel mode, just like connecting to a single-node Redis.

Design Flaws of the Lettuce Client

Starting from Spring Boot 2.x, Lettuce replaced Jedis as the default Redis client. Lettuce's default configuration works in standard Redis deployments but has a compatibility gap with Tencent Cloud VIP's transparent high availability architecture. It is required to forcibly enable the keepAlive and tcpUserTimeout parameters to ensure the client connection pool can respond promptly to backend switchovers. Otherwise, the client will remain unavailable after failover. For details, see the table below.
Fault Type
Business Scenario
Lettuce Version
Core Issue
Active switchover
Compatible version upgrade, proxy version upgrade, and data migration.
Lettuce versions before 6.1.05
TCP Keepalive (to detect whether idle connections are alive) is not enabled by default, causing the client connection pool to be unaware of backend VIP switchovers. Old connections remain in the pool. Even after the server completes the switchover, the client continues to use invalid connections and throws errors.
Passive switchover
The physical server crashes unexpectedly.
Lettuce versions before 6.3.0
If the TCP_USER_TIMEOUT parameter is unconfigured, when the network is interrupted or a node goes down, the operating system may maintain half-open connections for a long time (not less than 30 minutes by default). The client connection pool cannot promptly reclaim these zombie connections, resulting in continuous errors.

Recommended Version

Lettuce 6.3.0 in standalone connection mode is recommended. In this version, the issue that connection pools cannot respond promptly to backend active and passive switchovers has been resolved. Configure the keepAlive and tcpUserTimeout parameters as follows.
SocketOptions socketOptions = SocketOptions.builder()
.keepAlive(SocketOptions.KeepAliveOptions.builder()
// Time interval between two keepalives.
.idle(Duration.ofSeconds(TCP_KEEPALIVE_TIME))
// How long a connection remains idle before keepalive is started.
.interval(Duration.ofSeconds(TCP_KEEPALIVE_TIME/3))
// Number of keepalives sent before the connection is disabled.
.count(3)
// Whether to enable keepalive connection.
.enable()
.build())
.tcpUserTimeout(SocketOptions.TcpUserTimeoutOptions.builder()
// Resolve the long timeout issue caused by server rst.
.tcpUserTimeout(Duration.ofSeconds(TCP_USER_TIMEOUT))
.enable()
.build())
// Set TCP connection timeout.
.connectTimeout(Duration.ofMillis(redisConnectTimeout))
.build();

ヘルプとサポート

この記事はお役に立ちましたか?

フィードバック