Problem Index
How to Connect to a Distributed Cache Database Instance?
Distributed Cache supports connections through multiple methods such as client tools, DMC, and multi-language SDKs.
Private network connection
When an instance is connected to through a CVM in the same VPC, the latency is typically less than 1 ms. Connection methods:
redis-cli -h <private network address of the instance> -p <port> -a <password>
Public network connection
To access an instance from a local or non-Tencent Cloud environment, you can enable a public network access address in the console. For security purposes, consider the following measures for public network connections:
Configure security group rules to allow access only from specific IP address ranges.
Enable SSL encryption to ensure data transmission security.
Use a strong password policy and change passwords regularly.
Connecting via visualization tools
You can manage instances through visualization tools such as Redis Desktop Manager. To use these tools, you can provide a connection address externally by using a CVM as a jump server.
Note:
Public network connections may incur additional network latency. For production environments, use private network connections whenever possible. For SDK examples in multiple languages, see Connecting to Database Instances. Can a Private Network Be Used to Connect CVM and Instances?
Yes, but the following conditions must be met simultaneously:
The CVM and database instance belong to the same account.
Both are in the same VPC (ensuring the same region), or both are in the basic network.
You can view the network information of a CVM on the instance list or details page in the CVM console. You can view the network information of a distributed cache database instance on the instance list or details page in the Redis console. What Should I Do If CVM and Instances Are Not in the Same VPC?
You can connect to instances through CCN. For CVMs and databases in different VPCs (including the same/different accounts and the same/different regions), you can establish private network connections through CCN.
Can CVM and Instances Directly Access Each Other over a Private Network Across Different Regions?
No. Different regions belong to different VPC networks, so direct private network access is not possible. We recommend that you establish CCN between the two VPC networks to achieve interconnection.
Can a Private Network Be Used for Connections Across Different AZs in the Same Region?
You need to check whether they are in the same VPC:
If they are in different AZs of the same VPC, they can communicate over the private network.
If they are in different VPCs (such as VPC1 and VPC2), direct private network interconnection is not possible. You need to resolve this through CCN or by changing the network.
Can CVM and Instances Under Different Accounts Directly Connect over a Private Network?
No. Resources under different accounts are in different VPCs, so direct private network connection is not possible. We recommend that you use CCN to interconnect VPCs across accounts.
How to Troubleshoot Public Network Connection Failures to an Instance?
If you cannot connect to an instance over the public network, perform the following checks one by one:
1. Confirm that the public network access address is enabled for the instance. Log in to the Redis console and check whether the public network address is enabled in the network information on the instance details page. 2. Check whether the security group rule allows access from public IP addresses. Confirm that the inbound rule of the security group allows access from your client IP address and the instance port (6379 by default).
3. Confirm whether the network where the client resides can access the public network. You can test network connectivity by running telnet <public address> <port>.
4. Confirm that the password format in the connection command is correct. If password-free access is enabled for the instance, the -a parameter is not required. If a password is set, the format is -a <password> for the standard architecture and -a <account name>:<password> for the multi-account mode of the cluster architecture.
How to Check Port Connectivity of an Instance?
You can use the telnet command to check port connectivity:
telnet <instance address> <port>
If the connection is successful, the port is reachable. If the connection times out or is refused, check the security group rules and network configuration.
How to Ensure Secure Data Transfer for Instances?
Distributed Cache provides multi-level data security mechanisms:
Network Isolation
Instances are deployed in your VPC. Network isolation ensures that an instance is visible only to resources within the specified VPC and cannot be directly accessed from external networks.
Access Control
Security group: You can configure security group rules to precisely control the IP addresses and port ranges that are allowed to access the instance.
Password authentication: You can set an instance password or enable password-free access. The cluster architecture supports multi-account permission control.
High-Risk Command Disabling: You can disable high-risk commands such as FLUSHALL and KEYS in the console to prevent data loss caused by accidental operations.
Transmission Encryption
SSL/TLS encrypted connections can be enabled to encrypt data transmission between clients and instances, preventing data theft or tampering during transmission. This is suitable for scenarios with strict data transmission security requirements, such as finance and government affairs.
How to Systematically Troubleshoot Client Connection Failures to an Instance?
If the client cannot connect to the instance, we recommend that you perform systematic troubleshooting in the following order:
Step 1: Check the instance status
Log in to the console and check whether the instance is in the Running state. If the instance is in the Isolated, Recycled, or Creating state, the connection cannot be established.
Step 2: Check the connection address and port
Verify that the IP address and port used in the connection command match those displayed on the instance details page:
Use the private network address for private network access, and use the public network address for public network access.
The default port is 6379. If you have changed the port, use the actual port instead.
For cluster architecture, use the Proxy address instead of the node direct connection address.
Step 3: Check network connectivity
Run the telnet <instance address> <port> command from the client to test whether the port is reachable.
If telnet fails, check whether the inbound rules of the security group allow access from the client IP address and to the instance port.
Confirm that the client and the instance are in the same VPC (or connected through CCN).
Step 4: Check authentication information
Confirm that the password format is correct. In the multi-account mode of the cluster architecture, the format is <account name>:<password>.
If password-free access is enabled for the instance, the -a parameter is not required in the connection command.
Confirm that the account has not been disabled or deleted.
Step 5: Check the maximum number of connections
View the current number of connections to the instance in the console to confirm whether the maximum limit has been reached.
If the connection limit has been reached, check for connection leaks or expand the maximum connection limit.
Step 6: Check the client configuration
Confirm that the client SDK version is compatible with the Redis engine version.
Check whether connection timeout and retry mechanisms are configured on the client.
Confirm that DNS resolution is working properly (if you connect using a domain name).
|
Connection refused
| Port not open or instance abnormal | Check the instance status and security group rules. |
Connection timed out
| Network disconnection | Check the VPC/security group/CCN configurations. |
NOAUTH Authentication required
| Password not provided | Check whether the -a parameter is correct. |
ERR invalid password
| Incorrect password | Reset the password or check the account format. |
ERR max number of clients reached
| Number of connections exceeding the limit | Release idle connections or expand capacity. |
How to Configure a Client Connection Pool?
Properly configuring the connection pool is key to ensuring connection stability and performance. The following are recommended parameters for common client connection pools:
Example of Jedis connection pool configuration:
JedisPoolConfig config = new JedisPoolConfig();
config.setMaxTotal(200);
config.setMaxIdle(200);
config.setMinIdle(10);
config.setBlockWhenExhausted(true);
config.setMaxWaitMillis(3000);
config.setTestOnBorrow(true);
config.setTestWhileIdle(true);
config.setTimeBetweenEvictionRunsMillis(30000);
Lettuce connection pool configuration recommendations:
GenericObjectPoolConfig<StatefulRedisConnection<String, String>> poolConfig =
new GenericObjectPoolConfig<>();
poolConfig.setMaxTotal(50);
poolConfig.setMaxIdle(50);
poolConfig.setMinIdle(5);
Configuration notes:
Do not exceed the instance connection limit: For the cluster architecture, the default connection limit = 10000 × the number of shards (a single shard can be increased up to 40000). For the standard architecture, the connection limit ranges from 10000 to 40000 depending on the specification. Ensure that the total number of client connections does not exceed this limit.
Avoid connection leaks: Always return connections in a finally block or try-with-resources.
Connection timeout settings: Set the connection timeout to 2-3 seconds, and set the read timeout based on the worst-case business response time (for example, 5 seconds).
Enable SSL in production: If SSL encryption is enabled on the instance, you need to enable the SSL parameter in the connection pool configuration.
How to Enable an SSL/TLS Encrypted Connection?
SSL/TLS encryption can encrypt data transmission between clients and instances, preventing man-in-the-middle attacks and data theft. For how to enable it and connection examples, see SSL Encryption.