NewLife.Redis: a .NET Redis client with message queues and legacy .NET targets

A protocol client rather than a wrapper around one

NewLife.Redis is described as a high-performance, high-throughput .NET Redis client component built by the NewLife team, and the scale claim in the README is specific: since 2017 it has been running on multiple production platforms handling billions of records and high concurrency, processing more than 80 billion command calls daily, with a daily peak of more than 100 million business object writes. The core features list gives the mechanism rather than the claim. It implements RESP2 and covers the mainstream commands from Redis 2.8 through 7.x, it uses efficient synchronous RESP protocol parsing, and it has a built-in connection pool that goes up to 100,000 concurrent connections. A single get or set round trip is put at 200 to 600 microseconds including the network. That is the difference between a library that speaks the wire protocol itself and one that delegates to another client's socket layer.

Four message queues in the box

The queue support is what separates this from a general purpose Redis client, and there are four distinct designs offered. The simple queue is the obvious one. The reliable queue is described as using RPOPLPUSH with acknowledgement semantics, which gives at-least-once delivery: the message is moved out of the queue into a processing list atomically, and only removed when the consumer acknowledges it, so a consumer that crashes mid-task leaves the message recoverable rather than losing it. The delay queue handles scheduled delivery. The stream queue is for Redis 5.0 and later and uses multi-consumer-group semantics. The README frames this as ready to use with no need to reinvent the wheel, which is the honest description of what a library should offer here, since these patterns are the ones that get reimplemented badly in every application that needs them.

Data structures, from String to HyperLogLog

The structure coverage is listed as String, List, Hash, Set, Sorted Set, Stream, Geo and HyperLogLog, and the documentation table of contents breaks the operations down into a section per family, including a dedicated section for the stack type built on a list. The encoder is pluggable, with JSON as the default and binary serialization as an alternative, which matters for throughput: a JSON round trip on a large object graph is often more expensive than the Redis round trip itself, and swapping the encoder is the usual way to cut that. The README also describes an auto-detection path for Redis-compatible servers, specifically Microsoft Garnet and kvrocks, where the client notices what the server supports and degrades gracefully with clear alternatives when a feature is not there, rather than failing with an obscure protocol error.

Clustering, failover and the cloud providers nobody else supports

The deployment topologies covered are Standalone, Master-Replica, Sentinel and Native Cluster, with automatic failover. Servers accept a comma-separated list of nodes, the client fails over quickly on network errors, and the default shielding window is ten seconds, which is the pause before it starts retrying a node it has just decided is down. The cloud adapter section is the part that is unusual for a Redis client, and it covers Alibaba Cloud KVStore and Tair, Tencent Cloud Redis and Huawei Cloud DCS, with the differences that come from proxy mode, ACL authentication, SSL encryption and special authentication formats handled per provider rather than as an afterthought. For anyone running a Chinese cloud Redis, that is probably the deciding feature, because the proxy mode in particular changes how a client has to behave.

Targeting .NET Framework 4.5 and NativeAOT at the same time

The target framework list is the most unusual thing about the package: net45, net461, netstandard2.0, netstandard2.1 and net8.0, with the extension packages extending from netcoreapp3.1 to net10, and the README describing a single package as suitable for industrial control, government, IoT and other legacy scenarios. The library is also strong-named. The NativeAOT story is handled seriously: there is an IsAotCompatible check on net8.0, a dedicated AotSmoke project with CI regression, and the AOT smoke and unit tests cover win-x64, linux-x64, linux-arm64 and linux-la64 through QEMU emulation, plus win-arm64, macOS and musl RIDs under native compilation. The repository root shows the shape of the effort, with an AotSmoke directory, a Test directory, an XUnitTest directory and a Samples directory containing a benchmark, a mobile smoke test, a queue demo, a Redis switch and a web demo.

Pipeline, auto batching and observability

Throughput on a high-concurrency workload depends on how many commands you put on the wire, and the library offers optional auto-pipeline batching on top of the manual path. The table of contents separates the Pipeline and Auto Batching section from the queue sections, which suggests the batching applies across the ordinary command API rather than only to the queues. Observability is built in rather than bolted on: the client supports ITracer for distributed tracing and PerfCounter for performance counters, so a latency spike in Redis can be attributed rather than guessed at. The documentation set linked at the top of the README covers requirements, architecture, a feature list, a competitive analysis, Garnet compatibility and AOT compatibility, and the README itself ends with a feature completion status section that breaks the data structures, the queues, the cluster support and the advanced protocol features into what is done and what is not.

Where NewLife.Redis is the wrong choice

Four limits apply. It is a .NET library, so the range of frameworks is wide but it is not a polyglot tool, and a Node or Go service in the same system needs a different client. It targets .NET Framework 4.5 for legacy reasons, which means the oldest targets do not get the newer runtime capabilities, and a modern application is the case where the multi-targeting helps rather than the legacy case. The scale claims are the vendor's own, and the README's benchmark numbers are the project's, so they tell you about a workload the maintainers chose rather than about yours. And the compatibility surface is bounded: the command coverage is documented as Redis 2.8 to 7.x, so a feature added in a later release is simply absent, and the cloud adapters, while a genuine advantage, mean the code carries provider-specific paths that only one of the three is ever going to exercise.

Editorial conclusion

Use NewLife.Redis when you are on .NET and want message queue primitives rather than a bare key-value client, since the reliable queue with RPOPLPUSH and acknowledgement semantics, the delay queue and the stream consumer groups are the parts you would otherwise write yourself. Do not adopt it if you need Redis 7.4 or later features, because the protocol support is documented as covering commands from Redis 2.8 to 7.x. Verify first which target framework your application can actually use, whether you are on the .NET Framework side of the range where the newer runtime features are unavailable, and that the cloud provider you run on, if any, matches one of the adapters, since Alibaba Cloud, Tencent Cloud and Huawei Cloud each need their own configuration.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. NewLifeX/NewLife.Redis on GitHub
4. README
5. Releases