ElastiCache for Redis caching policy

Lazy loading

As the name suggests, lazy loading is a required only when loading data into the cache policy cache. It works as follows.

Amazon ElastiCache is a memory key - value store, located between your application and access its data storage (database). When an application requests data, it sends a request Xianxiang ElastiCache cache. If the data in the cache and the return date, the ElastiCache the data to the application program. If the data is not present in the cache or has expired, then the application requests data from the data store. Then, the data storage returns the data to the application. The next application data received from the write cache memory. In this way, it can retrieve the next more quickly when the data is requested.

When the data in the cache and has not expired, it will happen cache hit :

Application requests data from the cache.
Cache returns data to the application.

When the data is not in cache or has expired, it will take place a cache miss :

Application requests data from the cache.
The requested data is not cached, the flow returns null.
Application requests and receives data from the database.
Applications that use the new data to update the cache.

The following diagram illustrates these two processes.

Advantages and disadvantages of delayed loading

Loading delay following advantages:

Only the requested data cache.

Since most of the data has never been requested, thus avoiding delay loading unsolicited data to fill the cache.
For the application node failure is not fatal.

When a node fails replaced by a new, empty node, the application will continue to run, but the delay will increase. When a request for a new node, each cache misses will result in database queries. Meanwhile, add the copy of the data into the cache, subsequent requests to retrieve from the cache.

Delay loading of the following disadvantages:

Cache misses can result in loss of performance. Every time a cache miss will result in three round-trip:
1. Initial request data from the cache
2. Data Query database
3. Writing data to the cache
The misses will result in a significant delay in the time data reaches the application.
Obsolete data.

If only there is a cache miss writing data to the cache, the data cache may become stale. This result occurs because the cache is not updated when you change the data in the database. To resolve this problem, you can use direct-write and add TTL policy.

Delay loading pseudocode example

The following pseudo-code example of a delay loading logic.

// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is
//    retrieved from the database, 
//    added to the cache, and 
//    returned to the application
// *****************************************
get_customer(customer_id)

    customer_record = cache.get(customer_id)
    if (customer_record == null)
    
        customer_record = db.query("SELECT * FROM Customers WHERE id == {0}", customer_id)
        cache.set(customer_id, customer_record)
    
    return customer_record

For this example, the data acquired as the application code.

customer_record = get_customer(12345)

Direct Writing

Write-through strategy will add or update data in the cache when the data is written to the database.

Direct Writing the pros and cons

The advantages of direct-write as follows:

Data cache timeless.

Because every time data is written to the database will be updated when the data in the cache, the data cache is always up to date.
Read and write performance loss performance loss.

Each write involves two round-trip:
1. Write cache
2. Write to the database
This will increase the delay process. Even so, as compared with the retrieving data delay, end users often more tolerant to delay the update data. There is an inherent meaning, a greater amount of work that is updated, so it takes longer time.

Direct Writing shortcomings are as follows:

The missing data.

If you start a new node, a node failure or whether it is due to the scale, there will be missing data. Before you add or update data in the database, these data have been missing. You can implement using direct writing of lazy loading to minimize this situation.
Cache disturbance.

Most data are never read, this is a waste of resources. By adding time to live (TTL) value , you can minimize wasted space.

Write pseudocode example

The following is an example of pseudo-code write logic.

// *****************************************
// function that saves a customer's record.
// *****************************************
save_customer(customer_id, values)

    customer_record = db.query("UPDATE Customers WHERE id = {0}", customer_id, values)
    cache.set(customer_id, customer_record)
    return success

For this example, the data acquired as the application code.

save_customer(12345,{"address":"123 Main"})

Add TTL

Lazy loading allows obsolete data, but does not fail with an empty node. Direct writing can ensure that data is always current, but may fail with an empty node, and may fill too much data to the cache. By adding to each write survival time (TTL) value, you can get the benefits of each strategy. At the same time, you can avoid the use of additional data buffers confusion to a large extent.

Survival time (TTL) is an integer value, this value specifies the number of seconds before the key expires. Redis this value can be specified number of seconds or milliseconds. When an application attempts to read expired keys will be considered a key was not found. Query the database to get the key and update the cache. This method does not guarantee the value will not become obsolete. But it ensures that data does not become too old, and requires from time to time to refresh the cached value from the database.

For more information, see Redis set commands .

TTL pseudocode example

The following is an example of pseudo-code using a direct-write the TTL logic.

// *****************************************
// function that saves a customer's record.
// The TTL value of 300 means that the record expires
//    300 seconds (5 minutes) after the set command 
//    and future reads will have to query the database.
// *****************************************
save_customer(customer_id, values)

    customer_record = db.query("UPDATE Customers WHERE id = {0}", customer_id, values)
    cache.set(customer_id, customer_record, 300)

    return success

The following pseudo-code example uses the TTL logic delay loading.

// *****************************************
// function that returns a customer's record.
// Attempts to retrieve the record from the cache.
// If it is retrieved, the record is returned to the application.
// If the record is not retrieved from the cache, it is 
//    retrieved from the database, 
//    added to the cache, and 
//    returned to the application.
// The TTL value of 300 means that the record expires
//    300 seconds (5 minutes) after the set command 
//    and subsequent reads will have to query the database.
// *****************************************
get_customer(customer_id)

    customer_record = cache.get(customer_id)
    
    if (customer_record != null)
        if (customer_record.TTL < 300)
            return customer_record        // return the record and exit function
            
    // do this only if the record did not exist in the cache OR
    //    the TTL was >= 300, i.e., the record in the cache had expired.
    customer_record = db.query("SELECT * FROM Customers WHERE id = {0}", customer_id)
    cache.set(customer_id, customer_record, 300)  // update the cache
    return customer_record                // return the newly retrieved record and exit function

For this example, the data acquired as the application code.

save_customer(12345,{"address":"123 Main"})

customer_record = get_customer(12345)