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 the KEYS * Okay, to challenge this command to start this article, may not be a good way, but it may indeed be 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 standpoint, you tend to write the following pseudo-code: for key in ' keys * ': doallthethings () But when you have 13 million keys, the execution speed slows. 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 for 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 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 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 of each command) Simply execute the CONFIG resetstat command to reset it so you can get a completely new statistic. 3, willRedis-benchmark the results as a reference, instead of generalize Redis's father Salvatore said, "Testing redis by executing get/set commands is like testing the effect of a Ferrari wiper cleaner 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 take into account a variety of different realities, such as: What are the client operating environments that may be limited? 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 in an elegant way to introduce the hashes bar. Hashes will bring you an unprecedented experience. I have seen many key structures like the following: Foo:first_name foo:last_name foo:address The above example, Foo may be a user's user name, each of which is a separate key. This increases the space for mistakes and unnecessary keys. Instead of using a hash, you'll be amazed to find that you only need a 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 to 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--Usually you 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, use try/except if you have to ensure that critical data can be put into a Redis instance, I strongly recommend placing 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 whenever possible, distribute the work of a multi-redis instance whenever it is likely. 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 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 high-availability scheme to keep it out of line. Free pick up brother even it education original cloud Computing Training video/Detailed Linux tutorials, details Inquiry official website customer Service: http://www. lampbrother.net/linux/or hooking up q2430675018~ Welcome to the Linux Communication Group 478068715

10 tips for using Redis correctly