DCS Redis Help Documentation

FAQs About Product Features

2024-05-25 02:10:30

What Is the Relationship Between DCS Redis and Open Source Redis?

DCS Redis is a cloud-native, high-performance, and in-memory database service that is fully compatible with open source Redis.

You can use Redis-compatible clients to perform operations such as establishing connections to and storing data in DCS Redis instances.

Does a DCS Redis Instance Have Limits on CPU Processing Capability, Data Transmission Bandwidth, and the Number of Connections?

Yes. A DCS Redis instance has limits on CPU processing capability, uplink/downlink data transmission bandwidth, and the number of connections.

The performance parameters vary for different types of instances. For more information, see Specifications. You can also view the information on the Purchase page.

How Many Databases Does a Single Redis Instance Support?

By default, a single DCS Redis instance supports up to 256 databases.

Description

A single Redis cluster instance also supports up to 256 databases by default.

Do All Redis Instances Have Active and Standby Nodes?

All Redis instances including cluster instances configured with an active-standby architecture have active and standby nodes. Stand-alone instances only have active nodes. For details, see Overview of Instance Types.

The currently supported instance specifications include standard version - stand-alone, standard version - active/standby, cluster version - stand-alone, and cluster version - active/standby. You can select different specifications of instances based on your business scenarios. With the self-developed RDB+AOF persistence mechanism, all product series support data persistence, achieving high performance and data reliability.

Does DCS Redis Support Read-Only Standby Nodes?

A DCS Redis instance runs in a master-replica architecture. The architecture generally has an active node and one or more standby nodes. The active node is used for writes and reads, while the standby node is used to replicate the data of the active node, providing redundant backup and load balance for reads.

Currently, no standby node works as a read-only node.

Does DCS Redis Version Support Failovers Between Active and Standby Nodes?

The DCS Redis management console supports manual switchover of the leader and follower nodes of a Redis instance. This operation is used in special scenarios, such as releasing all business connections or terminating business operations currently under execution.

Note:

During the switchover between the active and standby nodes, the business connection will be intermittently disconnected for less than 10 seconds, so please ensure that the application has the ability to rebuild the connection before a switchover.

When performing an active-standby switchover, synchronizing the new active-standby relationship consumes many resources, so please perform the operation during the idle period for your business.

A semi-synchronization mechanism is adopted for the data synchronization between the active and standby nodes, and theoretically no data will be lost.

 

Does DCS Redis Support Distributed Cluster Instances?

Yes, DCS Redis supports distributed cluster instances. Cluster instances provide a larger storage capacity and higher processing performance. Redis uses multiple nodes to realize high availability and horizontal scaling for distributed cluster instances. In a Redis cluster, data is split into multiple slots and each slot can be assigned to a different node in the cluster. This design enables Redis to store a large amount of data on multiple nodes, improving system performance and scalability.

What Is Strong Consistency?

Strong consistency refers to whether strong consistency is required for data synchronization between the active and standby nodes. The function is disabled by default. It is recommended not to enable strong consistency configuration and keep it disabled.

After strong consistency configuration is enabled, when the active node is abnormal and the standby node has not completed data synchronization, active-standby switchover will not occur.

For a distributed DCS Redis cluster, the system first checks whether strong consistency is enabled before triggering the HA active-standby failover mechanism in case of an abnormal crash of the active node. If strong consistency is not enabled, the system performs the active-standby failover directly. If strong consistency is enabled, the system performs the active-standby failover after confirming that the data is synchronized between the active and standby nodes.

What Is One-click Detection of Readonly?

This feature automatically detects all the shards in an active and standby cluster. If a node in the ZooKeeper is a master node but the actual info role is slave, readonly is abnormal. On the one-click detection of readonly page, you can rectify the readonly anomaly.

It improves system stability and maintainability, reducing human errors and manual operations. You can easily identify and resolve readonly exceptions in a cluster to ensure the proper operations of a Redis cluster.

How Do I Control Permissions for Instance Accounts?

