Redis is an advanced key-value database. It's similar to memcached, but the data can be persisted and the data types are rich. There are strings, linked lists, sets, and ordered collections. It supports calculating the summing, intersecting, and complementing (difference) of collections on the server side, and also supports a variety of sorting functions. So Redis can also be seen as a data structure server.
All Redis data is stored in memory and then stored to disk asynchronously from time to time (this is called "semi-persistent mode"); You can also write every data change into an Append Only File (AOF) (this is called "full persistence mode").
The first method is filesnapshotting: The default redis will persist data to the disk in the form of a snapshot (a binary file, dump.rdb, this file name can be specified), and the format in the configuration file is: save N M means that within N seconds, redis will take a snapshot to disk if at least M modifications occur in redis. Of course, we can also manually perform save or bgsave (asynchronous) to take snapshots.
Here's a brief introduction to how it works: When Redis needs to persist, Redis will fork a child process; The child process writes the data to a temporary RDB file on disk; When the subprocess finishes writing the temporary file, it replaces the original RDB, which has the advantage of copy-on-write
There is also a persistence method Append-only:filesnapshotting method When redis is abnormally dead, the recent data will be lost (the amount of lost data depends on the configuration of your save policy), so this is its biggest drawback, when the business volume is large, the lost data is a lot. The append-only method can achieve all data loss, but the performance of redis is worse. AOF can be persisted throughout the process, only need to be turned on in the configuration file (default is no), appendonly yes After AOF is enabled, every time redis executes a command to modify data, it will be added to the aof file, and when redis is restarted, the AOF file will be read for "replay" to restore to the last moment before redis is closed.
LOG Rewriting As the AOF file becomes larger and larger as the data is modified, many of which record changes in a key. Therefore, redis has an interesting feature: reconstruct the AOF file in the background without affecting the client-side operation. Executing the BGREWRITEAOF command at any time will write the shortest sequence of commands in the current memory to disk, and these commands can fully construct the current data situation without unnecessary changes (such as state changes, counter changes, etc.), reducing the size of the AOF file. So when using OF, redis recommends using BGREWRITEAOF as well.
There are three ways to refresh the AOF file, refer to the configuration parameter appendfsync: appendfsync always calls fsync to flush to the AOF file every time a modification command is submitted, which is very, very slow, but also very safe; appendfsync everysec calls fsync every second to flush to the AOF file, quickly, but may lose data within a second; appendfsync no relies on the OS to refresh, redis does not actively refresh the OV, which is the fastest, but the security is poor. Refresh per second is recommended by default, so that both speed and security are taken into account.
It may be due to system reasons that the AOF is corrupted, redis can no longer load this OF the OV, you can follow the steps below to fix it: First, make a backup of the AOF file and copy it to another place; Fix the original OF file, execute: $redis-check-aof –fix; You can use the diff –u command to see where the files are inconsistent before and after the repair. Restart the Redis service.
How LOG Rewrite works: The same uses copy-on-write: first redis will fork a child process; The child process writes the latest AOF to a temporary file; The parent process incrementally writes the latest executed changes in memory (at this time, the old AOF is still written, and it is safe to rewrite if it fails); When the child process finishes rewriting the temporary file, the parent process receives a signal and writes the previous incremental changes in memory to the end of the temporary file. Redis renames the old OF file, renames the temporary file, and starts writing to the new OF.
Finally, just in case (machine crashes or disk crashes), remember to regularly back up the *rdb *.aof file generated using filesnapshotting or Append-only to the remote machine. I use a crontab to SCP every half hour. I didn't use redis' master-slave function, because a half-hour backup should be fine, and I feel like it's a bit of a waste of the machine if you have a master-slave. This ultimately depends on the application.
|
Posted on 8/24/2017 4:37:45 PM
|
|
|
