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

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

Design Principles of Client Programs

PDF

Focus Mode

Font Size

Last updated: 2024-11-05 10:22:22

Avoiding database reuse
You should avoid to use one Redis instance for multiple applications.
Cause: Key eviction rules cause keys of multiple applications to affect each other, reducing cache hit rate. Meanwhile, if some applications have a large number of accesses, this will also affect the normal usage of other applications.
Suggestion: Split unrelated businesses and share common data.
Using connection pool
The total time for accessing Redis includes several parts: network connection time, command parsing time, and command execution time. By using a database with a connection pool, you can save network connection time, improve the efficiency of accessing Redis, and efficiently control the number of connections. The key configuration parameters for the connection resource pool include the maximum connections, the maximum and the minimum idle connections. We recommend that you configure these three parameters with the same value evaluated based on your actual conditions.
Maximum Connections: Control the concurrency of your business. When the number of connections in the connection pool reaches the maximum limit, the connection pool will no longer create new connections, so that the system will not be overwhelmed by resource requests from the connection pool.
Maximum Idle Connections: The maximum number of idle connections allowed in the connection pool. When the number of active connections in the connection pool exceeds the maximum idle connections, the excess connections will be closed and removed from the connection pool, freeing up system resources. This ensures that the connection pool does not consume excessive system resources and improves the performance and scalability of the application.
Minimum Idle Connections: The minimum number of idle connections that must be maintained in the connection pool. If the number of idle connections in the connection pool is lower than this value, the connection pool will create new connections to meet this requirement. This ensures that there are always enough available connections in the connection pool, especially during high load situations.
Apart from the parameters above, here is the information regarding the specific code modifications required for the hot queue connection used in different language connection pools:
Language
Issue and Suggestion
Sample Code
golang go-redis connection pool
We recommend that you put the used connections at the end of the queue, and get connections from the front of the queue to avoid always getting hot connections.
The queen connection methods and related codes are as follows:
func (p *ConnPool) popIdle() *Conn {
   if len(p.idleConns) == 0 {
      return nil
   }
﻿
   // fix get connection from head,default is back
   cn = nil
   //When `Lifo` is `true`, get the connection from the front of the line; when `Lifo` is `false`, get the connection from the end of the line.
   if p.opt.Lifo == true {
      cn = p.idleConns[0]
      p.idleConns = p.idleConns[1:]
   } else  {
      idx := len(p.idleConns) - 1
      cn = p.idleConns[idx]
      p.idleConns = p.idleConns[:idx]
   }
﻿
   p.idleConnsLen--
   p.checkMinIdleConns()
   return cn
}
For more information, see redis/go-redis . For v8.11.5 or later, the queue connection method has been fixded. Please confirm the version and the code logic to avoid hot connection.
golang redigo
Connection pool configuration
Redigo connection pool only allows you to get connections from the front of the queue and put the used connections back to the front. As a result, the hottest connection is always being used without polling each connection, and proxy connection or load is always being unbalanced. To address this issue, you need to modify the source code in the pool.go file and add pushBack method and Lifo member variables.
The sample codes are as follows:
// idle connection in the pool method, True: pushBack, False: pushFront, default False
Lifo bool
﻿
// fix add pushBack
if p.Lifo == true {
p.idle.pushBack(pc)
} else  {
p.idle.pushFront(pc)
}
For more information, see Suggestions for Using Connection Pool.
java_jedis_pool
Queue connection mode in connection pool
false: Take the connection from the front of the queue and put it back to the end, which is recommended.
true: Take the connection from the front of the queue and put it back to the front, which is the default mode and ensures that the hottest connection is always used.
Specify the regular check time for the connection pool to avoid connections being occupied for a long time without being released. It is recommended to configure it as 3000 ms, which means checking every 3 seconds.
time-between-eviction-runs: 3000ms
For the key sample code, see Sample Code of Jedis Connection Pool.
For more sample codes, see spring-boot-jedis-demo.
java_lettuce_pool
Set the queue mode of the connection pool to be the same as that of java_jedis_pool.
Disable reuse of the connection to avoid PipeLine.
﻿
We recommend that you configure the parameters as follows. For more sample codes, see java_jedis_lettuce_pool. For core codes, see RedisConfig.java and RedisProperties.java.
server:
  port: 8989 
