redismodule-smartcache

Read through cache based on Redis

GET "SELECT firstname,lastname,age FROM customer" 

Returns the value of the "key" if found, otherwise it blocks the current client connection (to unblock the Redis main thread), start a thread to get the value from MySQL, stores it in Redis in the "key" with a TTL and unblock the connection to return the value.

First implemented in 2017 to try the new module API. Moved/Forked from GitHub to cerbelle.net for a better project management in 2022.

Devel restarted in 2025 with v0.0.2 to support

• flexible and extendable source DB connections (including noSQL)
• multi-source DB (SQL, NOSQL, streams from CDC)
• write-through (sync) and write-behind (async)
• scalability (sharded cache)
• Data transformation
• Data prefetch
• redis-cluster and redis-enterprise
• Fully asynchronous (non-blocking) operation management for optimal performances
• Fully transparent for the client application (diverting standard Redis commands)

The module is designed to support (despite not yet implemented) read-through on a remote database with or without transformation together with write-through (sync or async) with or without transformation into another or same remote database. All the features to achieve this goal are in the roadmap.

The configuration database can be stored using :

• Internal : the configuration is only stored in internal structures in the module RAM. This storage is the fastest but makes the backup files dependent on the module at restore time, which can be an issue for long-term backups. Currently replication or persistency are not yet supported.
• LocalRedis : stored in the Redis process which loaded the module, in Redis data structures (HASHes and SETs), with persistency and replication support. This can not support clustering. Backup files can be loaded without the module. This storage is not yet implemented.
• RemoteRedis : Any Redis database (the one which loaded the module or any other one), using any Redis architecture (redis-server, redis-sentinel, redis-cluster, redis-enterprise), with or without TLS (server and client certificates are supported), with or without authentication (password only, username/password provided by ACLs), with RESP2 or RESP3 protocol, with client-side caching (in internal module structures) or not, with auto-reconnect in case of disconnection. This is the most versatile storage, at the expense of very small performance impact, the backup files can be restored without the module. Currently, redis-cluster and redis-sentinel are not yet supported.

These storage ensure scalability, persistency, and high-availability.