10 Redis usage tips

Redis is very popular in the current technology community. Redis has come a long way from a small personal project from Antirez to becoming the industry standard for in-memory data storage. The resulting set of best practices allows most people to use Redis correctly.

1. Stop using KEYS *

Okay, starting this article by challenging this command may not be a good way, but it is indeed possible is the most important point. Many times when we pay attention to the statistics of a redis instance, we will quickly enter the "KEYS *" command so that the key information will be clearly displayed.

From a programming perspective, we tend to write the following pseudocode:

for key in'keys *': doAllTheThings()　　

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

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

2. Find out the culprit that slows down Redis

Since Redis does not have very detailed logs, it is very difficult to know what is done inside the Redis instance. Fortunately, Redis provides a command statistics tool like 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

Through this tool, you can view a snapshot of all command statistics, such as how many times the command has been executed and the number of milliseconds it took to execute the command (each command The total time and average time)

Just simply execute the CONFIG RESETSTAT command to reset it, so that you can get a brand new statistical result.

3. Use the Redis-Benchmark results as a reference instead of generalizing. Salvatore, the father of Redis, said: “Testing Redis by executing GET/SET commands is like testing a Ferrari on a rainy day. The effect of a wiper cleaning a mirror." Many times people come to me and they want to know why their Redis-Benchmark statistics are lower than the optimal results. But we must take into account various real situations.

For example:

What client running environment restrictions may be imposed? Is
the same version number?
Is the performance in the test environment consistent with the environment in which the application will be run?
The test results of Redis-Benchmark provide a benchmark point to ensure that your Redis-Server will not run in an abnormal state, but you should never take it as a real " pressure test". Stress testing needs to reflect how the application is running and needs an environment that is as similar to production as possible.

4. Hashes is your best choice

Introduce hashes in an elegant way. Hashes will bring you an unprecedented experience. I have seen many key structures similar to the following before:

foo:first_name foo:last_name foo:address

In the above example, foo may be the username of a user, and each item in it is a separate key. This increases the room for error and unnecessary keys. Use hash instead, you will 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 key timeout . A good example is storing something like a temporary authentication key. When you look up an authorization key - take OAUTH as an example - you usually get a timeout.

In this way, when setting the key, set it to the same timeout period, and Redis will automatically clear it for you! It is no longer necessary to use KEYS * to traverse all keys. How convenient?

6. Choose an appropriate recycling strategy

Now that we’ve talked about clearing keys, let’s talk about recycling strategies. When the Redis instance space is filled up, it will try to reclaim some keys. Depending on your usage, I strongly recommend using the volatile-lru strategy - provided you have set a timeout on the key.

But if you are running something similar to cache and do not set a timeout mechanism for the key, you can consider using the allkeys-lru recycling mechanism.

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

If you must ensure that critical data can be put into a Redis instance, I strongly recommend that you put it in in a try/except block. Almost all Redis clients adopt the "send and forget" strategy, 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 in the Redis command, this article is not about it. You just need to know that doing so can ensure that important data is placed where it should be.

8. Don’t exhaust an instance

Whenever possible, spread the workload of multiple redis instances. Starting from version 3.0.0, Redis supports clusters. Redis Cluster allows you to separate out some keys that contain master/slave modes based on key ranges. The complete "magic" behind clustering can be found here.

But if you are looking for tutorials, then this is a perfect place. If clustering isn't an option, consider namespaces and spreading your keys across multiple instances.

9. Are the more cores the better? !

Of course it is wrong. Redis is a single-threaded process and only consumes a maximum of two cores even with persistence enabled. Unless you plan to run multiple instances on a single host - hopefully only in a development and test environment! ——Otherwise, there is no need for 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 production environments (including ObjectRocket). If your application relies heavily on Redis, you need to come up with a high availability solution to ensure that it does not go offline.

For more related knowledge, please pay attention to thejava basic tutorialcolumn

The above is the detailed content of 10 Redis usage tips. For more information, please follow other related articles on the PHP Chinese website!