Problem Index
What Engine Versions and Architectures Does Distributed Cache Support?
Distributed Cache (Redis-compatible) supports three types of storage engines to meet caching requirements in different business scenarios:
Redis engine
It is fully compatible with the Redis protocol and supports multiple Redis versions, including 4.0, 5.0, 6.2, and 7.0, with comprehensive features proven in large-scale production environments. It is suitable for business scenarios that require high compatibility with the Redis ecosystem or specific version features.
Valkey engine
It supports Valkey 8.0, 9.0, and later versions. As an open-source fork of Redis, it delivers optimized I/O performance while maintaining full protocol compatibility. It is suitable for business scenarios that require higher throughput.
Memcached engine
It is compatible with the Memcached 1.6 protocol and uses a cluster architecture, optimized specifically for high-speed caching scenarios. It is suitable for business scenarios that demand high cache performance without persistence requirements.
In terms of architecture, both the Redis and Valkey engines support the following two architectures:
|
Capacity range | 0.25GB - 64GB | 1 - 128 shards, up to 8 TB |
Application scenarios | Small data volume and high command compatibility requirements | Large data volume and the need for horizontal scaling |
Command Compatibility | Fully compatible with Redis commands | Some cross-slot commands are restricted. |
Multi-DB support | Supported (16 DBs by default) | Supported through Proxy (up to 256 DBs) |
Read-write separation | Supported | Supported |
Replica quantity | 1 - 5 replicas | 1 - 5 replicas |
Recommendation: If your business data is within 64 GB and requires high command compatibility (for example, extensive use of SCAN and transactions), choose the standard architecture. If your business data is large or requires continuous scaling, choose the cluster architecture to obtain more storage space and higher throughput through horizontal sharding.
What Are the Differences Between the Redis and Valkey Engines?
Both the Redis and Valkey engines are fully compatible with the Redis protocol and support data structures such as String, Hash, List, Set, and Sorted Set. They can be used in both standard and cluster architectures. The key differences between them are as follows:
|
Supported Versions | 4.0,5.0,6.2,7.0 | 8.0 |
I/O model | Single-threaded I/O (support for multi-threaded I/O starting from version 6.0) | Optimized multi-threaded I/O processing |
Read-write separation | Supported | Supported |
Ecosystem maturity | Proven in large-scale production, with comprehensive feature coverage. | New engine, continuously iterating |
Application scenarios | High requirements for stability and ecosystem compatibility | Higher requirements for throughput performance |
Note:
After read/write separation is enabled, data on replica nodes may experience slight latency (typically at the millisecond level). Strong consistency read requests should be routed to the master node.
What Are the Performance Metrics for Different Architectures and Specifications?
The performance of Distributed Cache is related to the architecture type and instance specifications:
|
Standard architecture 8 GB | 80,000 - 100,000 QPS | Single-node performance baseline, 10000 connections |
Cluster Architecture | 80,000 - 100,000 QPS/shard | Performance scales linearly with the number of shards. |
The formula for calculating cluster architecture performance is: Cluster architecture performance = Standard architecture performance × Number of shards. For example, the QPS of an 8-shard cluster architecture is approximately 640,000 to 800,000, and that of a 32-shard cluster architecture is approximately 2,560,000 to 3,200,000.
Actual performance is affected by factors such as business data models, command types, and Key sizes. Verify performance through stress testing before launching your business. For detailed performance data, see Specifications and Performance. What Is the Billing Mode of Distributed Cache?
Distributed Cache provides two billing modes: yearly/monthly subscription (prepaid) and pay-as-you-go (postpaid). The yearly/monthly subscription mode is suitable for production environments with stable, long-running workloads and offers lower unit prices. The pay-as-you-go mode is suitable for highly fluctuating or temporary workloads, with hourly settlement and greater flexibility.
Instance specification fees are billed based on memory capacity, covering compute resources, memory storage space, and network maintenance costs. Pricing is proportional to memory capacity. Unit prices vary by region and architecture.
Standard Architecture Fee Calculation Formula:
Fee = Memory per node × Unit price per node × Number of nodes
Take an 8 GB standard architecture instance with 1 master node and 1 replica node as an example (node pricing: CNY 38/GB/month): Monthly fee = 8 GB × CNY 38/GB/month × 2 nodes = CNY 608/month.
Cluster Architecture Fee Calculation Formula:
Fee = Memory per shard × Unit price per shard × Number of nodes × Number of shards
Take an 8 GB cluster architecture instance with 3 shards and 1 master node plus 1 replica node per shard as an example (node pricing: CNY 42/GB/month): Monthly fee = 8 GB × CNY 42/GB/month × 2 nodes × 3 shards = CNY 2,016/month.
What Happens After an Instance Has Overdue Payments?
When a Tencent Cloud account has overdue payments or an instance expires, the Distributed Cache instance will go through the following stages:
Pay-as-you-go instances
After an account has overdue payments, the instance enters a 24-hour grace period, during which it remains accessible and continues to be billed. If the balance remains negative after the grace period ends, the instance will be shut down and moved to the recycle bin for isolation. Data is retained but inaccessible. The isolation period is 7 days. During this period, the instance can be restored after the balance is topped up to zero or above. If the instance remains isolated for more than 7 days, it will be terminated. Backup files are retained on the backend for an additional 8 days (contact engineers to obtain them). After that, all data is permanently destroyed and cannot be recovered.
Yearly/monthly subscription instances
After an instance expires, it enters a 7-day grace period, during which the instance remains accessible and the system sends expiration reminders every day. If the instance is not renewed after the grace period ends, it will be shut down and moved to the recycle bin, entering a 7-day isolation period. Data is retained but inaccessible. During the isolation period, the instance can be restored from the recycle bin. If the instance remains isolated for more than 7 days, it will be terminated. Backup files are retained on the backend for an additional 8 days. After that, all data is permanently destroyed and cannot be recovered.
How Do I Get a Refund for an Unwanted Instance?
Refund methods vary by billing mode as follows:
Pay-as-you-go instances
You can terminate an instance directly from the instance list in the distributed cache database console. Billing stops after termination, and no refund application is required. After termination, the instance will be moved to the recycle bin and retained for 7 days, during which it can be restored from the recycle bin. Yearly/monthly subscription instances
Self-service return is supported, and there are two refund types:
5-Day Unconditional Full Refund: Each Tencent Cloud account is entitled to one unconditional full refund within 5 days (inclusive) of a new purchase, with all consumed amounts refunded. Instances converted from pay-as-you-go to yearly/monthly subscription do not support this refund method.
Standard self-service return: After the 5-day unconditional refund period ends, a standard self-service return can be initiated at any time during the order service period. Each account supports standard self-service return for up to 199 instances. Refund amount = current active order amount + unstarted order amount - value of used resources.
Refund path: Log in to the console, go to the instance list, choose More > Return and Refund in the Operation column, confirm the refund information, and then submit. After the refund, the instance will be moved to the recycle bin and isolated for 7 days, during which it can be restored.
Which Regions Does Distributed Cache Support?
Distributed Cache has been deployed in multiple regions worldwide. The region cannot be modified after an instance is created, so confirm the region required by your business before purchase.
Chinese mainland: Guangzhou, Shanghai, Nanjing, Beijing, Chengdu, Chongqing
Finance Zone: Shenzhen Finance, Shanghai Finance, Beijing Finance (requires application for activation)
Hong Kong (China), Macao (China), and Taiwan (China): Hong Kong (China)
Asia Pacific: Singapore, Jakarta, Bangkok, Seoul, Tokyo
North America: Silicon Valley, Virginia
Europe: Frankfurt
South America: Sao Paulo
We recommend that you select the region closest to your business users to reduce access latency. Resource availability is subject to what is actually displayed on the purchase page in the console. For a detailed list, see Regions and AZs.