Comparison and analysis of Redis persistence methods

1. Preface

Redis has recently been used in projects to cache, allowing data to be shared between multiple business processes. Since Redis data is stored in memory, if no persistence is configured, the data is lost after the Redis reboot, so you need to turn on Redis persistence, save the data to disk, and restore the data from disk when Redis restarts. Redis provides two ways to persist, one is the RDB persistence (the principle is to dump the Reids in-memory database records to the RDB persistence on the disk), and the other is aof persistence (the principle is to write the Reids operation log to the file in an append way). So what is the difference between the two ways of persistence, and how do you choose? Most of the online is to introduce the two ways of how to configure, how to use, is not to introduce the difference between them, in what application scenarios to use. 2, the difference between the two

An RDB persistence is a snapshot of an in-memory dataset written to disk within a specified time interval, in which the actual operation is to fork a child process, write the dataset to a temporary file, write it successfully, replace the previous file, and store it in binary compression.

AOF persistence logs every write, delete operation that the server handles, the query operation is not recorded, the text is logged, the file can be opened to see the detailed operation record.

3. Advantages and Disadvantages What are the advantages of an RDB?

1). Once this is used, your entire Redis database will contain only one file, which is perfect for file backups. For example, you might want to archive the last 24 hours of data every hour and archive the last 30 days of data every day. With such a backup strategy, we can recover very easily once the system has a catastrophic failure.

2). The RDB is a great choice for disaster recovery. Because we can easily compress a single file and then transfer it to other storage media.

3). Maximum performance. For a Redis service process, the only thing it needs to do when it starts to persist is to fork out the child process and then complete the persistence work by sub-processes, which can greatly prevent the service process from performing IO operations.

4). If the data set is large, the RDB will be more efficient to start than the AOF mechanism.

What are the disadvantages of an RDB?

1). An RDB is not a good choice if you want to ensure high availability of data, which minimizes data loss. Since the system is down before the scheduled persistence, the data that has not been written to the disk before is lost.

2). Since the RDB assists with data persistence through the fork process, it can cause the entire server to stop serving hundreds of milliseconds, or even 1 seconds, if the data set is large. What are the advantages of aof?

1). This mechanism can result in higher data security, i.e. data persistence. There are 3 synchronization policies available in Redis, that is, synchronization per second, synchronization per modification, and unsynchronized. In fact, synchronization per second is also done asynchronously, and its efficiency is very high, the difference is that once the system is down, then the data will be lost in a second. Each time we modify the synchronization, we can treat it as a synchronous persistence, that is, each occurrence of the data changes will be immediately logged to disk. It can be predicted that this is the least efficient way. As for the no-sync, needless to say, I think we can understand it correctly.

2). Because this mechanism writes to log files in append mode, it does not break the content that already exists in the log file even if there is an outage during the write process. However, if we only write half of the data this time there is a system crash problem, do not worry, before the next boot of Redis, we can use the Redis-check-aof tool to help us solve the problem of data consistency.

3). If the log is too large, Redis can automatically enable the rewrite mechanism. That is, Redis continuously writes the modified data to the old disk file in Append mode, and Redis also creates a new file to record which modification commands are executed during this period. Therefore, the data security can be better ensured when the rewrite is switched.

4). AOF contains a well-formed, easy-to-understand log file for recording all modification operations. In fact, we can also complete the reconstruction of the data through this file.

What are the disadvantages of aof?

1). aof files are typically larger than the Rdb file for the same number of datasets. An RDB recovers a large data set faster than AOF.

2). Depending on the synchronization strategy, the AOF is often slower than the RDB in terms of operational efficiency. In summary, the efficiency of the synchronization policy per second is high, and the efficiency of the synchronization disable policy is as efficient as the RDB.

The choice of the standard is to see the system is willing to sacrifice some performance, in exchange for higher cache consistency (AOF), or willing to write frequently, do not enable backup in exchange for higher performance, when manually run save, then do Backup (RDB). The RDB is a bit more eventually consistent. 4. Common Configuration RDB Persistence Configuration

Redis dumps a snapshot of the dataset to the Dump.rdb file. In addition, we can modify the frequency of the Redis server dump snapshot through the configuration file, after we open the 6379.conf file, we search for save, we can see the following configuration information:

Save 1 #在900秒 (15 minutes), dump memory Snapshot if at least 1 key changes occur.

After save #在300秒 (5 minutes), dump memory Snapshot if at least 10 key changes occur.

After save 10000 #在60秒 (1 minutes), dump memory Snapshot if at least 10,000 key changes occur. aof Persistent Configuration

There are three synchronization modes in the Redis configuration file, namely:

Appendfsync always #每次有数据修改发生时都会写入AOF文件.

Appendfsync everysec #每秒钟同步一次, this policy is the default policy for AOF.

Appendfsync no #从不同步. Efficient but data is not persisted. 5. References

http://blog.csdn.net/jackpk/article/details/30073097

Http://www.jb51.net/article/65264.htm force you to move forward, not the faint light of the dream ahead, but the reality behind the abyss. ---------to yourself