1, stop using the * KEYS
Okay, began to challenge the command of this article, perhaps not a good way, but it really is probably the most important point.
Many times when we are concerned about the statistics a redis example, we will quickly enter "KEYS *" command, so that key information will be clearly displayed. In all fairness, from the procedural point of view we tend to write pseudo code like the following:
for Key in 'Keys *':
doAllTheThings ()
but when you have 13 million key, execution speed will be slower. KEYS command because the time complexity is O (n), where n is the number of keys to be returned, so that the complexity of this command depends on the size of the database. And during this operation is performed, you can not execute any other commands in your instance.
As an alternative command, SCAN look at it, which allows you to perform in a more friendly way ... SCAN to scan the database by way of incremental iterations. This operation cursor-based iterator to complete, so as long as you see fit, you can stop or continue at any time.
2, to find the culprit Redis slow down
due Redis is not very detailed log, to know Redis instances in the interior have done is very difficult. Fortunately Redis provides a command such as the following statistical tools:
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 is, usec_per_call = 14.20
cmdstat_keys: Calls = 2, usec = 42 is, usec_per_call = 21.00
cmdstat_info: Calls = 10, usec = 1931, usec_per_call = 193.10
can view all commands statistical snapshot of this tool, execute commands such as how many times the number of milliseconds it takes to execute the command (total time and average time per order)
simply execute CONFIG RESETSTAT command to reset so you can get a brand new statistics.
3, Redis-Benchmark result as a reference, but do not generalize
Redis Father Salvatore had said: "tested by performing GET / SET commands like Redis detecting wipers clean the mirror effect of Ferrari in the rain." Many times people running to me, they want to know why their Redis-Benchmark survey results less than optimal results. But we must take a variety of real situations into account, such as:
limit which the client operating environment might be?
Is the same version number?
Performance and application testing environment will run the environment are the same?
Redis-Benchmark test results provide a guarantee of your Redis-Server does not run at the reference point in the non-normal state, but you never put it as a real "stress test." The reaction requires an stress test operation mode of application, and requires as much as possible and produce a similar environment.
4, Hashes are your best choice
in an elegant way to introduce hashes it. hashes will bring you an unprecedented experience. Before I have seen many such key structure similar to the following:
foo: first_name
foo: last_name
foo: address
above example, foo can be a user name, each one is a separate key. This increases the space to make mistakes, and unnecessary key. Instead of using a hash of it, you will be surprised to find that even just 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
- “first_name”
- “Joe”
- “last_name”
- “Engel”
- “address”
- "Fanatical Pl 1"
127.0.0.1:6379> HGET foo first_name
"Joe"
5, set the survival time key value
no matter what time, as long as possible on the use of time-out of key advantages. A good example is to store things such as the number of temporary authentication key and the like.
When you go to look up a key authorization when - to OAUTH, for example - usually get a timeout. Such set key when set to the same timeout, Redis will be automatically cleared to you! And no longer need to use the KEYS * to loop through all the key, and how easy it?
6, select the appropriate recovery strategies
since talked about the Clear key topic, then we have to talk about recovery strategies. When Redis instance space is filled, it will try to recover a portion of the key. Depending on your usage, I strongly recommend the use of volatile-lru policy - provided that you have set for key timeout.
But if you're running something similar to cache things, and there is no set time-out mechanism for key, consider using allkeys-lru recovery mechanisms. My advice here is to look at possible options.
7. If your data is important, use the Try / Except
If you have to make sure that critical data can be put to an instance Redis, I strongly recommend to put try / except block. Almost all of the clients using Redis is "send and forget" strategy, it is often really need to consider whether a key is put in the Redis database. As for the try / expect into the complexity of this article is not to talk about Redis commands, you just need to know to do so can ensure that important data into the place to put it.
8, do not run out of an instance
whenever, whenever possible decentralized multi-redis instance workload. From the beginning of version 3.0.0, Redis to support the cluster. Redis clustering allows you separate the main portion comprising key / slave mode based on a key range. Complete cluster behind the "magic" can be found here.
But if you are looking for tutorials, then there is a place, but right then. If you can not select a cluster, consider the namespace of it, then your key dispersed into multiple instances. About how to allocate data, there is this wonderful comment on redis.io website.
9, the kernel it better? !
Of course, it is wrong. Redis is a single-threaded process, enabled even if persistent will only consume a maximum of two cores. Unless you plan to run multiple instances on a single host - only hope is in the development and testing environment! - If not for a Redis instance does not require two or more cores.
10, high availability
so far Redis Sentinel has passed very thorough testing, many users have to apply it to a production environment (including ObjectRocket). If your application is heavily dependent on Redis, it would need to come up with a scheme to ensure its availability will not be dropped.