You can create multiple sub-accounts for a DCS cluster instance. Each sub-account has three attributes, namely, name, password, and read/write. The DCS client uses the same authentication mode. For example, jedis.auth (subaccount name # subaccount password).

Read-only accounts can only read cached data, and read/write accounts can read and write cached data. You can control the read/write permissions of different accounts to ensure the security and reliability of DCS instances.

Do Clusters Support Multi-key Operations?

Yes. Stand-alone and active/standby instances support multiple key operations. In cluster instances, the access proxy layer will parse the key list and construct different Redis sharding protocols. After collecting the get results through the proxy layer, a protocol is constructed to uniformly return them to the client, and the application performs operations on the proxy cluster instances in a way just as operations on stand-alone and active/standby instances.

In Redis clusters, multi-key operations refer to executing commands on multiple keys at the same time, including reads, writes, and other operations. A Redis cluster has multiple nodes and each node manages a portion of data. During multi-key operations, the Redis cluster automatically distributes these keys to the corresponding nodes and then performs the operations. This ensures efficient operations in a distributed architecture.

What Is a Group of DCS Redis?

It is an alias for a database and corresponds to a Redis database, which is similar to a table in a relational database.

Example: group.instance name.xxx. xxx corresponds to the related service table.

What Are the Client Monitoring Metrics?

The monitoring metrics include the monitoring point (cluster), identifier (client IP), IP address of Frontend, group ID, operation type (read/write), return code, requested packet size (>32K, >1K, 1K), and returned packet size (>32K, >1K, 1K).

The statistics include the number of requests, maximum time consumed, and average time consumed.

What Are the Monitoring Metrics of an Frontend?

The monitoring metrics include the monitoring point (cluster), identifier (client IP+ port + name), requesting source IP, group ID, operation type (read/write), Redis instance ID, return code, requested message size (>32K, >1K, 1K), and returned message size (>32K, >1K, 1K).

The statistics include the number of requests, maximum time consumed, and average time consumed.

Are Pipeline Batch Transactions Supported?

Pipeline batch transactions are supported by stand-alone and active/standby instances but are not supported by clusters.

The native Redis transactions encapsulate multiple commands into a batch of commands to construct a serial command pipeline, which is not characterized by transaction acid, namely integrity, consistency and isolation. Additional operations are required on certain applications. To resolve concurrent modification conflicts, you are advised to use the optimistic locking mechanism.

What Is Redis Sharding?

Redis sharding is a data distribution policy that is used to store data across multiple Redis instances for scale-out and load balance.

In Redis shards, data is divided into multiple partitions and each shard stores a portion of data that is processed by an independent Redis instance.

Redis sharding addresses the limits on storage capacity and performance of a single Redis instance. Data is distributed to multiple instances and load is spread across nodes, improving the overall processing capacity and throughput. In addition, Redis sharding expands the storage capacity, each instance stores a portion of data, and the total capacity can be increased with more instances.

What Is a Redis Replica?

A Redis replica supports data redundancy and HA by replicating data in Redis.

In a Redis replica, an active node handles read/write requests and replicates data to multiple standby nodes. The standby nodes replicate the data of the active node and synchronize data with the active node to perform a takeover if the active node fails.

Does Redis Support Cross-AZ Deployment?

The standard Redis active/standby instances and clusters support cross-AZ deployment. If an AZ fails, nodes in other AZs will not be affected.

The standby node automatically becomes the active node. You can select cross-AZ deployment when creating an instance.

How Does Redis Realize HA?

The standard DCS Redis active/standby instances and clusters support HA.

You can choose to deploy instances in a single AZ or multiple AZs. When a tenant deploys an instance across multiple AZs, the Redis instance actively establishes and maintains Redis synchronous replication.

In the event of an active node fault, the DCS instance automatically promotes the standby node to the active node to achieve HA. If the tenant mostly uses the DCS instance to read the business data, they can choose an active/standby cluster instance, because the DCS instance actively maintains data synchronization and replication between the active node and the standby node.


juFyp19Jy31P