spring:
  redis:
    database: 0
    host: 172.17.0.43
    port: 6379
    # Password, which can be left empty if there is none.
    password: ######
    # Connection timeout period in ms
    timeout: 1000
    # If jedis is used, modify lettuce to jedis.
    lettuce:
      pool:
        # Maximum wait time for getting the connection in a connection pool in ms
        max-wait: 1000ms
        # Maximum active connections, which is 8 by default.
        max-active: 2000
        # Maximum idle connections, which is 8 by default.
        max-idle: 1000
        # Minimum idle connections, which is 0 by default.
        min-idle: 500
        time-between-eviction-runs: 3000ms
        # Queue connection mode in connection pool. `false`: Take the connection from the front of the queue and put it back there; `true`: Take the connection from the front of the queue and put it back there.The hottest connection is always used, so this mode is not recommended.
        lifo: false
﻿
        #shutdown-timeout: 1000

spring_boot_redisson connection pool
Configure the maximum connections, the maximum and the minimum idle connections with the same value.
The queen connection methods and related codes are as follows:
# Single-node replica node (clusterServersConfig: Cluster mode)
singleServerConfig
 # Idle connection timeout period in ms
 idleConnectionTimeout: 10000
 Connection timeout period in ms
 connectTimeout: 10000
 Command wait timeout period in ms
 timeout: 3000
 # Retry attempts upon command failure. If the command fails to be sent to a specific node even after reaching retryAttempts, an error will be thrown.
 # If the command is sent successfully within this limit, the timeout (command wait timeout) will start counting.
 retryAttempts: 3
 # Command sending retry interval in ms
 retryInterval: 1500
 # # Reconnection intervel in ms
 # reconnectionTimeout: 3000
 # # Maximum number of failed executions
 # failedAttempts: 3
 # Password
 password: 111
 # Maximum number of subscriptions per connections
 subscriptionsPerConnection: 5
 # Client name
 clientName: cdkey
 # # Node address
 address: redis://172.20.1.20:6379
 # Minimum idle connections for publishing and subscribing connections
 subscriptionConnectionMinimumIdleSize: 1
 # pub/sub connection pool size
 subscriptionConnectionMinimumIdleSize: 1
 # Minimum idle connections
 connectionMinimumIdleSize: 1000
 # Connection pool size
 connectionPoolSize: 10000
 # Database number
 database: 0
 # DNS monitoring interval in ms
 dnsMonitoringInterval: 5000
