Why Codis Outperforms Twemproxy: A Deep Dive into Redis Cluster Solutions

Preface

Efficient operations require both managerial and technical specialization. This piece focuses on the technical side, discussing recent developments in Redis clustering.

1. Common Redis Cluster Technologies

1.1 Client‑Side Sharding

Business code handles routing to multiple Redis instances based on predefined rules, offering high performance but poor operability and heavy reliance on developers.

1.2 Proxy Sharding

Dedicated proxy programs (e.g., Twemproxy) perform routing, simplifying application code and operations at the cost of some performance loss. This is the recommended approach.

1.3 Redis Cluster

Redis Cluster distributes keys across 16384 slots without a central node, handling node communication and failover internally. It is a heavyweight solution and not yet widely adopted in production.

2. Twemproxy and Its Shortcomings

Twemproxy, an open‑source proxy sharding solution from Twitter, solves single‑instance capacity limits but suffers from scaling pain points, lack of smooth expansion/reduction, and limited operational tooling.

3. Codis Practice

3.1 Architecture

Codis introduces the concept of a Group (one master and at least one slave) and stores routing information for 1024 slots in ZooKeeper, enabling seamless master‑slave failover via a dashboard.

3.2 Performance Comparison

Extensive three‑month benchmarks using

redis-benchmark

show Codis initially 20% slower than Twemproxy but now up to 100% faster under certain conditions. For Set operations with value size < 888 B, Codis outperforms Twemproxy; Get performance is consistently better.

3.3 Tips and Caveats

Key practical points include seamless migration from Twemproxy using the Codis‑port tool, Java HA support via Jodis, pipeline support for batch requests, and the responsibility of operators to maintain master‑slave data consistency.