camellia bundles a Redis proxy, an ID generator, a delay queue and a hot key service

One repository, four servers and a set of client libraries

camellia is not a single library but a family of components that share a core module and a common build. The repository splits into four deployable servers and six enhanced client libraries, and the split matters because the two groups have different runtime requirements. The servers are a Redis proxy, an ID generator, a delay queue and a hot key detection and caching service. The client side covers a Redis client, an HBase client, a Feign client for microservice calls, a database cache framework and a set of utility classes. The README describes these client libraries as enhanced versions of open source projects, which tells you the design intent: keep the familiar library API, add the production behaviour that a live environment needs. The claim on the README is worth quoting precisely, because it defines the audience. The project states that it was developed by NetEase Yunxin and that all modules have been applied in its production environment. That is a statement about one large operator, and it tells you the failure modes were encountered at scale, not in a lab.

The proxy hides the storage topology behind the Redis protocol

The proxy is built on Netty 4 and presents itself to clients as a Redis endpoint. Clients connect with the Redis protocol and do not need to know what sits behind it. That is the whole idea: the topology of your storage layer changes behind a stable protocol surface.

What sits behind it is configurable. Standalone Redis, Redis Sentinel and Redis Cluster are all supported as backends. Another proxy can sit behind the proxy, which is how the README describes a double write migration scenario, naming twemproxy and codis as examples of that arrangement. It also supports kvrocks, pika and tendis as backends, and supports using hbase, obkv or tikv as the underlying storage to build a Redis-like system.

The routing model is where the operational features live. Custom sharding, read and write splitting, double or multiple writes, and double or multiple reads are all configurable. Multi-tenancy is supported, meaning one proxy can serve several groups of routes, distinguished by different login passwords. Routing can also change at runtime, through a dynamic routing data source: the built-in options are the local configuration file, Nacos and etcd, and you can supply your own.

Command coverage reaches past GET and SET

The command coverage is the reason to look past the simple proxy label. Beyond plain GET and SET, the proxy handles MGET and MSET, the blocking BLPOP, PUBLISH and SUBSCRIBE, transactions, and the newer data types including STREAMS, JSON, SEARCH, BloomFilter and CuckooFilter, plus the TAIR_HASH, TAIR_ZSET and TAIR_STRING commands.

Two commands are called out with real operational weight. SCAN is supported even when the backend is Redis Cluster or a custom sharded store, and the README says this lets you transparently scan every key rather than only the keys of one shard. SELECT is supported too, which means multiple logical databases can be used behind one endpoint.

Transport options are broad. SSL/TLS is supported on both legs, client to proxy and proxy to Redis. Unix domain sockets are supported on both legs as well. The proxy can also be reached over HTTP, in a shape similar to webdis but with a different interface definition, and the documentation points at a separate page for the Redis over HTTP interface.

Cluster shapes, plugins and the monitoring story

Availability is handled by letting the proxy take on a cluster identity. The README lists several shapes: a cluster behind a load balancer, a cluster formed through a registry, a proxy disguised as a Redis Cluster, and a proxy disguised as a Redis Sentinel. The last two matter for clients that already speak a specific discovery protocol, because the client side of the connection does not have to change.

Around that core sit the plugins, and this is where the operational tooling lives. The proxy ships with a set of built-in plugins you enable as needed, including big key monitoring, hot key monitoring, hot key caching, key namespacing, IP allow and deny lists, and rate control. Monitoring covers TPS, response time, hot keys, big keys, slow queries and connection counts, and the README states that a Prometheus and Grafana setup can be used to watch a proxy cluster.

The other three server modules follow a similar pattern of clustering and monitoring. The id generator server and the delay queue server both support horizontal scaling, and the hot key server is designed around hot key detection, hot key caching and top N statistics with extension points for notifications, rules and custom data sources.

ID generation, delay queue and hot keys share the foundation

