Design and implementation of Redis-persistence chapter

Redis Database

2. The default 16 databases, each database is represented by a REDIS.H/REDISDB structure, the structure of the dict dictionary and Expires dictionary, where dict saved all key value pairs of the library, this dictionary is the key space; The Expires dictionary holds the expiration time for all keys in the database, which is a key object in the key space, and the value is an integer of type long Long that represents the expired Unix timestamp.
4. There are additional actions to take when working with the key space:
• Update hit or miss Count;
• Updated LRU (last use) time;
• Determine whether the key is out of date, if it expires, delete the key and then perform other operations;
• If a watch command monitors this key, the key is identified as dirty for the application to notice;
• Modify key pair Dirty counter +1 to trigger persistence and copy operation;
• Send a possible database notification
6. Redis uses lazy delete with periodic delete mate policy
• Lazy Delete: Only in the key is to determine whether to delete, CPU-friendly to memory unfriendly;
• Periodic deletion: Execute once every time, and limit the length and frequency of execution, traverse each library multiple times, randomly check the expiration time and delete
8. RDB persistence mode for expired key processing:
• Keys that have expired when an RDB file is generated are not saved to the file;
• On load if the current server is running in master server mode, the expiration key is ignored if the slave mode is loaded and then waits for synchronization with the primary server to the expired key, regardless of expiration.
10. AOF persistence mode processing of expired keys:
• A del record is appended to the AoF file only after the expiration key has been lazily deleted or deleted periodically.
• AoF overrides and generates an RDB file type, the expiration key does not error to the rewritten aof file
12. The primary server in replication mode controls the deletion of expired keys from the server by sending the DEL command, from which the service does not determine whether it expires or should be deleted.
14. The redis2.8 version supports two types of database notifications:
• Key Space notification: the notification that a key has executed which commands;
• Key TIME notification: Notifies a command of which keys have been executed.

Above text from Dimmacro, reprint please explain source:http://www.cnblogs.com/dimmacro/

RDB Persistence: Saving key-value pairs at a point in the database

1. Both the save and Bgsave commands can generate a binary RDB file to disk, except that the save command blocks during the creation of the file and cannot process any client's command requests while Bgsave fork a child process without affecting the main process receiving and executing the command;
2. The Redis server will start by looking at whether AoF is turned on, prioritizing the use of aof files to restore the state of the database, using only aof shutdown to load the Rdb file, and the server will be in a blocking state until it is loaded into the Rdb file;
3. SAVE, BGSAVE, bgwriteof Three commands will not be executed at the same time;
4. For Bgsave, because the server records the number of times the database state has been modified since the last successful save or Bgsave, and the last point in time, the user can set the auto-trigger Bgsave via the command form of save time period modification, such as save 60 1000 Indicates that a change of more than 1000 times in 60 seconds is required to trigger a bgsave.
5. Internal content structure diagram for the Rdb file:

aof Persistence: Save Write commands executed by the server

2. AOF Open after the server executes a write command, the Write command is written to the end of the AOF_BUF buffer in protocol format, and after each event is processed, the AoF file is written and synchronized according to different Appendfsync policies:
• always: Write and synchronize all contents of Aof_buf to aof file;
• everysec: writes all content inside the aof_buf to aof file, and by a specialized thread checks the distance last synchronization aof whether exceeds 1 seconds, exceeds then synchronizes this content to the AoF file, the default way;
• no: Writes all content within AOF_BUF to the AoF file, but is determined by the operating system when to synchronize
4. AoF rewrite to regenerate the aof file by reading the current key-value pairs in the database, achieving the purpose of merging multiple write commands to reduce the volume of the AoF file, and not doing any reading, parsing, or writing of the existing AoF file.
6. The process of aof rewriting is as follows:
• The main process fork out a child process to be rewritten, overwriting the new write command of the main process during the write to the aof rewrite buffer;
• When the child process finishes rewriting, it sends a signal to the master process to notify the rewrite to complete;
• The main process will aof the new write command in the rewrite buffer to continue writing to the new aof file and rename the new AoF file, the atom overwrites the existing AoF file, and implements the replacement of the old and new AoF file;

Above text from Dimmacro, reprint please explain source:http://www.cnblogs.com/dimmacro/

Design and implementation of Redis-persistence chapter