Shulou(Shulou.com)06/01 Report--

What this article shares with you is about the Redis experience that Linux operators need to know. The editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article. Let's take a look at it with the editor.

Redis is very popular in the current technology community. From a small personal project at Antirez to becoming the standard in the in-memory data storage industry, Redis has come a long way. The resulting series of best practices make it possible for most people to use Redis correctly.

Below we will explore 10 experiences of using Redis correctly.

1. Stop using KEYS *

Okay, which begins this article by challenging this command, may not be a good way, but it is probably the most important point. Many times when we look at the statistics of a redis instance, we quickly enter the "KEYS *" command so that the key information is clearly displayed. To be fair, it tends to write pseudo-code like this from a programmatic point of view:

For key in'keys *': doAllTheThings ()

But when you have 13 million key, the execution speed will be slower. Because the time complexity of the KEYS command is O (n), where n is the number of keys to be returned, the complexity of the 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 execute in a more friendly way. SCAN scans the database through incremental iterations. This is done based on the cursor iterator, so you can stop or continue as long as you see fit.

2. Find out the culprit that slows down Redis

Since Redis does not have a very detailed log, it is very difficult to know what is done inside the Redis instance. Fortunately, Redis provides a command statistics tool 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 snapshots of all command statistics, such as how many times the command was executed and the number of milliseconds it took to execute the command (total and average time per command)

Simply execute the CONFIG RESETSTAT command to reset it, so you can get a whole new statistical result.

3. Take the Redis-Benchmark results as a reference, rather than generalize them.

Salvatore, the father of Redis, said: "testing Redis by executing GET/SET commands is like testing the effectiveness of Ferrari wipers in cleaning mirrors on rainy days." A lot of times people come to me and they want to know why their Redis-Benchmark statistics are lower than the optimal results. But we have to take into account different real situations, such as:

What are the possible limitations of the client operating environment?

Is it the same version number?

Is the performance in the test environment consistent with the environment in which the application will run?

Redis-Benchmark 's test results provide a benchmark to ensure that your Redis-Server will not run in an abnormal state, but you should never use it as a real "stress test". Stress testing needs to reflect the way the application works, and requires an environment as similar as possible to production.

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 user name of a user, each of which is a separate key. This increases the room for mistakes and some unnecessary key. Use hash instead, and you'll be surprised to find that only one key is needed:

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

5. Set the survival time of key value

Take advantage of key timeouts whenever possible. A good example is storing things such as temporary authentication key. When you look up an authorized key-- take OAUTH, for example-- you usually get a timeout. In this way, when setting key, set the same timeout, and Redis will automatically clear it for you! Instead of using KEYS * to traverse all the key, how convenient is that?

6. Choose the appropriate recycling strategy

Now that we're talking about removing key, let's talk about recycling strategies. When the instance space of the Redis is filled, an attempt will be made to recycle a portion of the key. Depending on how you use it, I strongly recommend using the volatile-lru strategy-- provided you have set a timeout for key. But if you are running something similar to cache and do not set a timeout mechanism for key, consider using the allkeys-lru recycling mechanism. My suggestion is to check out the feasible plan here first.

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

If you have to make sure that critical data can be put into an instance of Redis, I strongly recommend that you put it in a try/except block. Almost all Redis clients use a "send-and-forget" strategy, so you often need to consider whether a key is actually placed in an Redis database. As for the complexity of putting try/expect in Redis commands is not the subject of this article, you just need to know that doing so ensures that important data is where it should be. Welcome to follow my public Hao [programmer chase wind]. In 2019, more than 1000 java interview questions have been sorted out and more than 400 pages of pdf documents have been sorted out. The article will be updated inside, and the collated information will be put in it.

8. Don't exhaust an instance

Whenever possible, spread the workload of multiple redis instances. Redis has supported clustering since version 3.0.0. Redis clusters allow you to separate parts of the key that contain master / slave patterns based on the key scope. The magic behind the complete cluster can be found here. But if you're looking for tutorials, this is the perfect place. If you can't choose a cluster, consider the namespace and spread your key across multiple instances. There is this wonderful review on how to distribute data on the redis.io website.

9. The more kernels, the better?!

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

10. High availability

Redis Sentinel has been thoroughly tested so far, and many users have applied it to production environments (including ObjectRocket). If your application is heavily dependent on Redis, you need to come up with a highly available solution to make sure it doesn't go offline. Of course, if you don't want to manage these things yourself, ObjectRocket provides a highly available platform and provides 7 × 24-hour technical support, so consider it if you are interested.

These are the Redis experiences that Linux operators need to know. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.