tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

DocumentaçãoTencent Cloud Distributed Cache (Redis OSS-Compatible)Practical TutorialRedis Client Connection Configuration Policy and PracticeConnecting to Redis via RedissonRecommended Version

Recommended Version

PDF
Modo Foco
Tamanho da Fonte
Última atualização: 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.
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);
}
Anterior: OverviewPróximo: Parameter Configuration

Ajuda e Suporte

Esta página foi útil?

comentários