The standard architecture of Tair features high data consistency, simple structure, and high cost-effectiveness, which can meet the requirements in different scenarios. However, the standard architecture does not allow you to add data shards or read replicas. The standard architecture is supported only for master-replica instances and standalone instances.
To add data shards or implement read/write splitting, select the cluster architecture or read/write splitting architecture.
The master-replica deployment model provides high-performance caching services and ensures high data reliability.
The cost-effective standalone deployment model is suitable for cache-only scenarios that do not require high data reliability.
Master-replica
The standard architecture provides a master-replica deployment model. The master node handles your daily workloads and the replica node stays in hot standby mode to ensure high availability. If the master node fails, the high availability (HA) system switches the workloads to the replica node within 30 seconds after the failure. This mechanism ensures the stability of your workloads.
Features of standard master-replica instances:
Reliability
Service reliability
The master and replica nodes are deployed on different physical machines. The master node serves your workloads. You can use the Redis CLI and common clients to add, remove, modify, and query data on the master node. If the master node fails, the in-house HA system performs a master-replica switchover to ensure high availability of your workloads.
Data reliability
By default, data persistence is enabled for standard master-replica instances. Instances support data backup. You can clone or roll back an instance based on a specified backup set to restore data after accidental operations. Instances created in zones that provide disaster recovery, such as Hangzhou Zone H and Zone I, support zone-disaster recovery.
Compatibility
Standard instances are fully compatible with the Redis protocol. You can seamlessly migrate data from a self-managed Redis database to a standard instance of Tair. You can also use Data Transmission Service (DTS) to migrate incremental data without service interruption.
In-house proprietary systems
HA system
Alibaba Cloud Tair uses the HA system to detect failures on the master node, such as disk I/O failures and CPU failures, and performs master-replica switchovers to ensure high availability.
Master-replica replication mechanism
Alibaba Cloud has optimized the master-replica replication mechanism of Tair. You can use write-ahead logs (WALs) to replicate data between the master node and the replica node. If the replication is interrupted, system performance and stability remain unchanged. This resolves issues caused by the master-replica replication mechanism of native Redis.
The following section describes specific issues caused by the master-replica replication mechanism of native Redis:
If the replication is interrupted, the replica node runs the PSYNC command to resynchronize partial data. If the resynchronization fails, the master node synchronizes all Redis Database (RDB) files to the replica node.
To synchronize full data, the master node performs a full replication as a response to the single-threading mode. As a result, the master node experiences a latency of several milliseconds or seconds.
Child processes are created to perform copy-on-write (COW) tasks. The child processes consume memory on the master node. In the worst-case scenario, the memory of the master node may be exhausted, which can cause the application to abnormally exit.
The replica files that the master node generates consume disk I/O and CPU resources.
The replication of GB-level files may lead to outbound traffic bursts on the server and increase the sequential I/O throughput of disks. This delays responses and causes more issues.
Applicable scenarios of standard master-replica instances:
Applications that require high compatibility with the Redis protocol
Standard instances are fully compatible with the Redis protocol. You can migrate your workloads to standard instances without service interruption.
Applications that use Tair as persistent data storage
Standard instances provide the data persistence, backup, and restoration mechanisms to ensure data reliability.
Applications that have a stable query rate on a single Tair instance
Native Redis databases use the single-threading mode. If your workloads support a query rate of less than 100,000 queries per second (QPS), we recommend that you use standard instances. If you require a higher query rate, use cluster instances.
Applications that have few sorting and computing workloads and require simple Tair commands
CPU performance is the main bottleneck due to the single-threading mode of Tair. If you want to process a large number of sorting and computing workloads, we recommend that you use cluster instances.
Standalone
The standalone deployment model contains only one data node. No replica nodes are provided to synchronize data in real time. Standard standalone instances are suitable for cache-only scenarios that do not require high data reliability. Standard standalone instances can be purchased at a low price.
Before you choose standard standalone instances, take note that standard standalone instances do not ensure data reliability or service continuity. We recommend that you do not use standard standalone instances in the production environment.
A standard standalone instance has only one data node and does not provide data persistence or backup and restoration. If the data node fails, the system creates a Tair instance and migrates data to the new instance. In this case, data loss may occur, and data prefetching is required for your application.
Standard standalone instances do not support the following features: automatic or manual backup, offline key analysis, and recycle bin. If your application requires data reliability, we recommend that you use standard master-replica instances.
Applicable scenarios of standard standalone instances:
Cache-only workloads
Standard standalone instances cannot ensure data reliability. Your application must re-cache data after the master node fails. If you want to handle workloads that require data reliability, we recommend that you use master-replica instances.
Applications that require high compatibility with the Redis protocol
Standard standalone instances are fully compatible with the Redis protocol. You can migrate your workloads to standard standalone instances without service interruption.
Applications that have a stable query rate on a single data node
Each standard standalone instance runs in single-threading mode and has only one CPU core. We recommend that you use standard standalone instances in scenarios in which the expected query rate is approximately 80,000 QPS. If you require a higher query rate, use cluster instances.
Applications that have few sorting and computing workloads and require simple Redis commands
CPU performance is the main bottleneck due to the single-threading mode of Redis. If you want to process a large number of sorting and computing workloads, we recommend that you use cluster instances.