tencent cloud

Feedback

Design Principles of Client Programs

Last updated: 2023-10-20 10:49:47

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.

Contact Us

Contact our sales team or business advisors to help your business.

Technical Support

Open a ticket if you're looking for further assistance. Our Ticket is 7x24 avaliable.

7x24 Phone Support