Redis 10 tips for proper use _redis

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

Okay, it may not be a good way to start this article with the challenge of this command, but it is probably the most important point. Many times when we focus on a Redis instance of statistics, we quickly enter the "KEYS *" command, so that key information is clearly displayed. To be fair, from a programmatic standpoint, you tend to write the following pseudocode:

For key in ' keys * ': 
 doallthethings () 

But when you have 13 million keys, the execution speed slows down. Because the time complexity of the keys command is O (n), where n is the number of keys to return, the complexity of the command depends on the size of the database. And during the execution of this operation, none of the other commands can be executed in your instance.

As an alternative command, take a look at SCAN, which allows you to perform in a friendlier way ... SCAN scans the database through incremental iterations. This operation is done based on the cursor iterator, so you can stop or continue whenever you feel appropriate.

2, find the culprit of slowing down Redis

Since Redis does not have a very detailed log, it is very difficult to know what has been done inside the Redis instance. Fortunately, Redis provides a command statistic tool such as the following:

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 snapshots of all command statistics, such as how many times the command was executed, the number of milliseconds to execute the command (the total time and average time of each command)

Simply execute the CONFIG resetstat command to reset it so you can get a whole new statistic.

3, will redis-benchmark result as a reference, but not generalize

Redis's father, Salvatore, said: "Testing Redis by executing get/set commands is like detecting the effect of Ferrari wiper cleaning mirrors on a rainy day." A lot of times people come to me and they want to know why their Redis-benchmark stats are less than the best results. But we have to take all the different realities into account, such as:

• What clients may be constrained by the environment in which they run?
• Is it the same version number?
• Does the performance in the test environment coincide with the environment in which the application will run?

Redis-benchmark's test results provide a reference point that guarantees that your redis-server will not run in an abnormal state, but you should never use it as a real "stress test". Stress tests need to reflect how the application operates and require a similar environment to be produced as much as possible.

4, hashes is your best choice

Introduce hashes in an elegant way. Hashes will bring you an unprecedented experience. I've seen many key constructs like the following:

Foo:first_name 
foo:last_name 
foo:address 

In the example above, Foo may be the user name of a user, each of which is a separate key. This increases the space for error and some unnecessary key. Use 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< c11/>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 key value of the survival time

Whenever possible, take advantage of key timeout. A good example is to store something such as a temporary authentication key. When you go to look up an authorization key--take OAuth as an example--usually you get a time-out. So when you set the key, set the same timeout time, Redis will automatically clear for you! And no longer need to use the keys * to traverse all the key, how convenient is it?

6, choose the appropriate recycling strategy

Now that we've talked about clearing key, let's talk about recycling strategies. When the Redis instance space is filled, a portion of the key is attempted to be reclaimed. Depending on how you use it, I strongly recommend using the VOLATILE-LRU policy-if you have set a timeout for key. But if you're running something similar to cache, and you don't have a time-out mechanism on the key, consider using the ALLKEYS-LRU recycle mechanism. My suggestion is to look at the feasible plan here first.

7, if your data is very important, please use the try/except

If you have to ensure that critical data can be put into an Redis instance, I strongly recommend putting it in a try/except block. Almost all Redis clients use "send-and-forget" policies, so it is often necessary to consider whether a key is actually placed in the Redis database. As for the complexity of putting try/expect into the Redis command, this is not what this article is about, you just need to know that you can make sure that the important data is put where it is.

8. Do not run out of an instance

Whenever possible, spread the workload of multiple Redis instances. Starting with version 3.0.0, Redis supports clustering. The Redis cluster allows you to isolate key elements that contain the master/from mode based on the key range. The "magic" behind the complete cluster can be found here. But if you're looking for a tutorial, it's a good place to be. If you can't select a cluster, consider the namespace, and then spread your key across multiple instances. There's this wonderful comment on the Redis.io website about how to distribute the data.

9, the more the kernel the better?

Of course it's wrong. Redis is a single-threaded process that consumes up to two cores even if it is enabled for persistence. Unless you plan to run multiple instances on a single host-hopefully only in the development test environment! -Otherwise, it does not require more than 2 cores for a Redis instance.

10, High availability

So far Redis Sentinel has been thoroughly tested, and many users have applied it to the production environment (including Objectrocket). If your application is heavily dependent on redis, you need to come up with a highly available solution to ensure that it does not fall off the line. Of course, if you don't want to manage these things yourself, Objectrocket provides a highly available platform and provides 7x24-hour technical support, which you can consider if you wish.

The above is about the correct use of Redis 10 skills, I hope to help you learn, Resolute collection bar