Mastering NewLife.Redis: Architecture, Usage, and Performance Tips

1. Redis Encapsulation Architecture

NewLife.Redis implements the full Redis protocol, but the core functionality lives in NewLife.Core under the NewLife.Caching namespace, which provides the Redis class for basic commands and the RedisClient class representing a client connection. A connection pool holds many RedisClient objects, and FullRedis adds all advanced Redis features.

2. Basic Usage with Test Examples

The Program.cs example shows how to enable console logging with XTrace.UseConsole();. Test1 demonstrates Set and Get behavior: strings are stored directly, other types are JSON‑serialized; Get deserializes JSON back to objects. The third parameter of Set specifies expiration time in seconds. Debugging tips include launching only the needed project to speed up compilation.

3. Stress Testing

A benchmark script performs Get, Set, Remove, and increment operations. On a single machine the test reaches about 600 k operations per second; with multithreading it exceeds 1 M ops. Bench parameters include thread count, random key/value generation ( rand), and batch size using GetAll / SetAll for optimization.

4. Advanced Performance Features

GetAll/SetAll batch retrieve or set multiple keys in a single command, reducing round‑trips dramatically.

Pipeline groups commands; StartPipeline() begins and StopPipeline() ends the batch. AutoPipeline automatically flushes when a threshold is reached, removing the need for explicit start/stop calls.

Add and Replace provide conditional insert ( Add succeeds only if the key does not exist) and unconditional update ( Replace), useful for implementing distributed locks.

5. Practical Experience and Tips

In ZTO’s real‑time platform, over 200 Redis instances have run stably for more than a year, processing nearly 1 billion packages daily with 80 billion calls.

Average Get/Set latency is 200‑600 µs (including network round‑trip).

The built‑in connection pool supports up to 1 000 concurrent connections.

Binary serialization is significantly faster than JSON.

Deploy one Redis instance per CPU core, each using the full physical memory of the host to avoid memory exhaustion.

Distribute data across instances using key hashing (Crc16/Crc32) to achieve linear performance scaling.

Design each key/value size so that network packets stay around 1.4 KB, reducing the number of round‑trips.

Use pipelines and batch commands to mitigate serialization, bandwidth, and memory bottlenecks.

6. FAQ

Multiple keys for one data : If performance is not critical, store the whole object as JSON; otherwise consider a dictionary layout.

Queue vs List : Redis List implements both queue and stack semantics; use a dedicated queue when you need left‑push/right‑pop behavior.

Performance of objects with many fields : Generally similar, but very large datasets may show differences.

Big‑data storage : Split tables/databases so each shard contains fewer than ten million rows.

CPU spikes : Aim for near‑100 % CPU utilization; if the CPU is lower, investigate code inefficiencies or serialization overhead.