When you create an ApsaraDB for Redis instance, you must select the most cost-effective and stable instance type that can suit your performance, price, scenario, and workload needs. This topic describes the instance types, editions, architectures, and storage media of ApsaraDB for Redis to help you select instances.

Overview of ApsaraDB for Redis

ApsaraDB for Redis is a database service that is compatible with the open source Redis protocol and supports a variety of storage media. ApsaraDB for Redis provides the hot standby architecture and the cluster architecture, and can scale to meet requirements for high-throughput and low-latency operations.

Figure 1. Overview of ApsaraDB for Redis
Overview of ApsaraDB for Redis

Selection procedure

To create an ApsaraDB for Redis instance, you must select the instance type and specifications that can suit your performance, price, scenario, and workload needs. For example, you need to select different instance types and specifications based on whether you use the instance as a high-speed cache or an in-memory database. The following table describes the recommended procedure for selecting ApsaraDB for Redis instances.

Note For more information about the pricing of ApsaraDB for Redis, see Billable items and prices.
Step Description
Select ApsaraDB for Redis Community Edition or Enhanced Edition (Tair) ApsaraDB for Redis provides Community Edition and Enhanced Edition (Tair). ApsaraDB for Redis Enhanced Edition (Tair) is developed based on Tair to provide higher performance, more data structures, and more flexible storage methods. Tair is an internal service of Alibaba Cloud.
Select a deployment architecture ApsaraDB for Redis provides instances that use the standard architecture, cluster architecture, or read/write splitting architecture. You can select an architecture that suits your business data volume and your requirements for read and write capabilities and business performance. For more information about the standard, cluster, and read/writing architectures, see Standard master-replica instances, Cluster master-replica instances, and Read/write splitting instances.
Select a disaster recovery solution An ApsaraDB for Redis instance may fail due to unexpected reasons, such as a device or power failure in a data center. In this case, disaster recovery can help ensure data consistency and service availability. ApsaraDB for Redis provides a variety of disaster recovery solutions to meet the requirements in different business scenarios.
Select a major version We recommend that you use the latest major version that boasts more features.
Estimate the memory size We recommend that you estimate the size of memory to be consumed. This reduces costs and prevents your business from being affected by frequent specification changes.
Create an ApsaraDB for Redis instance After you determine the instance type and specifications, create an ApsaraDB for Redis instance by using the ApsaraDB for Redis console or an API operation of ApsaraDB for Redis.
Verify and adjust the selected instance After you create and start to use an ApsaraDB for Redis instance, we recommend that you monitor the performance of the instance when your business is running as expected. This allows you to check whether the type and specifications of the instance are suitable.

Select ApsaraDB for Redis Community Edition or Enhanced Edition (Tair)

ApsaraDB for Redis provides Community Edition and Enhanced Edition (Tair). ApsaraDB for Redis Enhanced Edition (Tair) is developed based on Tair and is suitable for enterprise-grade cache business. Tair is an internal service of Alibaba Cloud. ApsaraDB for Redis Enhanced Edition (Tair) provides various series of instances based on storage media such as DRAM, NVM, and enhanced SSDs (ESSDs) to meet your requirements for low-latency access, persistence, and reduced overall costs. For more information about ESSDs, see ESSDs. ApsaraDB for Redis Enhanced Edition (Tair) provides you with higher performance, more data structures, and more flexible storage methods. This helps you meet business requirements in different scenarios.

Notice
Edition Series Feature Scenario
ApsaraDB for Redis Enhanced Edition (Tair) Performance-enhanced instances
  • Performance-enhanced instances use the multi-threading model to provide approximately three times the performance of ApsaraDB for Redis Community Edition instances with the same specifications.
  • Performance-enhanced instances provide multiple enhanced data structure modules such as TairString (including CAS and CAD commands), TairHash, TairGIS, TairBloom, TairDoc, TairTS, TairCpc, TairZset, TairRoaring, and TairSearch. These instances eliminate concerns about storage structure and timeliness and allow you to focus on business development.
  • Performance-enhanced instances provide high compatibility. Performance-enhanced instances are fully compatible with open source Redis. You can switch from open source Redis to ApsaraDB for Redis without the need to modify application code.
  • Performance-enhanced instances provide a variety of enterprise-grade features such as data flashback, proxy query cache, and Global Distributed Cache for Redis. For more information, see Use data flashback to restore data by point in time, Use proxy query cache to address issues caused by hotkeys, and Overview.
