There are two persistence methods for Redis, AOF and RDB.

Third, persistence There are two persistence methods for Redis, AOF and RDB. AOF persistence refers to the method of appending write commands to an aof file, and RDB refers to the manner in which a snapshot of a memory is periodically saved to an rdb file. Although the RDB can save the snapshot in the background through the bgsave command, the fork () subprocess has overhead and takes a long time in the case of a large memory dataset. Although a shareable data content Need to copy, but will copy the memory page table of the previous process space, if the memory space has 40G (consider each page table entry consumes 8 bytes), then the page table size is 80M, this copy takes time, The server node on the test, 35G data bgsave moment will block more than 200ms, the general recommendation Redis use memory does not exceed 20g. I / O consumption, we are online in the Slave node to open rdb persistence, disk performance in general, 1.2g rdb file persistence once a minute, a time-consuming about 30s, so rdb frequency can not be too frequent, according to The situation is well configured. AOF is an additional write command to the aof file, the advantage is that you can basically do the data lossless, the disadvantage is that the file grows faster, requiring intermittent bgrewrite, bgrewrite is also a consumption of both CPU and disk IO operations, the highest single cpu utilization Up to 100%. bgrewrite period can be set to temporarily write a new write request buffer, bgrewrite synchronous write disk after completion, synchronization will temporarily stop processing client requests, if bgrewrite longer, the buffer backlog data more core blocking time will be very long, so if Must be open aof, it is generally recommended to find several free time to set the script to do bgrewrite. AOF there is a pit more brush set fsync strategy, this setting generally have three ways: always, everysec, no, if set to no, the time to write the disk to the operating system, which is very large To the extent sacrificed aof data lossless advantage, if set to always means that each command will be synchronous brush, will cause frequent I / O, so the general advice is to set everysec, Redis will default once every second fsync call , The data in the buffer to disk. But when this time fsync call longer than 1 second. Redis will take a delay fsync strategy, wait a second. That is fsync after two seconds, this time fsync no matter how long will be carried out. At this time due to the fsync file descriptors will be blocked, so the current write operation will be blocked, because it is synchronized so the core processing block, open aof and require Redis lossless performance on the disk have very high requirements.  Persistence provides a mechanism for restoring data to and from Redis, but turning persistence on comes at a cost, and persistence can cause CPU stalls, affecting the processing of client requests. Do not open the persistence there is a risk, if you restart the master node by mistake, or imagine such a scenario, the master-slave switch fails, it is likely to restart the master because of carelessness, then do not open the persistent master will all slave data clear 0. So whether to turn on persistence, how to open persistence is a problem. And operation and maintenance colleagues discussed some of the options here for your reference: 1, in extreme cases can tolerate the full amount of data loss, it is recommended that the master turn off persistence, slave off persistence; 2, in extreme cases can not tolerate the full amount of data loss, but can tolerate some of the data loss, if the memory data set smaller and does not increase the proposed master open rdb, slave open rdb; if the data set is large, or not sure the data set growth trend , It is recommended master turn off persistence, slave open rdb

Open rdb need cpu and disk performance protection. If master turn off persistence, slave to open rdb need to ensure that slave rdb will not be covered by the master error restart, here are several options:  Restart the script package layer network load command to load the rdb file backup directory backup and then start, to prevent accidental restart, but the preparation for the deployment may need to adjust the script, the host also needs to adjust the script to open the persistence  Regular rdb file through the network io passed to the master node (file is more time-consuming, file growth need to consider the timing of the script execution interval, otherwise it will cause persistent network io), but also a certain loss of data  Regular backup of the rdb to the backup directory Slave, do not do any other operation, error restart manually copy rdb to the master node (there will be some data loss) 3, the maximum data lossless, it is recommended master open aof, slave open aof Open aof need cpu and disk performance protection. Open aof fsync sync brush disk use everysec, custom scripts do bgrewrite regularly in idle time, bgrewrite incremental data buffer. At present, most of the business allows part of the data loss, in order to maximize the Redis performance, turn off the Master persistence, slave open rdb, to prevent a false restart rdb made a 5-minute backup, keep the last 1 hour backup file, if necessary Artificial copy to the master data directory recovery data. Follow-up hardware performance improvements, see the situation and then adjust the persistence mechanism.