Choosing the Right KV Store: Redis vs Redis Cluster vs Pika for High‑Scale 360 Applications

Background Introduction

As 360’s business expands, the demand for key‑value (KV) storage has grown explosively. To handle the surge and diverse usage scenarios, the 360Web platform team built a comprehensive KV solution that currently uses Redis, Redis Cluster, and Pika in production.

In 2015 the daily Redis traffic was 80 billion requests; by Q3 2016 it exceeded 250 billion, and by Q1 2017 it approached 400 billion—a five‑fold increase in 1.5 years.

KV Storage – Redis

Redis Overview

Redis is a widely used open‑source in‑memory database supporting data structures such as String, Hash, List, Set, Zset, Geo, and HyperLogLog, as well as features like master‑slave replication, Lua scripting, transactions, persistence, high availability, and clustering.

Redis Features

High performance: single‑threaded but can reach ~100 k OPS per server.

Diverse data structures: String, Hash, List, Set, Zset, Geo, etc.

Persistence: RDB (snapshot) and AOF (append‑only file) each with trade‑offs.

Multiple eviction policies: lazy deletion, periodic deletion, and proactive deletion (volatile‑lru, volatile‑ttl, volatile‑random, allkeys‑lru, allkeys‑random, noeviction).

High availability via Sentinel.

Redis Use Cases

Typical scenarios handle <10 k OPS with modest data size. Advanced scenarios require read‑write separation or hash‑sharding when a single node cannot sustain the load, but these increase code complexity and limit scalability.

KV Storage – Redis Cluster

Redis Cluster Overview

Redis Cluster is a distributed, master‑less, highly available, linearly scalable in‑memory database that implements a subset of single‑node Redis functionality. It sacrifices some fault tolerance to maintain consistency.

Key Concepts

Hash slots: 16 384 slots; keys are mapped to slots via CRC16 modulo.

Cluster node: each master handles a subset of slots; slot allocation can be adjusted manually.

Cluster map: each node stores the full cluster topology (node IDs, IP, port, role, slot ranges, status) and exchanges updates via the Gossip protocol.

Redis Cluster Architecture

Data Routing

Client computes the hash slot for the key.

Using its local cluster map cache, the client contacts the node responsible for that slot.

If the slot is served by a different node, the server returns a MOVED error; the client updates its cache and retries.

If the slot is being migrated, the server returns an ASK error; the client redirects accordingly.

Typical Scenarios

Large‑capacity, high‑concurrency workloads that require linear scaling.

KV Storage – Pika

What Is Pika

Pika is a high‑capacity, high‑performance, persistent KV store compatible with Redis protocols, built on the Nemo engine (a RocksDB‑based storage layer). It supports String, Hash, List, Set, Zset, and stores data on disk, overcoming Redis’s memory limits.

Pika vs Redis – Advantages

Massive storage: limited only by disk capacity.

Second‑level startup: data is persisted, so restart does not require full memory loading.

Fast backup: snapshot of data files.

Quick deletion: logical delete with versioning, actual removal during compaction.

Incremental sync: write‑ahead logs enable resumable replication.

High compression ratio (5‑10× compared to Redis).

Cost‑effective: uses inexpensive SSD storage instead of costly RAM.

Disadvantages

Read/write performance lower than in‑memory Redis.

Multi‑data‑structure support incurs some overhead due to RocksDB.

~90% Redis command compatibility; not 100%.

Pika Architecture

Usage Scenarios

When business volume is moderate and Redis memory cost is prohibitive.

When data size exceeds a single Redis server’s memory.

When large‑key operations cause Redis to block.

Read‑write separation with fast failover without affecting replicas.

Adoption

Inside 360, Pika serves 43 primary and 76 secondary business lines, handling billions of daily requests and tens of terabytes of data, saving substantial memory costs. It is also used by companies such as Sina Weibo, Meituan, 58.com, Xunlei, Wanda, and Huanxin.

Migrating from Redis to Pika

The aof_to_pika tool reads Redis AOF files (with AOF enabled and rewrite disabled) and streams data to Pika using reader and sender threads. A similar ssdb_to_pika tool assists migration from SSDB.

Q&A

Q1: Does Pika support clustering? A1: Currently Pika uses a master‑slave model and supports Codis; full distributed clustering is under research.

Q2: Is Pika a replacement for Redis? A2: Pika complements Redis; it is used when memory costs are high, typically on SSDs, handling up to 50 k OPS comfortably.

Q3: Which Redis persistence should I choose? A3: Most scenarios use AOF for durability; the choice depends on data‑safety requirements.

Q4: Can Pika on SSD match Redis performance? A4: In 360’s production, Pika runs on SSDs and meets performance expectations for its workloads.

Q5: How does Pika implement Zset? A5: Each Zset entry is stored as three RocksDB key‑value pairs; scan commands are fully supported.

Q6: How does Pika differ from FastDFS? A6: FastDFS is a distributed file system for static files; Pika is an online KV database designed to replace Redis when memory is insufficient.

Q7: Advantages over Aerospike? A7: Pika maintains Redis‑compatible commands and client libraries, enabling seamless migration without code changes, and it does not reload deleted data after restart.

Q8: How to handle hot or large keys in Redis? A8: Split hot keys at the application level, use multi‑level caching, compress large keys, or offload them to multi‑threaded stores like Pika.