Performance-centric business scenarios.
Persistent memory-optimized instances
  • Provides ultra-high cost-effectiveness. The price of persistent memory-optimized instances is 30% lower than that of ApsaraDB for Redis Community Edition instances with the same capacity. The performance of persistent memory-optimized instances reaches 90% of that of native Redis databases.
  • Prevents data loss when power failures occur. Persistent memory-optimized instances implement data persistence for each command. The system returns success response for each write operation only after the data is persistently stored. You can use persistent memory-optimized instances as in-memory databases instead of caches.
  • Optimizes append-only file (AOF) rewriting performance for large-sized Redis databases. Persistent memory-optimized instances reduce the latency and jitters that are caused when Redis calls forks to rewrite the AOF.
  • Delivers high compatibility. Persistent memory-optimized instances are compatible with most data structures and commands of native Redis databases.
Data cache and storage scenarios that require high performance and high data persistence, and can bear high costs.
Storage-optimized instances
  • Saves costs. Storage-optimized instances save up to 85% of costs compared with ApsaraDB for Redis Community Edition instances.
  • Stores data in disks. Storage-optimized instances store data in ESSDs with high data reliability. The capacity of a storage-optimized instance reaches hundreds of terabytes.
  • Optimizes memory usage for large-sized Redis databases. Storage-optimized instances reduce the amount of reserved memory that is required for the forks of native Redis databases.
  • Delivers high compatibility. Storage-optimized instances are compatible with most data structures and commands of native Redis databases.
Data storage scenarios that require a large capacity and low costs, involve only infrequent data access, and can bear high access latency.
ApsaraDB for Redis Community Edition N/A Compatible with open source Redis databases and provides high performance. Small-sized applications, medium-sized applications, applications for verification, and standard Redis usage and data migration scenarios.

Select a deployment architecture

ApsaraDB for Redis instances support three deployment architectures. You can select an architecture that suits your business data volume and your requirements for read and write capabilities and business performance.

Figure 2. Comparison among deployment architectures
Comparison among deployment architectures
Note
  • By default, cluster instances and read/write splitting instances provide proxy endpoints. Requests of clients are routed to data shards by proxy nodes. Proxy nodes help implement features such as load balancing, read/write splitting, failover, proxy query cache, and persistent connection. Only performance-enhanced instances of the ApsaraDB for Redis Enhanced Edition (Tair) support proxy query cache. For more information about proxy query cache, see Use proxy query cache to address issues caused by hotkeys. For more information about performance-enhanced instances, see Performance-enhanced instances. For more information about proxy nodes, see Features of proxy nodes.
  • If you use a cluster instance, you can use a private endpoint to bypass proxy nodes. This way, you can directly access backend data shards. This is similar to the connection to a native Redis cluster. For more information about private endpoints, see Enable the direct connection mode. Compared with the proxy mode, the direct connection mode reduces the routing time and accelerates the response of ApsaraDB for Redis.
Architecture Description Scenario
Standard Standard instances adopt a master-replica architecture. The master node serves your workloads, whereas the replica node stays in hot standby mode to ensure high availability. If the master node fails, the system switches the workloads to the replica node within 30 seconds after the failure occurs. This ensures the high availability of your instance.
  • Support for more native Redis features.
  • Persistent storage in ApsaraDB for Redis instances.
  • Stable query rate on a single node of ApsaraDB for Redis.
  • Use of simple Redis commands, when only a few sorting and computing commands are required.
Cluster
  • A cluster instance contains proxy nodes, data shards, and config servers. You can scale out a cluster instance by increasing the number of data shards.
  • A cluster master-replica instance contains multiple data shards. Each data shard works in a high availability architecture in which a master node and a replica node are deployed on different devices. If the master node is faulty, the master-replica cluster instance fails over to the replica node to ensure high service availability.
  • Large data volume.
  • High QPS.
  • High throughput and high performance.
Read/write splitting
  • A read/write splitting instance contains proxy nodes, master and replica nodes, and read replicas.
  • Read replicas support chained replication. This allows you to scale out read replicas to increase the read capacity.
  • High QPS scenarios, such as data hotspots.
  • Support for more native Redis features. You can use read/write splitting instances to overcome the limits of cluster instances. For more information, see Limits on commands supported by cluster instances.
