Ten tips for using Redis correctly

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 standard in the memory data storage industry. A series of best practices followed, making it possible for most people to use Redis correctly. Below we will explore 10 tips for using Redis correctly.

1. Stop using KEYS *

Okay, starting this article with the challenge of this command may not be a good way, but it is probably the most important point. Many times when we focus on the statistics of a Redis instance, we quickly enter the "KEYS *" command so that the key information is clearly displayed. In all fairness, from a programmatic point of view tends to write the following pseudo-code:

123	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, 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 a way that incrementally iterates. This is done based on a cursor iterator, so you can stop or continue whenever you feel fit.

2. Find the culprit behind slow Redis

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

123456

127.0.0.1:6379> INFO commandstats# Commandstatscmdstat_get:calls=78,usec=608,usec_per_call=7.79cmdstat_setex: Calls=5,usec=71,usec_per_call=14.20cmdstat_keys:calls=2,usec=42,usec_per_call=21.00cmdstat_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, the number of milliseconds it took to execute the command (the total time and the average time for each command)

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

3, the Redis-benchmark results as a reference, and not generalize

Salvatore, the father of Redis, said: "Testing redis by executing the get/set command is like testing the effect of a Ferrari wiper cleaning mirror on a rainy day." Many times people come to me and they want to know why their redis-benchmark statistics are lower than the best results. But we have to think of different realities, such as:

• What are the possible client operating environment limitations?

• 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 operates and requires a similar environment as possible to produce.

4, hashes is your best choice

Introduce hashes in an elegant way. Hashes will bring you an unprecedented experience. I've seen a lot of key structures like this before:

123	Foo:first_namefoo:last_namefoo:address

In the above example, Foo may be a user's user name, each of which is a separate key. This increases the   error space, and some unnecessary keys. Instead of using a hash, you'll be amazed to find that you only need a key:

123456789101112

127.0.0.1:6379> hset foo first_name "Joe" (integer) 1127.0.0.1:6379> hset foo last_name "Engel" (integer) 1127.0.0.1 :6379> hset foo Address "1 fanatical Pl" (integer) 1127.0.0.1:6379> hgetall foo1) "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 key timeout. A good example of this is storing things like temporary authentication keys. When you go to find an authorization key--take OAuth as an example--you usually get a time-out. This way, when you set the key, the same time-out period, Redis will be automatically cleared for you! Instead of having to use keys to traverse all the keys, how easy 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, it will attempt to reclaim some of the keys. Depending on how you use it, I strongly recommend using the VOLATILE-LRU policy-if you have set a timeout on key. But if you're running something like the cache, and you don't have a timeout mechanism set on the key, consider using the ALLKEYS-LRU recycle mechanism. My advice is to take a look at the possible scenarios here first.

7. If your data is important, please use try/except

If you have to ensure 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 it is often necessary to consider whether a key is actually placed in the Redis database. The complexity of putting try/expect into Redis commands is not what this article is about, you just need to know that this will ensure that important data is placed where it should be.

8. Do not exhaust an instance

Distribute the workload of multi-redis instances whenever possible. Starting with version 3.0.0, Redis supports clustering. A Redis cluster allows you to isolate a part of a key that contains a master/slave pattern 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 a wonderful comment on how to distribute data on the Redis.io website.

9, the more cores 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 the context of development testing! --otherwise, no more than 2 cores are required for a Redis instance.

10. High Availability

Redis Sentinel has been thoroughly tested so far, 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 high-availability scheme to keep it out of 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 think about.

If you want to dive into the Linux system novice, you can also download a German Linux software center trial.
Free: Http://www.nfs-cloud.cn:81/appCenter/open/softcenter

Ten tips for using Redis correctly