A, Redis two kinds of persistent manner (RDB & AOF)
Redis persistence of the process does not require too much of our developers to participate, what we have to do is it? In addition to in-depth understanding of the principles of the role of RDB and the AOF, the rest is to develop appropriate strategies based on the actual situation, and then more complex, which is a customized high-availability, data security strategy.
Two, RDB persistent way:
In RDB way, you have two options:
- One is to manually perform persistent data commands to make redis conduct a snapshot of the data; and manually execute the persistent command, you still have two choices, that is, save command and bgsave command.
(1) the Save operation Redis work in the main thread, so the operation will block other requests should be avoided.
(By default, the persistence to dump.rdb file, and after the restart redis, which automatically read the file, it is learned, usually the next ten million key string type, 1GB snapshot files, the time synchronization memory 20-30 seconds)
(2) bgsave is calling Fork, produce the child, the parent process continues to process the request. The child process to write data to a temporary file, and after writing, .rdb replace the original file. Fork occurs when the father and son shared memory process, so as not to affect the child process for data snapshots, during which the modified data will be a copy, but not into the shared memory. So, RDB the persistent data is data of Fork occur. Persistent data under such conditions, if for some cases of downtime, data will be lost for some time. If your situation is not so sensitive to loss of data, loss can also be obtained from traditional databases or missing part does not matter, then you can choose RDB persistent way.
- The other is based on policy configuration files you configured to automatically persist data when certain conditions are met strategy. In fact, it bgsave command and persistence principle is the same.
This is the default policy configuration file, or the relationship between them is, every 900 seconds, during which at least one key change, do snapshots. Or every three hundred seconds, ten key changes do snapshots. Or every sixty seconds, the change of at least ten thousand keys, do snapshots.
3.AOF snapshots:
AOF, append only file. 
Appendonly modify the configuration file to yes. After opening AOF persistence, each instruction executed by you, will be recorded in the appendonly.aof file. But in fact, does not immediately command is written to the hard disk file, but is written to the hard disk cache, the next strategy, configure how long to write the file to your hard disk from the hard disk cache. So under certain conditions to some extent, there will still be data loss, but you can greatly reduce data loss.
Here is the AOF persistent policy configuration. redis use everysec default, every second that is persistent, and always will be written for each operation is immediately aof file. And no it is not actively synchronize, default 30s once. Of course, always must be the least efficient, think everysec enough to use, data security and high performance.
Redis also allows us to use both ways, and then after the restart redis will recover data from aof because small thing aof than rdb data loss.
And in-depth understanding of the difference between:
RDB every time snapshots will re-record all the information for the entire data set. RDB when restoring data faster, maximize performance redis, the child process without any performance impact on the parent.
AOF orderly records redis command operations. Little unexpected situations of data loss. He constantly adding operation log record aof file, you might say, how large it was such a file. Yes, it will certainly become huge, but there will be redis optimization strategies, such as your operations on a key1 key, set key1 001, set key1 002 , set key1 003. That is to optimize the results of the first two slightly removed, and that specific optimized configuration corresponding to the configuration file is
former refers to more than the last time aof aof rewrite what percentage of file size, optimization will be again, if not rewritten too, places the main startup. The latter is allowed to rewrite the minimum limit aof file size. bgrewriteaof command is manually override command, fork child process, in a temporary file to rebuild the database state, without any impact on the original aof, when the reconstruction of the old state, will put the data over a period of time after the occurrence of the fork together with additional to a temporary file, and finally replace the original aof file, the new command continues to append to a new aof file.