Note Data synchronization to read replicas has a latency. Therefore, in scenarios that require high data consistency, we recommend that you use cluster instances instead of read/write splitting instances.

Select a disaster recovery solution

Figure 3. Roadmap of disaster recovery for ApsaraDB for Redis
Roadmap of disaster recovery for ApsaraDB for Redis
Disaster recovery solution Protection level Description
Single-zone HA solution ★★★☆☆ The master node and replica node are deployed on different devices in the same zone. If the master node fails, the high availability system performs a failover to prevent service interruption caused by a single point of failure (SPOF).
Zone-disaster recovery solution ★★★★☆ The master node and replica node are deployed in two different zones in the same region. If the zone in which the master node resides is disconnected due to force majeure factors such as a power or network failure, the high availability system performs a failover to ensure continuous availability of the entire instance.
Cross-region disaster recovery solution ★★★★★ In the architecture of Global Distributed Cache for Redis, a distributed instance consists of multiple child instances that synchronize data among each other in real time by using synchronization channels. The channel manager monitors the health status of child instances and handles exceptions that occur on child instances, such as a switchover between the primary and secondary databases. Global Distributed Cache for Redis is suitable for scenarios such as geo-disaster recovery, active geo-redundancy, nearby application access, and load sharing. For more information, see Overview.

Select a major version

Select a major version of ApsaraDB for Redis based on your business requirements. All major versions are regularly maintained. You can use the latest major version that boasts more features. For more information, see New features of ApsaraDB for Redis 5.0 and Features of ApsaraDB for Redis 4.0.

You must consider the following limits when you select a major version:

  • ApsaraDB for Redis Community Edition supports only Redis 4.0 and Redis 5.0.
  • Performance-enhanced instances of the ApsaraDB for Redis Enhanced Edition (Tair) support only Redis 5.0. For more information about performance-enhanced instances, see Performance-enhanced instances.

Estimate the memory size

To create an ApsaraDB for Redis instance, you must estimate the size of memory to be consumed based on the following factors and select the most suitable memory specifications. This reduces costs, prevents your business from being affected by frequent specification changes, and allows you to migrate your business to the cloud at a faster pace.

Notice When you determine the memory size of an ApsaraDB for Redis instance, you must first consider the volume of the business data to be stored. In addition, you must take into account the memory required for the operation of the instance itself, such as the memory occupied by the process metadata, replication buffer, and fragments.

For self-managed Redis databases, you must consider the memory overhead caused by the write-time replication of forks and advanced features such as whitelist configuration, audit logging, large key management, and hotkey management. If you use ApsaraDB for Redis instances, the preceding memory overhead is borne by Alibaba Cloud and is not included in the memory size of the purchased instance.

  • The data types, lengths, and quantity of keys.
    Note If a key, such as a key of the hash type, contains elements, you must consider the quantity and lengths of these elements.
  • The lengths of values.
  • The expiration time and eviction policy of each key. For more information about eviction policies, see How does ApsaraDB for Redis evict data by default?
  • The access models. For example, if the access model involves a large number of client connections, Lua scripts, and transactions, you must reserve memory for them.
  • Medium- and long-term business growth.

Create an ApsaraDB for Redis instance

After you determine the instance type and specifications, you can create an ApsaraDB for Redis instance by using the ApsaraDB for Redis console or an API operation of ApsaraDB for Redis. For more information, see the following topics:

Verify and adjust the selected instance

ApsaraDB for Redis supports a variety of monitoring metrics. After you create and start to use an ApsaraDB for Redis instance, we recommend that you monitor the performance of the instance when your business is running as expected. This allows you to check whether the type and specifications of the instance are suitable. For more information, see View monitoring data.

Note You can also use the Redis-benchmark tool to perform a performance stress test. For more information, see Description of redis-benchmark.
For example, if the performance monitoring data of an ApsaraDB for Redis instance indicates high memory usage, you must check whether an exception exists. If no exception exists, upgrade the instance specifications. For more information, see Change the configurations of an instance. For more information about how to troubleshoot performance issues for ApsaraDB for Redis instances, see the following topics: