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
Getting Started
- Quickly Creating an Instance
- Connecting to an Instance (Redis/Valkey Edition)
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
Service Agreement
- Service Level Agreement
- Terms of Service
Glossary
Contact Us

Overview

포커스 모드

폰트 크기

마지막 업데이트 시간: 2026-03-17 18:23:48

In the high availability architecture of TencentDB for Redis®, the backend ensures service continuity (such as automatic recovery after physical server downtime or network jitter) through a second-level failover mechanism. The robustness of the client connection pool becomes a key bottleneck affecting business availability.
Fault Type
Business Scenario
TencentDB for Redis® Processing Mechanism
Challenge for Client
Impact on Business
Active switchover
Compatible version upgrade, proxy version upgrade, and data migration.
It actively sends RST to reset the connection.
Detect interruption and reconnect it quickly.
Temporary jitter exists and can be quickly restored.
Passive switchover
The physical server crashes unexpectedly.
It does not actively send RST to reset the connection.
Existing connections become "dead connections", which can be removed relying on the client's keepalive mechanism.
Recovery delay depends on the keepalive efficiency of the connection pool.
To resolve the above issues, this solution provides a configuration policy for the client connection pool. Through client-side optimization, it reduces business unavailability time caused by passive switchovers from minutes to seconds, aligning with Tencent Cloud's service recovery capability.

도움말 및 지원

문제 해결에 도움이 되었나요?

더 자세한 내용은 문의하기 또는 티겟 제출 을 통해 문의할 수 있습니다.

피드백

tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

Overview

도움말 및 지원

Fault Type	Business Scenario	TencentDB for Redis^® Processing Mechanism	Challenge for Client	Impact on Business
Active switchover	Compatible version upgrade, proxy version upgrade, and data migration.	It actively sends RST to reset the connection.	Detect interruption and reconnect it quickly.	Temporary jitter exists and can be quickly restored.
Passive switchover	The physical server crashes unexpectedly.	It does not actively send RST to reset the connection.	Existing connections become "dead connections", which can be removed relying on the client's keepalive mechanism.	Recovery delay depends on the keepalive efficiency of the connection pool.