How Camellia-Redis-Proxy Boosts Redis Cluster Performance and Simplifies Migration

Background

Redis Cluster is the official Redis clustering solution that uses a decentralized architecture, gossip protocol for node status exchange, and data sharding across 16,384 hash slots. Keys are assigned to slots via CRC16, and the cluster supports dynamic node addition, slot migration, and automatic failover.

Problem

When projects migrate from single‑instance Redis to Redis Cluster, client code often requires extensive changes to handle the cluster protocol, leading to heavy testing effort and risk.

Requirement

To simplify migration, a client SDK should be fully compatible with both Redis and Redis Cluster APIs. While Spring's RedisTemplate can achieve this, many projects use other clients (e.g., Jedis) whose APIs differ, making migration costly. Introducing a Redis Cluster proxy allows existing client code to operate unchanged.

Features of Camellia-Redis-Proxy

Password authentication support.

Proxy to regular Redis or Redis Cluster.

Custom sharding logic (proxy to multiple Redis/Cluster clusters).

Custom dual‑write logic (writes are sent to multiple back‑ends).

External plugins (e.g., HBase plugin for hot‑cold ZSET storage).

Online configuration changes via Camellia‑Dashboard.

Multi‑tenant routing rules for different business types.

Spring‑Boot starter for rapid deployment (three lines of code).

Performance Enhancements

Multithreading

Camellia‑Redis‑Proxy uses Netty’s multithreaded reactor model, defaulting to a worker thread per CPU core, and can bind business threads to non‑CPU‑0 cores to avoid interrupt handling contention.

Asynchronous Non‑Blocking I/O

All request‑forwarding steps except in‑memory rule matching are performed with asynchronous non‑blocking I/O, preventing any single stage from blocking the entire service.

Pipelining

During upstream parsing, multiple commands are parsed at once, and downstream forwarding batches commands per client or per target node, while preserving one‑to‑one request‑response correspondence.

TCP Fragmentation & Large‑Packet Handling

Checkpoint mechanisms reduce repeated unpacking of large packets, improving throughput.

Exception Handling & Log Consolidation

Fast‑fail strategy for unhealthy backend nodes.

Unified, merged exception logging to reduce performance impact.

Periodic health checks for backend Redis instances.

Deployment Architecture

The proxy is stateless and horizontally scalable. For high availability, at least two proxy nodes are deployed behind an LVS load balancer, or registered in a service registry (ZK/Eureka/Consul) for client‑side discovery.

Application Scenarios

Migrating from Redis to Redis Cluster without modifying client code.

Reducing excessive connections when clients directly connect to a Redis Cluster.

Extending capacity/QPS beyond a single cluster via proxy sharding.

Cache migration using dual‑write for seamless transition.

Disaster‑recovery with dual‑write across clusters.

Combining sharding and dual‑write for complex workloads.

Developing custom plugins via the proxy’s extensible architecture.

Conclusion

Redis Cluster is increasingly adopted for large‑scale caching, and Camellia‑Redis‑Proxy offers a transparent, high‑performance bridge that lets Java developers use familiar Jedis‑style APIs while gaining sharding, dual‑write, and other advanced features. The project is open‑source on GitHub.