Tair (Redis® OSS-Compatible):Standard architecture

High availability

The standard high availability (HA) architecture uses a master-replica model. The master node handles daily workloads and the replica node remains in hot standby mode to ensure high availability. If the master node fails, the system switches workloads to the replica node within 30 seconds to ensure stability.

Features of the standard HA architecture:

• Reliability

  • Service reliability

    The standard HA architecture uses a master-replica model. The master and replica nodes are deployed on different physical hosts. If the master node fails, the self-developed HA system performs a master-replica switchover to ensure smooth business operations.

  • Data reliability

    By default, data persistence is enabled. This indicates that all data is written to disks. The architecture supports data backup. This allows you to clone or roll back an instance from a backup set to restore data after accidental operations. Instances created in zones that provide disaster recovery capabilities, such as Hangzhou Zone H and Zone I, support zone-disaster recovery.

• Compatibility

  The architecture is fully compatible with the Redis protocol. You can seamlessly migrate data from a self-managed Redis database to a standard instance. You can also use Alibaba Cloud Data Transmission Service (DTS) to migrate incremental data without service interruption.

• In-house proprietary systems

  • HA system

    Tair (Redis OSS-compatible) 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 service availability.

  • Master-replica replication mechanism

    Tair (Redis OSS-compatible) is optimized to resolve the fork issue that occurs during full data synchronization between master and replica nodes and achieve non-blocking synchronization. You can use write-ahead logs (WALs) to replicate data between the nodes. If replication is interrupted, the impact on system performance and stability is minimal. This resolves issues caused by the master-replica replication mechanism of native Redis.

    Disadvantages of the replication mechanism of native Redis

    • If replication is interrupted, the replica node runs the PSYNC command to resynchronize partial data. If 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 data replication, which involves forking the process. This causes 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 extreme scenarios, the memory of the master node may be exhausted, which can cause the application to unexpectedly exit.

    • The replica files that are generated by the master node consume disk I/O and CPU resources.

    • The replication of GB-level files may lead to outbound traffic bursts on the server and an increase in the sequential I/O throughput of disks. This delays responses and causes more issues.

Scenarios:

• Applications that require high compatibility with the Redis protocol

  The standard architecture is fully compatible with the Redis protocol. You can migrate workloads to standard instances without service interruption.

• Applications that use Redis as persistent data storage

  The standard architecture provides data persistence, backup, and restoration mechanisms to ensure data reliability.

• Applications that have a stable query rate on a single instance

  Native Redis databases use the single-threaded mode. If your workloads support a query rate of less than 100,000 queries per second (QPS), we recommend that you use the standard architecture. If you require a higher query rate, enable read/write splitting or use the cluster architecture.

• Applications that have few sorting and computing workloads and require simple Redis commands

  CPU performance is the main bottleneck due to the single-threaded mode of native Redis. If you want to process a large number of sorting and computing workloads, we recommend that you use the cluster architecture.

FAQ

• The existing business operates in Redis Sentinel mode. What architecture do I select when I migrate business to the cloud?

  We recommend that you select the standard HA architecture, which uses a master-replica model. If the master node fails, the HA system automatically performs a master-replica switchover to ensure service availability.

• If an instance has 8 GB of memory and uses the standard architecture, how do I upgrade the instance performance without upgrading the memory capacity?

  We recommend that you use one of the following upgrade solutions based on your business requirements:

  • If the number of connections or bandwidth is insufficient, the instance may fail to handle high read traffic. To improve the read performance of your instance without the need to upgrade the memory specifications, we recommend that you enable the read/write splitting feature.

    This solution is ready to use without the need to modify business code. You can also disable the feature at any time. After you enable read/write splitting for an instance, the instance can automatically identify and forward read and write requests to corresponding nodes. This allows the instance to support high-concurrency read and write operations.

  • If the CPU utilization of the existing instance is consistently high, consider upgrading the instance to a cluster instance. This way, you can add data shards to reduce CPU utilization in a single shard.

    However, this solution involves changing the instance architecture, and specific commands may not be compatible between standard and cluster architectures. For more information, see Limits on commands supported by cluster instances and read/write splitting instances. Before you perform the upgrade operation, we recommend that you evaluate the compatibility and impact of the change.

  The following section compares the performance of an 8-GB Redis Open-Source Edition instance under different architectures.

  Architecture	Memory (GB)	CPU cores	Bandwidth (Mbit/s)	Maximum number of connections	QPS reference value
  Standard architecture (master and replica nodes)	8	2	96	20,000	100,000
  Standard architecture (read/write splitting enabled, one master node, one read replica)	8	4 (2 × 2)	192 (96 × 2)	40,000 (20,000 × 2)	200,000
  Cluster architecture (2 shards)	8 (4 GB × 2 shards)	4 (2 × 2)	192 (96 × 2)	40,000 (20,000 × 2)	200,000