配置代理策略

Redis 企业软件

Redis Software 提供高性能数据访问 通过管理和优化对分片的访问的代理进程 在 Redis Software 集群中。每个节点都包含一个代理进程。 每个代理可以是主动的并接收传入流量，也可以是被动的 并等待故障转移。

代理策略

数据库可以具有以下代理策略之一：

代理策略 描述 推荐用例 优势 弊
单 只有一个代理绑定到数据库。这是默认的数据库配置。 没有高流量或负载的大多数用例 降低资源使用量，减少应用程序到集群的连接 更高的延迟，更多的网络跃点
所有主分片 多个代理绑定到数据库，托管数据库主分片的每个节点上都有一个代理。 需要多个终端节点的大多数使用案例，例如使用 OSS 集群 API 时 更低的延迟、更少的网络跃点、更高的吞吐量 更高的资源使用率，更多的应用程序到代理连接
所有节点 多个代理绑定到数据库，集群中的每个节点上都有一个代理，无论节点上是否有来自此数据库的分片。 在没有 DNS 的环境中使用负载均衡器时 更高的吞吐量 最高的资源利用率

查看代理策略

您可以使用 Cluster Manager UI、rladmin或 REST API 查看代理配置设置。

这rladmin info clustercommand 返回分片和非分片（单个分片）数据库的当前代理策略。

$ rladmin info cluster
cluster configuration:
   ...
   default_non_sharded_proxy_policy: single
   default_sharded_proxy_policy: single
   ...

Configure database proxy policy

You can use the Cluster Manager UI, the REST API, or rladmin to configure a database's proxy policy.

Warning:
Any configuration update that unbinds existing proxies can disconnect existing client connections.

Cluster Manager UI method

You can change a database's proxy policy when you create or edit a database using the Cluster Manager UI:

  1. While in edit mode on the database's configuration screen, expand the Clustering section.

  2. Select a policy from the Database proxy list.

  3. Click Create or Save.

REST API method

You can specify a proxy policy when you create a database using the REST API:

POST /v1/bdbs
{ 
  "proxy_policy": "single | all-master-shards | all-nodes",
  // Other database configuration parameters
}

To change an existing database's proxy policy, you can use an update database configuration REST API request:

PUT /v1/bdbs/<database-id>
{ "proxy_policy": "single | all-master-shards | all-nodes" }

Command-line method

You can configure a database's proxy policy using rladmin bind.

The following example changes the bind policy for a database named "db1" with an endpoint ID "1:1" to "All primary shards" proxy policy:

rladmin bind db db1 endpoint 1:1 policy all-master-shards

The next command performs the same task using the database ID instead of the name. The ID of this database is "1".

rladmin bind db db:1 endpoint 1:1 policy all-master-shards
Note:
You can find the endpoint ID for the endpoint argument by running rladmin status. Look for the endpoint ID information under the ENDPOINT section of the output.

Reapply policies after topology changes

If you want to reapply the policy after topology changes, such as node restarts, failovers and migrations, run this command to reset the policy:

rladmin bind db db:<ID> endpoint <endpoint id> policy <all-master-shards|all-nodes>

This is not required with single policies.

Other implications

During the regular operation of the cluster different actions might take place, such as automatic migration or automatic failover, which change what proxy needs to be bound to what database. When such actions take place the cluster attempts, as much as possible, to automatically change proxy bindings to adhere to the defined policies. That said, the cluster attempts to prevent any existing client connections from being disconnected, and hence might not entirely enforce the policies. In such cases, you can enforce the policy using the appropriate rladmin commands.

Multiple active proxies

Each database you create in a Redis Software cluster has an endpoint, which consists of a unique URL and port on the FQDN. This endpoint receives all the traffic for all operations for that database. By default, Redis Software binds this database endpoint to one of the proxies on a single node in the cluster. This proxy becomes an active proxy and receives all the operations for the given database. If the node with the active proxy fails, a new proxy on another node takes over as part of the failover process automatically.

In most cases, a single proxy can handle a large number of operations without consuming additional resources. However, under high load, network bandwidth, or a high rate of packets per second (PPS) on the single active proxy can become a bottleneck to how fast database operations can be performed. In such cases, having multiple active proxies across multiple nodes, mapped to the same external database endpoint, can significantly improve throughput.

You can configure a database to have multiple internal proxies, which can improve performance in some cases. Even though multiple active proxies can help improve the throughput of database operations, configuring multiple active proxies may cause additional latency in operations as the shards and proxies are spread across multiple nodes in the cluster.

Note:
When the network on a single active proxy becomes the bottleneck, consider enabling multiple NIC support in Redis Software. With nodes that have multiple physical NICs (Network Interface Cards), you can configure Redis Software to separate internal and external traffic onto independent physical NICs. For more details, refer to Multi-IP & IPv6.

Having multiple proxies for a database can improve Redis Software's ability for fast failover in case of proxy or node failure. With multiple proxies for a database, a client doesn't need to wait for the cluster to spin up another proxy and a DNS change in most cases. Instead, the client uses the next IP address in the list to connect to another proxy.

RATE THIS PAGE
Back to top ↑