10 tips for using Redis correctly

Redis is very popular in the current technology community. From a small personal project from Antirez to becoming the standard in the in-memory data storage industry, Redis has come a long way.
1. Stop using KEYS *

Okay, challenging this command to start this article, may not be a good way, but it is probably the most important point. Most of the time when we are looking at the statistics for an instance of redis, we will quickly enter the "KEYS *" command so that the information of key will be clearly displayed. To be fair, from a programmatic perspective, you tend to write pseudo-code like this:

for key in 'keys *': 
 doAllTheThings() 

But when you have 13 million key, the execution will slow down. Since the time complexity of the KEYS command is O(n), where n is the number of keys to return, the complexity of this command depends on the size of the database. And during the execution of this operation, no other command can be executed in your instance.

As an alternative command, take a look at SCAN 1, which allows you to execute it in a more friendly way... SCAN scans the database through incremental iterations. This 1 operation is done based on the cursor's iterator, so you can stop or continue as you see fit.

2. Find the culprit that is slowing down the Redis

Since Redis does not have a very detailed log, it is difficult to know what is going on inside an Redis instance. Fortunately, Redis provides a command statistics tool that looks like this:

127.0.0.1:6379> INFO commandstats 
# Commandstats 
cmdstat_get:calls=78,usec=608,usec_per_call=7.79 
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20 
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00 
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10 

This tool allows you to view a snapshot of all command statistics, such as how many times the command was executed and how many milliseconds it took to execute the command (total and average time per command)

Simply execute the CONFIG RESETSTAT command to reset, and you'll get a new statistic.

3. Use the Redis-Benchmark results as a reference, not a generalization of 1

Salvatore, the father of Redis, once said, "testing Redis by executing the GET/SET command is like testing the cleaning effect of ferrari's wipers on the mirror on a rainy day". A lot of times people come to me and they want to know why their Redis-Benchmark statistic is less than optimal. But we have to take into account different realities, such as:

What client runtime environments might be limited by? Is it the same version number? Does the performance in the test environment correspond to the environment in which the application will run?

The Redis-Benchmark test results provide a baseline to ensure that your Redis-Server does not run under abnormal conditions, but you should never treat it as a real "stress test." The stress test needs to reflect how the application is running and needs an environment that is as close to production as possible.

4. Hashes is your best bet

Introduce hashes in an elegant way. hashes will give you an experience you've never had before. I have seen many key structures like the following before:

foo:first_name 
foo:last_name 
foo:address 

In the example above, foo might be the username of a user, where each entry is a separate key. This increases the room for error, and some unnecessary key. Use the hash instead, and you'll be surprised to find that you only need one key:

127.0.0.1:6379> HSET foo first_name "Joe" 
(integer) 1 
127.0.0.1:6379> HSET foo last_name "Engel" 
(integer) 1 
127.0.0.1:6379> HSET foo address "1 Fanatical Pl" 
(integer) 1 
127.0.0.1:6379> HGETALL foo 
1) "first_name" 
2) "Joe" 
3) "last_name" 
4) "Engel" 
5) "address" 
6) "1 Fanatical Pl" 
127.0.0.1:6379> HGET foo first_name 
"Joe" 

5. Set the survival time of the key value

Whenever possible, take advantage of the timeout advantage of key. A good example is to store something like temporary authentication key. When you go looking for an authorization key -- OAUTH for example -- you usually get a timeout. When you set key to the same timeout, Redis will automatically clear it for you! Instead of having to use KEYS * to traverse all of key, how convenient is that?

6. Choose the right recycling strategy

Now that we're on the topic of cleaning up key, let's talk about recycling strategies. When the instance space of Redis is filled, part 1 of key will be recycled. Depending on how you use it, I strongly recommend using the Volatile-lru policy -- if you've set a timeout for key. But if you're running something like cache and you don't have a timeout mechanism for key, consider using the allkeys-lru recall mechanism. My suggestion is to look at 1 possible options here first.

7. If your data is important, use Try/Except

If you must ensure that critical data can be put into an instance of Redis, I strongly recommend putting it into the try/except block. Almost all Redis clients use a "send and forget" policy, so it is often necessary to consider whether an key is actually in the Redis database. As for the complexity of putting try/expect into the Redis command, that's not the point of this article. You just need to know that doing so ensures that important data is in the right place.

Don't run out of an instance

Whenever possible, spread out the workload of more instances of redis. Since version 3.0.0, Redis has supported clustering. The Redis cluster allows you to separate out part of key that contains master/slave patterns based on the key scope. The "magic" behind the full cluster can be found here. But if you're looking for a tutorial, this is the perfect place. If clustering is not an option, consider the 1 namespace and spread your key across multiple instances. An excellent review of how to allocate data is available on the redis.io website.

9. The more cores, the better?

Wrong, of course. Redis is a single-threaded process that consumes at most two kernels, even if persistence is enabled. Unless you plan to run multiple instances on one host -- hopefully only in a development and testing environment! Otherwise, no more than 2 cores are required for 1 instance of Redis.

10. High availability

Redis Sentinel has been thoroughly tested so far, and many users have used it in production environments (including ObjectRocket). If your application relies heavily on Redis, you'll need to come up with a high-availability plan to keep it from dropping. Of course, if you don't want to manage these things yourself, ObjectRocket offers a highly available platform with 7×24 hours of technical support, so consider 1 if you're interested.

These are the 10 tips for the correct use of Redis. I hope they will help you in your study