A fast, highly available, resilient, and scalable caching layer that spans across clouds
A basic caching layer meets the minimum requirements of temporarily storing data so that repeated database requests can be served faster. Enterprise caching includes enterprise-grade functionality to ensure modern applications can linearly scale without performance degradation.
| Basic Caching | Enterprise Caching | |
|---|---|---|
| Linear scaling without performance degradation | • | |
| Guaranteed sub-millisecond latency | • | |
| Five-nines high availability for always-on data access | • | |
| Local read/write latency across on-premise, clouds, and geographies | • | |
| Hybrid and multicloud deployment | • | |
| Optimized TCO | • | |
| RBAC (Role-Based Access Control) | • | |
| Ease of deployment across clusters and regions | • | |
| Enterprise-grade support from the creators of Redis | • |
Can your cache stand up to modern application needs?
To find out more, read The Definitive Guide to Caching at Scale
This is the most common way to use Redis as a cache. With this strategy, the application first looks into the cache to retrieve the data. If data is not found (cache miss), the application then retrieves the data from the operational data store directly. Data is loaded to the cache only when necessary (hence: lazy-loading). Read-heavy applications can greatly benefit from implementing a cache-aside approach.
In this strategy, data is first written to cache (for example, Redis), and then is asynchronously updated in the operational data store. This approach improves write performance and eases application development since the developer writes to only one place (Redis). RedisGears provides both write-through and write-behind capabilities.
Write-through cache strategy is similar to the write-behind approach, as the cache sits between the application and the operational data store, except the updates are done synchronously. The write-through pattern favors data consistency between the cache and the data store, as writing is done on the server’s main thread. RedisGears provides both write-through and write-behind capabilities.
In an environment where you have a large amount of historic data (e.g. a mainframe) or have a requirement that each write must be recorded on an operational data store, Redis Enterprise change data capture (CDC) connectors can capture individual data changes and propagate exact copies without disrupting ongoing operations with near real-time consistency. CDC, coupled with Redis Enterprise’s ability to use multiple data models, can give you valuable insight into previously locked up data.
Front-end for DBMS
Legacy and traditional SQL databases were designed for functionality rather than speed at scale. A cache is often used to store copies of lookup tables and the replies to costly queries from the DBMS to reduce latency and significantly increase throughput. Enterprise caching solutions enable front-end DBMS to be always available and easily scale.
User session data
Caching user session data is an integral part of building scalable and responsive applications. Because every user interaction requires access to the session’s data, keeping that data in the cache speeds response time to the application user. Enterprise cache is used to handle the tremendous growth in user session data and the requirement to be available 24×7.
API responsiveness
Today’s modern applications use APIs to make requests for service from other components, whether inside (microservices architecture) or outside (SaaS) the application itself. Enterprise cache ensures these communications are always real-time to enable real-time application responses.
Redis is designed around the concept of data structures and can store your dataset across Strings, Hashes, Sorted Sets, Sets, Lists, Streams, and other data structures or Redis modules.
// connecting redis client to local instance.
const client = redis.createClient(6379)
// Retrieving a string value from Redis if it already exists for this key
return client.get('myStringKey', (err, value) => {
if (value) {
console.log('The value associated with this key is: ' + value)
} else { // key not found
// Storing a simple string in the Redis store
client.set('myStringKey', 'Redis Enterprise Tutorial');
}
});
This snippet tries to retrieve the string value associated with the myStringKey key using the GET command. If the key is not found, the SET command stores the Redis Enterprise Tutorial value for myStringKey.
The same code can be written in Python, as shown here:
# Connecting redis client to local instance.
r = redis.Redis(host = 'localhost', port = 6379, db = 0)
# Retrieving a string value from Redis if it already exists
for this key
value = r.get('myStringKey')
if value == None: # key not found
# Storing a simple string in the Redis store
r.set('myStringKey', 'Redis Enterprise Tutorial')
else :
