Redis server optimization practices: configuration optimization, master-slave switch, persistence

 First, the Server configuration llkeys-lru or noeviction Redis server has such a configuration parameter maxmemory-policy allkeys-lru, Redis said the use of memory allocated to the upper limit of the default use lru key elimination strategy (there are other optional strategies). We have encountered such a problem, the application side due to an improper hgetall operation, resulting in Redis memory expansion exceeds the limit, trigger key out, the results of the important data is emptied (Fortunately, most businesses have done disaster recovery mechanism) After this accident we changed the strategy of elimination to noeviction-forbidden key to be eliminated. So, in the end to adjust the elimination strategy? In fact, the main business scenarios, Redis is considered as a data cache to be eliminated or the core data storage memory database. One of the core advantages of using Redis is that Redis has a rich data structure. Most current businesses choose Redis for this purpose. Once the data set of some complex structures is emptied, it is impossible to implement a service-free recovery mechanism Automatically rebuilt. If your Redis is not a simple string cache, then you need to carefully consider whether to disable the key out. client-output-buffer-limit normal 0 0 0? The example of hgetall is exactly the same as the reason that an accident was caused by a memory spike caused by the engineer turning on the monitor command.  By default, this buffer is allocated unlimited, and also occupy Redis memory space, which means that a large query memory may double exponentially, check the memory burst on several occasions, if unfortunately not set to prohibit the key to eliminate , Then the data is likely to be cleared 0. Redis APIs provide many levels of O (N) instructions like hgetall, smembers, keys, etc. O (N) level instructions should be used with caution if your application has high QPS or is intended for end-user requests. If the target of the instruction Large data set, then it means that either the request is time-consuming long-term consumption of cpu, or a large amount of data inquiries led to soaring Redis memory. Redis single-threaded design is not intended for high-frequency large data set queries. We set the client-output-buffer-limit normal 10MB 5MB 10 limit for this parameter. The allocation of 10MB buffers for a single request is high enough, and can be lower depending on the application, but it is by no means unlimited. lua-time-limit One of the advantages of Redis' support for custom commands is that they support Lua scripts. Some of our services use Lua scripts. The run time of these custom instructions needs to be tested and evaluated. In applications requiring high QPS, there must be no Lua scripts. Long-term Take
 up CPU resources. Although lua-time-limit will not terminate the Lua script, it will cause Redis to respond to client requests returning Busy errors after the time limit has expired, thus avoiding knowing when a large number of connections have been suspended and timed out. Lua need to set the time limit, but still suggest testing lua script performance. rename-command Redis provides rename-command can rewrite some of the dangerous command, so that it can not be successful, it is proposed to ban the following commands:  rename-command FLUSHALL "" / * Delete all existing databases * /  rename-command FLUSHDB "" / * clear all the current database key * /  rename-command SHUTDOWN "" / * Close redis server (server) * /  rename-command KEYS "" / * Complexity O (N), traversing all key * /  rename-command MONITOR "" / * debug command to see the command Redis is executing * / The company had engineers mistakenly executed flushall lead to the data empty, the United States regiment dropped monitor pit, we also appeared to use the keys caused by CPU Caton. In fact, these commands do not need and should not appear in the application API calls. Hope not to accidentally call engineers, it is better to ban directly on the server side. slaveof This directive is very special, it specifies that the current Redis instance is a slave of a Master instance. If this command is written dead in the configuration file, then the instance can only be a slave after it starts, unless there is a Sentinel to promote it to master, or manually execute slaveof no one. This instruction is an instruction that will be dynamically removed or added by the Sentinel from the configuration file. It is best if the Sentinel decides the existence of the Sentinel. Our previous configuration file was introduced via a subfile, so there was a problem. If a slave was elected as the master by the Sentinel, its slaveof instruction would be removed, but the subroutine could not write the command Removed, once restarted this master instance, it has become a slave. If you do not pay attention to the existence of this sub-file, the problem is still not good investigation, do not know what happened. No problem encountered online, the test environment did a master-slave switch, the operation process, restart the next master, the result of a pit. The test example will be covered later, as it also deals with sentry and master-slave switching.