The three smaller servers are easier to summarise, and each answers a problem that keeps reappearing in chat and push services. The ID generator offers several algorithms, ready to use. A snowflake algorithm with configurable unit markers, a strictly increasing algorithm whose step size can be adjusted dynamically, and a trend increasing algorithm that also supports unit markers and synchronising IDs across multiple units. The server exposes an HTTP interface, which means clients in other languages can use it, and the documentation notes Prometheus and Grafana support for monitoring a cluster of id gen servers. The delay queue is built on Redis. A standalone delay queue server supports horizontal scaling and multiple topics, and serves HTTP with either short polling or long polling, again so that clients in any language can talk to it. A Java SDK is provided, including a Spring Boot integration for quick adoption. The hot key service covers detection, caching and top N statistics, with extension points for hot key notification, top N notification, a hot key rules data source and hot key cache hit statistics. It accepts custom data sources, with the local configuration file, Nacos and etcd built in, and custom registries, with ZK and Eureka built in. In each case the README says you can implement your own.

Taking camellia from Maven Central, module by module

Camellia publishes to Maven Central, and the README states that the latest release is 1.4.2, published on 2026/06/11, with a changelog linked from the repository. The current development version is 1.4.3-SNAPSHOT, and the README gives the Sonatype snapshot repository entry you add to your build to resolve it:

<repositories>
  <repository>
    <id>sonatype-snapshots</id>
    <name>Sonatype Snapshot Repository</name>
    <url>https://central.sonatype.com/repository/maven-snapshots/</url>
    <snapshots>
      <enabled>true</enabled>
    </snapshots>
  </repository>
</repositories>

The repository is a multi module Maven build, with a pom.xml at the root, a maven wrapper in the form of mvnw and mvnw.cmd, a bom module for managing versions across the submodules, and separate directories for each component: camellia-redis-proxy, camellia-redis-client, camellia-redis-base, camellia-id-gen, camellia-delay-queue, camellia-hot-key, camellia-cache, camellia-hbase-client, camellia-feign-client, camellia-toolkits, camellia-core and camellia-admin.

There is no single install command in the documentation, and that is worth flagging. The README does not spell out a pip style one line install, a docker run invocation, or a copy and paste dependency snippet for the Redis proxy. Each component has its own quick start page under the docs directory, and the release artefacts sit on Maven Central.

The Java version split is the adoption tax

The most immediate constraint is a version split inside one project. The server components, meaning the Redis proxy, the id generator, the delay queue and the hot key server, state a minimum requirement of Java 21. The SDK libraries, meaning the Redis client, the HBase client, the Feign client, the cache framework and the utility classes, state a minimum requirement of Java 8. The project badge shows 1.8 and 21 side by side. So a service on Java 8 can use the client libraries but cannot run the servers, and a team upgrading from Java 8 has to split that work.

Second, the breadth is a cost. The proxy implements a large command surface, several plugin categories, four cluster topologies, and multiple transport options. Each of those is a place where behaviour is chosen for you, and the linked documentation pages are where you find out which choice was made.

Third, the delay queue and the hot key service both keep their state in Redis, so Redis becomes a dependency of those modules rather than an optional backend. That is a different deployment shape from the proxy, which can sit in front of several storage systems.

Editorial conclusion

camellia earns its place in a Java shop that already runs Redis at scale and needs a proxy layer to hold sharding rules, read and write splitting, migration paths and hot key visibility in one place, and it is a fair choice for teams wanting distributed ID generation or a delay queue without writing them. It is the wrong tool for a service stuck on Java 8 that needs the servers rather than just the client libraries, for a small deployment with one Redis node and no traffic shaping to do, and for anyone who wants a single command to install it, because the README documents no such command and points at per component quick start pages instead. Before adopting, check three things: which Redis commands the proxy version you plan to use actually covers, listed in the supported_commands page, whether your deployment can give the servers Java 21 while clients stay on Java 8, and whether the built-in dynamic routing source, local file, Nacos or etcd, matches the registry you already run.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. netease-im/camellia on GitHub
4. README
5. Releases