Redisson is not just a Redis client, it is also a Java In Memory Data Grid implemented on top of Redis. Its core goal is to enable Java developers to use Redis in the most natural way possible, by encapsulating complex Redis commands into familiar Java interfaces (such as those under the java. java. concurrent package).
The principle of Redis can be summarized as: implementing high-performance, non blocking communication through Netty, mapping Redis data structures into Java objects and distributed objects, and based on this, utilizing Redis' single threaded atomicity, implementing a series of distributed and thread safe Java commonly used tools.
1. Asynchronous non blocking communication based on Netty
Netty framework: Redisson uses Netty 4+as its network communication framework. This ensures high throughput and low latency connection management. It allows processing thousands of connections simultaneously without creating separate threads for each connection.
Connection management: Redisson maintains a connection pool with Redis servers (which can be in standalone, sentinel, cluster, or other modes). It manages the lifecycle, heartbeat detection, reconnection mechanism, and other aspects of these connections through a Connection Manager.
Asynchronous and Reactive: All operations are asynchronous at the underlying level. When you call get ("key"), Redisson writes a request to the Channel through Netty and immediately returns an RFuture object. You can synchronously wait for this Future (future. get()), or add listeners to it for asynchronous callbacks. This lays the foundation for building high concurrency applications.
2. Encoders and decoders
Redisson uses pluggable codecs to serialize/deserialize Java objects and binary data stored in Redis.
By default, JacksonJsonCodex is used, but you can also choose StringCodex, AvroCodec, or customize it. This ensures the flexibility of storage formats.
This is the most core and clever part of Redisson. It is not just about sending commands, but building a layer of object logic on Redis' data structure.
1. Distributed objects
Redisson has packaged every basic data structure of Redis into a Java object.
RList: List corresponding to Redis. When you call RList. add (object), the underlying layer of Redisson executes the RPUSH command. RList implements the java.util.List interface, so you feel like you're manipulating a local collection.
RMap: Hash corresponding to Redis. Implemented the java.util.Map interface. Use commands such as HMSET and HGETALL at the bottom level.
RSorteSet: The Sorted Set corresponding to Redis. Implemented the java.util.SatedSet interface.
Principle: These objects internally hold a CommandAsynchronous Executor. Every method call you make (such as map. put (key, value)) will be converted into one or more Redis commands and sent to the Redis server through Netty.
2. Distributed collection
This is an extension of distributed objects, adding local caching functionality. For example, RListCache and RMapCache.
Principle: They not only store data in Redis, but also cache a copy in JVM local memory. They ensure local cache consistency across all nodes in the cluster by monitoring Redis' publish subscribe (Pub/Sub) channels. When any node modifies data, it will publish a message, and other nodes receiving it will invalidate their local corresponding cache.
3. Distributed Lock - Core Highlights
This is the most famous feature of Redisson. It implements the java.util-concurrent.locks.Lock interface.
Locking principle (lock() method):
Unique value: Each lock request will have a unique UUID+thread ID as its value. This is used to identify the holder of the lock and prevent other clients from releasing locks that do not belong to them.
Lua script: The locking operation is completed by executing a Lua script. The capital punishment of Lua scripts in Redis is atomic, which is the key to implementing locks.
3. Watchdog mechanism: If the client does not explicitly specify a lock timeout, Redisson will start a watchdog thread. It will continuously extend the holding time of the lock (through the pexfire command) around one-third of the lock expiration time. As long as the JVM does not fail, this lock will not be accidentally released due to timeout, thus avoiding deadlocks. If the JVM crashes, the watchdog thread will also stop and the lock will eventually expire automatically.
Unlocking principle (unlock() method):
Lua script: Atomicity is also ensured through Lua scripts.
The principle of waiting for a lock: If the lock acquisition fails, the client will not keep polling, but will subscribe to a specific channel through Redis' publish subscribe (Pub/Sub) function. When the lock is released, the client currently holding the lock will issue a message (as seen at the end of the unlock script above), and all waiting clients will receive a notification and then competitively attempt to lock again. This greatly reduces unnecessary network requests.
4. Other synchronizers (such as RSemaphore, RCountDownLatch)
The principle is similar to locks, both based on Redis' atomic operations (Lua scripts) and publish subscribe mechanisms.
RSemaphore: Use Redis' string structure to store the number of licenses. Acquire() reduces the quantity, release() increases the quantity. If there is no license, wait by publishing and subscribing.
RCountDownLatch: Store counts using Redis' string structure. CountDown() decreases the count, await () waits for the count to become 0. When the count is 0, notify all waiting threads by publishing and subscribing.
Redisson can seamlessly work with Redis clusters.
Automatic redirection: When executing a command in cluster mode, if an - MOVED error is returned, Redisson's ClusterConnection Manager will automatically update its Slot Node mapping table and re route the command to the correct node.
Pipelining: Supports packaging multiple commands into a pipeline and sending them in cluster mode to improve performance.
Network and Communication: A high-performance, asynchronous, and non blocking communication model based on Netty.
Atomicity cornerstone: Fully utilize the atomicity of Lua scripts executed in Redis to achieve complex distributed synchronization logic.
Event driven: The widely used publish subscribe (Pub/Sub) mechanism is used to implement event notifications, avoiding inefficient polling such as lock waiting and cache invalidation.
Object Mapping: Mapping Redis data structures to familiar Java object interfaces (List, Map, Lock, etc.) through codecs.
Fault tolerance and high availability: The robustness of the service is ensured through the support of watchdog mechanism, connection pool management, reconnection mechanism, sentinel, and cluster mode.
Simply put, the principle of Redisson is to "use Redis commands as bricks and tiles, Lua scripts as cement, Netty as the skeleton, and build a building called 'Distributed Tools' for the Java world. It provides you with a programming experience that is almost identical to a standalone application in a distributed environment.