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.

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 cacheor 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 failure or a 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 cloud disk-based instances or local disk-based instances

ApsaraDB for Redis local disk-based instances provide a complete set of features. ApsaraDB for Redis cloud disk-based instances use a cloud native architecture and support imperceptible scaling. This allows you to specify a custom number of shards to scale a cluster instance without affecting your business. In the future, more and more ApsaraDB for Redis instances will use cloud disks. The following table compares these two types of ApsaraDB for Redis instance.

Item Instance that uses local disks Instance that uses cloud disks
Architecture The instances that use local disks are developed based on the traditional management architecture of ApsaraDB for Redis. The instances that use cloud disks are developed based on the new-generation management architecture of ApsaraDB for Redis.
Note New types of instances will evolve based on this architecture. ApsaraDB for Redis allows you to migrate data from an instance that uses local disks to an instance that uses cloud disks.
Scale-out
  • A scale-out consumes more time.
  • Transient connections occur when you scale out a cluster instance.
  • In a scale-out, you can only double the number of shards in a cluster instance. For example, if the original cluster instance has two shards, you can scale the instance only to four shards.
  • A scale-out consumes less time.
  • Transient connections do not occur when you scale out a cluster instance.
  • You can scale shards in a cluster instance to a number that is no less than one and scale up or down a single shard. This allows the instance to better cope with read/write hotspots and skewed requests.

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 an in-memory database service that is developed based on Tair. Tair is an internal service of Alibaba Cloud. ApsaraDB for Redis Enhanced Edition (Tair) provides a variety of 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 and provide read and write performance approximately three times that 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 application 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
  • Persistent memory-optimized instances provide 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.
  • Persistent memory-optimized instances support the TairString (including CAS and CAD commands) and TairCpc enhanced data structure modules.
  • Persistent memory-optimized instances prevent data loss when power failures occur. These instances implement persistence for each command. The system will return a 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.
  • Persistent memory-optimized instances optimize the append-only file (AOF) rewriting performance for large-sized Redis databases. These instances reduce the latency and jitters that are caused when Redis calls forks to rewrite the AOF.
  • Persistent memory-optimized instances deliver high compatibility. These 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
  • Storage-optimized instances reduce costs. These instances reduce up to 85% of costs compared with ApsaraDB for Redis Community Edition instances.
  • Storage-optimized instances store data in disks. These instances store data in enhanced SSDs (ESSDs) with high data reliability. The capacity of a storage-optimized instance reaches hundreds of terabytes. For more information about ESSDs, see ESSDs.
  • Storage-optimized instances optimize memory usage for large-sized Redis databases. These instances reduce the amount of reserved memory that is required for the forks of native Redis databases.
  • Storage-optimized instances deliver 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 None ApsaraDB for Redis Community Edition instances are 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 1. 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, 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 queries per second (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 caused by a large number of read requests, 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 2. 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 balancing. 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 6.0, 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.

Instance disk type and creation method Supported instance edition Supported engine version Supported architecture
Local disk-based instance

Create an ApsaraDB for Redis Community Edition instance or a performance-enhanced instance of the ApsaraDB for Redis Enhanced Edition (Tair)

ApsaraDB for Redis Community Edition

4.0

5.0

Cluster architecture

Standard architecture

Read/write splitting architecture

Performance-enhanced instances of the ApsaraDB for Redis Enhanced Edition (Tair)

5.0

Cluster architecture

Standard architecture

Read/write splitting architecture

Cloud disk-based instance

Create an ApsaraDB for Redis instance

ApsaraDB for Redis Community Edition

7.0

6.0

5.0

Standard architecture

Cluster architecture

Performance-enhanced instances of the ApsaraDB for Redis Enhanced Edition (Tair)

5.0

Standard architecture

Cluster architecture

Performance-enhanced instances of the ApsaraDB for Redis Enhanced Edition (Tair) 6.0

Standard architecture

Cluster architecture

Performance-enhanced instances of the ApsaraDB for Redis Enhanced Edition (Tair) 4.0

Standard architecture

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 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 instance 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: