tencent cloud

PrevNext

フィードバック

キーワードで検索してください

Recent Pages

ドキュメント
TencentDB for Redis®
    ドキュメント
    Download PDF

    Design Principles of Client Programs

    最終更新日:2024-11-05 10:22:22
    PDFファイルをダウンロード

    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.
    
    お問い合わせ

    カスタマーサービスをご提供できるため、ぜひお気軽にお問い合わせくださいませ。

    お問い合わせ
    テクニカルサポート

    さらにサポートが必要な場合は、サポートチケットを送信して弊社サポートチームにお問い合わせください。24時間365日のサポートをご提供します。

    チケットを送信
    電話サポート（24 時間365日対応）
    Copyright © 2013-2024 Tencent Cloud. All Rights Reserved.
    個人情報保護方針利用規約クッキーポリシー