Redis series:
A, Redis of high performance single and
Redis single-threaded why can so quickly?
Because it all data in memory, all operations are memory-level operations, to avoid the multi-threaded and single-threaded performance switching loss problem. Because Redis is single-threaded, so be careful to use Redis commands, those commands (such as keys) time-consuming, must be used with caution, we believe it could lead to Redis Caton.
Redis how to deal with so many single-threaded concurrent client connections?
Redis of IO multiplexing : redis epoll implemented using multiplexing IO, and the connection information into the event queue, event dispatcher successively into the file, event dispatcher will distribute events to the event processor.
Nginx also use IO multiplexing principles to solve problems C10K
Second, endurance of
RDB snapshot (snapshot)
By default, Redis database snapshots stored in the memory as a binary file name in dump.rdb. You can set the Redis, when it "N seconds dataset has at least M changes" this condition is satisfied, automatically save a data set. For example, the following is provided Redis will meet "at least 60 seconds have been changed key 1000" when the condition, automatically save a data set (provided in redis.conf):
# save 60 1000
AOF（append-only file）
The snapshot feature is not very durable (durable): If for some reason Redis caused downtime, the server will lose the most recently written, and those data are not yet saved to the snapshot. From version 1.1, Redis adds a completely durable persistent way: AOF persistence, the modified record every instruction into the file.
You can open AOF function (set in redis.conf in) by modifying the configuration file:
# appendonly yes
From now on, whenever a change Redis execute command data sets (such as set), this command will be appended to the end AOF file (appendonly.aof) of. In this case, when Redis restarted, the program can achieve the purpose of reconstruction data sets by re-executing commands in the file AOF.
How long before you can configure Redis will fsync data to disk first.
There are three options:
Each time a new command is added to the AOF document on the implementation of a fsync: very slow, very safe.
fsync once per second: fast enough (and almost persistent use RDB), and only one second of data loss in case of failure.
Never fsync: the data to the operating system to handle. Faster and less safe choice.
Recommended (and also the default) measures to fsync once per second, this strategy can take into account the fsync speed and security.
AOF should a RDB and with what?
If you are very concerned about your data, but you can still withstand the loss of data within a few minutes, then you can just use RDB persistence.
AOF many users use only persistent, but does not recommend this approach: since the timing generating RDB Snapshot (Snapshot) is very easy database backup and recovery speed RDB data set than AOF is also faster recovery.
Mixing persistence Redis 4.0
Restart Redis, we rarely use RDB to recover memory state, as it will lose large amounts of data. We usually use the AOF log replay, but replay log AOF performance RDB is relatively much slower, so that in a lot of cases Redis instance, start it takes a long time. Redis 4.0 To solve this problem, has brought a new persistence options - mixed persistence . AOF when rewriting (aof file may be too many useless instruction, aof aof file periodically generated according to the latest data memory) will rewrite the contents of memory RDB and incremental snapshot file before this moment AOF modify memory command log file data exist together, have written a new aof file, start a new file is not called appendonly.aof, until re-finished new AOF file will be renamed atoms overwrite the original file AOF, complete replace old and new AOF documents;
AOF automatically rewritten in accordance with configuration rules in the background, you may be artificially Run bgrewriteaof rewriting AOF. So when Redis reboot, you can load content rdb, and then replay log replay on incremental AOF AOF full amount before the file can be completely replaced, restart efficiency and therefore significantly be improved.
Open mixed persistence:
# aof-use-rdb-preamble yes
Mixed persistent aof file structure:
Cache elimination strategy
When Redis memory beyond the limits of physical memory, the data memory and the disk will begin to produce frequent exchange (swap). Redis exchange performance will drop dramatically, for more frequent visits Redis, the access efficiency is substantially equal to the speed of the turtle is not available. In a production environment, we are not allowed to appear Redis exchange behavior, in order to limit the maximum use of memory, Redis provides configuration parameters maxmemory to limit the size of memory beyond expectations. When the actual memory beyond maxmemory, Redis offers several optional policies ( maxmemory-Policy ) to allow users to decide how to make the new space to continue to provide literacy services:
noeviction not continue to service the write request (DEL request can continue to serve), the read request can proceed. This ensures that no data is lost, but the online business will not continue. This is the default elimination strategy.
volatile-lru attempt to eliminate a key set expiration time, the least used of the key priorities to be eliminated. The key is not set an expiration time will not be eliminated, thus the need to ensure data persistence will not suddenly be lost.
volatile-ttl Like the above, in addition to the LRU policy is not eliminated, but the key value of the remaining lifetime of ttl, ttl smaller the priority is eliminated.
volatile-random , like the above, but the key is out of date key set of random key.
allkeys-lru different from the volatile-lru, this strategy to phase out the key target is the key to all collections, not just expired key collection. This means that there is no set expiration time of the key will be eliminated.
allkeys-random with the same as above, but out of the strategy is random key.
volatile-xxx strategy only be eliminated with an expiration time for the key, allkeys-xxx strategy will all be out of key. If you just take Redis as cache, it should be used allkeys-xxx, clients do not have to carry expiration time write cache. If you want to use Redis persistence function, and then use volatile-xxx strategy so that you retain no set expiration time key, they will not be permanent key LRU algorithm eliminated.