Redis Cache Best Practices for Development
Today in this article we will see a few Redis Cache Design and Best Practices for Development to be considered while developing the application leveraging the Cache architecture.
We will cover the below aspects in this article,
- Naming convention for Redis Key and Namespace
- Size/Lenth of Redis Key and Namespace
- Use the SCAN Vs KEYS command guidelines
- Redis server powerful with rich query pattern – Use Lua Scripts
- Storing the data on the server
- Cache frequently used data
- Managing concurrency in a cache
- Manage Key Expiration in Redis Cache
- Redis – Security for Data
Caching is a typical strategy for improving a system’s performance and scalability.
Cache lets you temporarily copy frequently accessed data to fast storage near to the application.
Caching helps increase response times for client applications by serving data more quickly(data storage is located closer to the application than the original source.)
Cache plays a crucial part in the below aspects of application management,
- Performance
- High Availability
- Reduced downtime
Let’s look at a few high-level guidelines and best practices for developing the application using the Cache architecture.
Naming convention for Redis Key and Namespace
It’s important to follow the basic naming conventions for Redis Key and Namespace upfront to avoid any issues with managing the data on the server.
Redis Cache server is most time used as a shared server across applications/projects and it is likely to contain more data with a similar format as the application grows in size with multiple use cases.
Redis cache is based on key-value pair but with a curated data structure and as long as the key is unique, you are set to leverage all benefits of the data management.
SET key value
If all of your data has to be stored in a single database, please create a namespace with a key prefix.
Below is an example of a key naming pattern
// Set keys for Saving account SET Saving:key1 value SET Saving:key2 value // Set keys for Credit Account SET Credit:key1 value SET Credit:key2 value // Set keys for Personal account SET Personal:key1 value SET Personal:key2 value
The above pattern can be extended as required so that we get the benefit for the same key managed by different applications or domains or modules.
Like we can add additional identifiers like Bank of ABCD
Set keys for Bank of ABCD with saving Account SET BOA:Saving:key1 value
SET BOA:Saving:key2 value
Size/Lenth of Redis Key and Namespace
There are few Guidelines on Redis Key and Namespace
It is important to keep your Redis key names as short as possible.
Even shorter keys should follow the above namespace and key rules.
Any key above 1024 bytes is not recommended as key size may cause issues considering memory and bandwidth.
- Redis key size max is 512 MB.
- Redis Value size max is 512 MB.
The Performance issue however is more observed when dealing with a high volume of data and which also depends on the Redis server configuration.
Use the SCAN Vs KEYS command guidelines
KEY commands
- KEYS command, which returns all matched elements at once, is risky to use in production.
- It may cause your Redis server to become inefficient and even exhaust its RAM resources.
SCAN Commands
- SCAN commands allow you to inspect data without risking your server being blocked.
- SCAN command allows you to get the data without requiring the use of a slave.
- The SCAN command enables you to retrieve keys in the keyspace using a cursor.
- SCAN also accepts a key name pattern and an optional count argument.
- The major difference between SCAN and KEYS is that it is possible to get the same key name more than once with SCAN.
Redis server powerful with rich query pattern – Use Lua Scripts
- Lua scripts on the Redis server make your query pattern very rich with great performance and less server-side resource consumption.
- Server-side query/logics run near to actual data which reduces network latency and redundant transmission of data.
Storing the data on the server
There are multiple ways, data can be stored on the Redis server. Like as below,
- Multiple Redis instances
- Single Redis instances
Cache frequently used data
- Determine data to be cached.
- Cache your most frequently accessed data.
- Cache critical or authoritative information only if needed with the right strategy.
- Do restrict caching for frequently modified data.
Managing concurrency in a cache
Redis cache is designed to be shared by multiple instances of application/system.
However, one can follow any of the below approaches to make sure data is accessed considering the concurrency.
- Optimistic– application checks if data in the cache has changed since it was retrieved. A useful approach when updates are infrequent.
- Pessimistic– When it retrieves the data, the application locks it in the cache to prevent another instance from changing it.
Manage Key Expiration in Redis Cache
- Managing the key Expiration is an important aspect while managing the keys in Reds cache.
- Understand your datastore pattern.
- Carefully check the data expiration. Too short Key expiration will make objects to expires sooner in Cache thereby increasing the call to your backend server also too long data will make you used stale old data producing issues.
Redis – Security for Data
- Redis does not allow data encryption natively, encoding must be done by client applications.
- As Redis does not offer transport security by default, the use of an SSL proxy is recommended if you need to protect data as it travels across the network.
- Redis is designed to run inside a trusted environment and data is accessed by only trusted clients.
Useful References:
Do you have any comments or ideas or any better suggestions to share?
Please sound off your comments below.
Happy Coding !!
Please bookmark this page and share it with your friends. Please Subscribe to the blog to receive notifications on freshly published(2024) best practices and guidelines for software design and development.
