Tendis Hybrid Storage Architecture and Key Features

Introduction

This article first outlines the pain points encountered when operating Redis at Tencent IEG, then presents the three Tendis product editions jointly developed by the Tencent Interactive Entertainment CROS DBA team and the Tencent Cloud Database team, and finally focuses on the overall architecture and component features of the hybrid storage edition.

Background

Redis Pain Points

High memory cost, including excessive memory consumption during scaling and the need to reserve memory for fork operations.

Cache‑database consistency requires considerable effort.

Data reliability issues: AOF persistence degrades performance, no rollback, and asynchronous replication can cause data loss.

Asynchronous replication leads to data loss on master failure.

What Is Tendis?

Tendis is a Redis‑compatible KV storage solution that integrates Tencent’s large‑scale KV storage experience, fully compatible with the Redis protocol and all Redis 4.0 data models. It offers three editions—Cache, Hybrid Storage, and Storage—each targeting different business scenarios, and the Storage edition is open‑source on GitHub (Tencent/Tendis).

Hybrid Storage Architecture

The hybrid storage version consists of four main components: Proxy, Cache Layer (Redis Cluster), Storage Layer (Tendis Storage), and the synchronization layer (Redis‑sync).

Proxy : Routes client requests to the appropriate shard, collects monitoring data, and can disable high‑risk commands.

Cache Layer (Redis Cluster) : Built on Redis 4.0 with added features such as version control, automatic cold‑data eviction, Cuckoo Filter for full‑key representation, and RDB+AOF based scaling.

Storage Layer (Tendis Cluster) : A RocksDB‑based KV engine compatible with Redis protocol, responsible for full data persistence, backup, and incremental log handling.

Redis‑sync : A stateless synchronization component that imports data in parallel, supports fault‑tolerant resumption, and automatically routes requests to the correct Tendis node.

Cache Layer Enhancements

Version control: each key/value carries a monotonically increasing version, enabling incremental RDB generation and idempotent AOF execution.

Cold‑hot data interaction: a connection pool per Tendis node accelerates cold‑data recovery from storage to cache.

Key cooling and Cuckoo Filter: dynamic Cuckoo Filter prevents cache penetration while allowing key eviction together with values, reducing memory usage dramatically.

Intelligent eviction/loading policies: maxmemory‑policy for memory‑full eviction, value‑eviction‑policy for time‑based eviction, and configurable loading thresholds to avoid cache pollution.

RDB+AOF scaling: replaces the non‑atomic importing/migrating process of community Redis with a slot‑based, parallel, and incremental approach.

Synchronization Layer (Redis‑sync)

Redis‑sync mimics Redis Slave behavior, receives RDB and AOF streams, and imports them into Tendis while addressing:

Slot‑level serialization and cross‑slot parallelism to preserve command order.

Serial‑parallel conversion for special commands (e.g., FLUSHDB).

Periodic reporting of the latest AOF version for fault‑tolerant recovery.

Automatic routing based on slot‑to‑Tendis‑node mapping.

Storage Layer (Tendis Cluster)

Full compatibility with Redis protocol and data structures.

Persistent storage using RocksDB, supporting petabyte‑scale data.

Decentralized gossip‑based architecture with optional hashtag sharding.

Horizontal scalability up to thousands of nodes with transparent slot migration.

Automatic failover and master promotion.

Overall, the hybrid storage edition combines the low‑latency access of a cache layer with the durability and capacity of a storage layer, offering configurable eviction, version‑controlled replication, and a stateless sync component for reliable, scalable KV services.