# Number of thread pools. Default value: Number of current processing cores * 2.
threads: 64
# Number of Netty thread pools. Default value: Number of current processing cores * 2.
nettyThreads: 64
# Code
codec: !<org.redisson.codec.JsonJacksonCodec> {}
## Transfer mode
transportMode : "NIO”
For more information, see redisson/redisson.
Adding a circuit breaker
In high-concurrency scenarios, we recommend that you configure the client with acircuit breaker, such as Netflix or Hystrix. When configured, the circuit breaker  monitors the cluster nodes in real time. The abnormal Redis node will not be requested, hence avoiding the failure of the entire system caused by a single node failure.
Configuring a valid password
The database access password ensures data security. The requirements for password complexity are as follows:
It can contain [8,30] characters.
It must contain at least two of the following four types: lowercase letters, uppercase letters, digits, and symbols ()`~!@#$%^&*-+=_|{}[]:;<>,.?/.
It cannot start with a slash (/).
Tencent Cloud supports Secure Sockets Layer (SSL). For detailed directions, see SSL Encryption.
﻿

Help and Support

Was this page helpful?

You can also Contact sales or Submit a Ticket for help.

Help us improve! Rate your documentation experience in 5 mins.

Feedback

tencent cloud

Tencent Cloud Distributed Cache (Redis OSS-Compatible)

Design Principles of Client Programs

Avoiding database reuse

Using connection pool

Adding a circuit breaker

Configuring a valid password

Help and Support

Language	Issue and Suggestion	Sample Code
golang go-redis connection pool	We recommend that you put the used connections at the end of the queue, and get connections from the front of the queue to avoid always getting hot connections.	The queen connection methods and related codes are as follows: func (p ConnPool) popIdle() Conn { if len(p.idleConns) == 0 { return nil } // fix get connection from head,default is back cn = nil //When `Lifo` is `true`, get the connection from the front of the line; when `Lifo` is `false`, get the connection from the end of the line. if p.opt.Lifo == true { cn = p.idleConns[0] p.idleConns = p.idleConns[1:] } else { idx := len(p.idleConns) - 1 cn = p.idleConns[idx] p.idleConns = p.idleConns[:idx] } p.idleConnsLen-- p.checkMinIdleConns() return cn } For more information, see redis/go-redis . For v8.11.5 or later, the queue connection method has been fixded. Please confirm the version and the code logic to avoid hot connection.
golang redigo Connection pool configuration	Redigo connection pool only allows you to get connections from the front of the queue and put the used connections back to the front. As a result, the hottest connection is always being used without polling each connection, and proxy connection or load is always being unbalanced. To address this issue, you need to modify the source code in the pool.go file and add pushBack method and Lifo member variables.	The sample codes are as follows: // idle connection in the pool method, True: pushBack, False: pushFront, default False Lifo bool // fix add pushBack if p.Lifo == true { p.idle.pushBack(pc) } else { p.idle.pushFront(pc) } For more information, see Suggestions for Using Connection Pool.
java_jedis_pool	Queue connection mode in connection pool false: Take the connection from the front of the queue and put it back to the end, which is recommended. true: Take the connection from the front of the queue and put it back to the front, which is the default mode and ensures that the hottest connection is always used. Specify the regular check time for the connection pool to avoid connections being occupied for a long time without being released. It is recommended to configure it as 3000 ms, which means checking every 3 seconds. time-between-eviction-runs: 3000ms	For the key sample code, see Sample Code of Jedis Connection Pool. For more sample codes, see spring-boot-jedis-demo.
java_lettuce_pool	Set the queue mode of the connection pool to be the same as that of java_jedis_pool. Disable reuse of the connection to avoid PipeLine.	We recommend that you configure the parameters as follows. For more sample codes, see java_jedis_lettuce_pool. For core codes, see RedisConfig.java and RedisProperties.java. server: port: 8989 spring: redis: database: 0 host: 172.17.0.43 port: 6379 # Password, which can be left empty if there is none. password: ###### # Connection timeout period in ms timeout: 1000 # If jedis is used, modify lettuce to jedis. lettuce: pool: # Maximum wait time for getting the connection in a connection pool in ms max-wait: 1000ms # Maximum active connections, which is 8 by default. max-active: 2000 # Maximum idle connections, which is 8 by default. max-idle: 1000 # Minimum idle connections, which is 0 by default. min-idle: 500 time-between-eviction-runs: 3000ms # Queue connection mode in connection pool. `false`: Take the connection from the front of the queue and put it back there; `true`: Take the connection from the front of the queue and put it back there.The hottest connection is always used, so this mode is not recommended. lifo: false #shutdown-timeout: 1000
spring_boot_redisson connection pool	Configure the maximum connections, the maximum and the minimum idle connections with the same value.	The queen connection methods and related codes are as follows: # Single-node replica node (clusterServersConfig: Cluster mode) singleServerConfig # Idle connection timeout period in ms idleConnectionTimeout: 10000 Connection timeout period in ms connectTimeout: 10000 Command wait timeout period in ms timeout: 3000 # Retry attempts upon command failure. If the command fails to be sent to a specific node even after reaching retryAttempts, an error will be thrown. # If the command is sent successfully within this limit, the timeout (command wait timeout) will start counting. retryAttempts: 3 # Command sending retry interval in ms retryInterval: 1500 # # Reconnection intervel in ms # reconnectionTimeout: 3000 # # Maximum number of failed executions # failedAttempts: 3 # Password password: 111 # Maximum number of subscriptions per connections subscriptionsPerConnection: 5 # Client name clientName: cdkey # # Node address address: redis://172.20.1.20:6379 # Minimum idle connections for publishing and subscribing connections subscriptionConnectionMinimumIdleSize: 1 # pub/sub connection pool size subscriptionConnectionMinimumIdleSize: 1 # Minimum idle connections connectionMinimumIdleSize: 1000 # Connection pool size connectionPoolSize: 10000 # Database number database: 0 # DNS monitoring interval in ms dnsMonitoringInterval: 5000 # Number of thread pools. Default value: Number of current processing cores * 2. threads: 64 # Number of Netty thread pools. Default value: Number of current processing cores * 2. nettyThreads: 64 # Code codec: !<org.redisson.codec.JsonJacksonCodec> {} ## Transfer mode transportMode : "NIO” For more information, see redisson/redisson.