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

Glossary

Recommended Version

PDF

フォーカスモード

フォントサイズ

最終更新日: 2026-03-17 18:23:48

Redisson is a high-performance, thread-safe Redis Java client based on Netty. It provides various distributed objects and distributed services, such as distributed locks, distributed collections, and distributed queues, greatly simplifying the use of Redis in distributed environments and enabling developers to build distributed applications more conveniently.
Note:
Tencent Cloud uses a Virtual IP Address (VIP) proxy layer to uniformly shield the complexity (sharding/high availability) of the underlying Redis architecture. When accessing a Tencent Cloud Redis instance, Redisson clients can directly access the unified entry VIP provided by Tencent Cloud without the need to configure a cluster or sentinel mode, just like connecting to a single-node Redis.
Recommended Version
Through a comprehensive evaluation, Redisson 3.24.3 in standalone connection mode is recommended. This version's stability and functionality have been verified, and issues in other versions have been resolved. For details, see 3.24.3 Released.
Other Versions
Version Information
Core Issue
Fix Description
Redisson < 3.21.0
In Redis cluster mode, when backend nodes change (such as failover or scaling nodes), the Redisson client fails to properly release old node connections, which may cause connection leaks in the connection pool.
This issue has been resolved in Redisson 3.21.0. For details, see Redisson Releases History.
﻿
Redisson < 3.17.5
When replica node changes (such as HA switchover, scaling, or configuration change) occur in a Redis cluster, incorrect replica refresh may cause Redisson lock acquisition exceptions.
This issue has been resolved in Redisson 3.17.5. For details, see Error while Attempting to Set Lock.
Redisson < 3.18.1
When connection interruptions occur due to network exceptions or server crashes, if the business system is using a distributed lock, all connections that acquired the lock will remain occupied and unable to be released. The client continuously throws java.util.concurrent.CancellationException errors, eventually leading to the entire distributed lock feature becoming completely unavailable.
For the specific fix method, see Fixed - RLock Throws CancellationException Continuously.
Redisson > 3.44.0
In standalone mode, when Redisson connects to Tencent Cloud Redis and calls the tryLock method, its recently added lock renewal mechanism sends Lua scripts based on the thread count, causing cross-slot operation errors.
Note:
In Redisson cluster mode, this issue can be resolved. Still, you need to verify whether there is any exception due to conflicts between the cluster discovery mechanism and the VIP architecture during the connection establishment phase, and whether VIP switchover during instance configuration changes (like scaling) affects client stability.
To resolve this issue in standalone mode, explicitly set the lockWatchdogBatchSize parameter to 1. This configuration will force Redisson's lock batch renewal mechanism to execute Lua scripts in single-thread serialization, ensuring each renewal operation processes only one key, thereby avoiding cross-slot errors.
﻿
// There is a setLockWatchdogBatchSize in Config that can be set, for example,
public RedissonClient redissonClient(){
    Config redissonConfig = new Config();
    redissonConfig.setLockWatchdogBatchSize(1);
}

ヘルプとサポート

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

営業担当者にお問い合わせいただくかチケットを提出してサポートを求めることができます。

フィードバック

tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

Recommended Version

Recommended Version

Other Versions

ヘルプとサポート

Version Information	Core Issue	Fix Description
Redisson < 3.21.0	In Redis cluster mode, when backend nodes change (such as failover or scaling nodes), the Redisson client fails to properly release old node connections, which may cause connection leaks in the connection pool.	This issue has been resolved in Redisson 3.21.0. For details, see Redisson Releases History.
Redisson < 3.17.5	When replica node changes (such as HA switchover, scaling, or configuration change) occur in a Redis cluster, incorrect replica refresh may cause Redisson lock acquisition exceptions.	This issue has been resolved in Redisson 3.17.5. For details, see Error while Attempting to Set Lock.
Redisson < 3.18.1	When connection interruptions occur due to network exceptions or server crashes, if the business system is using a distributed lock, all connections that acquired the lock will remain occupied and unable to be released. The client continuously throws `java.util.concurrent.CancellationException` errors, eventually leading to the entire distributed lock feature becoming completely unavailable.	For the specific fix method, see Fixed - RLock Throws CancellationException Continuously.
Redisson > 3.44.0	In standalone mode, when Redisson connects to Tencent Cloud Redis and calls the tryLock method, its recently added lock renewal mechanism sends Lua scripts based on the thread count, causing cross-slot operation errors. Note: In Redisson cluster mode, this issue can be resolved. Still, you need to verify whether there is any exception due to conflicts between the cluster discovery mechanism and the VIP architecture during the connection establishment phase, and whether VIP switchover during instance configuration changes (like scaling) affects client stability.	To resolve this issue in standalone mode, explicitly set the `lockWatchdogBatchSize` parameter to 1. This configuration will force Redisson's lock batch renewal mechanism to execute Lua scripts in single-thread serialization, ensuring each renewal operation processes only one key, thereby avoiding cross-slot errors. // There is a setLockWatchdogBatchSize in Config that can be set, for example, public RedissonClient redissonClient(){ Config redissonConfig = new Config(); redissonConfig.setLockWatchdogBatchSize(1); }