Comparative analysis of redis persistence methods

1 Introduction

Recently, Redis is used in the project as a cache to facilitate data sharing between multiple business processes. Since Redis data is stored in memory, if persistence is not configured, all data will be lost after redis restarts, so it is necessary to enable the persistence function of redis and save the data to disk. Data recovery. Redis provides two ways to persist, one is RDB persistence (the principle is to periodically dump the database records of Reids in memory to the RDB persistence on disk), and the other is AOF persistence (the principle is to store Reids' The operation log is written to the file appendingly). So what is the difference between these two persistence methods, and how to choose? Most of the information on the Internet describes how to configure and use these two methods, but they do not introduce the difference between the two and what application scenarios are used.

2. The difference between the two

RDB persistence refers to writing a snapshot of the data set in memory to disk within a specified time interval. The actual operation process is to fork a sub-process, first write the data set to a temporary file, and then replace the previous file after successful writing. , stored with binary compression.

AOF persistence records every write and delete operation processed by the server in the form of a log. The query operation is not recorded, but is recorded in the form of text. You can open the file to see the detailed operation record.

3. The advantages and disadvantages of the two

What are the advantages of RDB?

1). Once this method is adopted, then your entire Redis database will contain only one file, which is perfect for file backups. For example, you might plan to archive the last 24 hours of data every hour, and also archive the last 30 days of data every day. Through such a backup strategy, once the system fails catastrophically, we can restore it very easily.

2). For disaster recovery, RDB is a very good choice. Because we can very easily compress a single file and then transfer it to other storage media.

3). Maximize performance. For the Redis service process, when starting persistence, the only thing it needs to do is to fork the child process, and then the child process will complete the persistence work, which can greatly avoid the service process from performing IO operations.

4). Compared with the AOF mechanism, if the data set is large, the startup efficiency of RDB will be higher.

What are the disadvantages of RDB?

1). If you want to ensure high availability of data, that is, to avoid data loss to the greatest extent, then RDB will not be a good choice. Because once the system goes down before the scheduled persistence, the data that has not been written to the disk before will be lost.

2). Since RDB assists in completing data persistence by forking child processes, if the data set is large, it may cause the entire server to stop serving for hundreds of milliseconds, or even 1 second.

What are the advantages of AOF?

1). This mechanism can bring higher data security, that is, data persistence. Three synchronization strategies are provided in Redis, namely synchronization per second, synchronization per modification, and non-synchronization. In fact, the synchronization per second is also done asynchronously, and its efficiency is also very high. The difference is that once the system goes down, the data modified within this second will be lost. And every modification synchronization, we can think of it as synchronization persistence, that is, every data change that occurs will be recorded to disk immediately. Predictably, this approach is the least efficient. As for no synchronization, no need to say much, I think everyone can understand it correctly.

2). Since the mechanism uses the append mode for the writing operation of the log file, even if there is a downtime during the writing process, the existing content in the log file will not be destroyed. However, if we only write half of the data in this operation and the system crashes, don't worry, we can use the redis-check-aof tool to help us solve the problem of data consistency before Redis starts next time.

3). If the log is too large, Redis can automatically enable the rewrite mechanism. That is, Redis continuously writes 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, data security can be better ensured when rewrite switching is performed.

4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。

AOF的劣势有哪些呢？

1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。

二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能，待手动运行save的时候，再做备份（rdb）。rdb这个就更有些 eventually consistent的意思了。

4、常用配置

RDB持久化配置

Redis会将数据集的快照dump到dump.rdb文件中。此外，我们也可以通过配置文件来修改Redis服务器dump快照的频率，在打开6379.conf文件之后，我们搜索save，可以看到下面的配置信息：

save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，则dump内存快照。

save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，则dump内存快照。

save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，则dump内存快照。

AOF持久化配置

在Redis的配置文件中存在三种同步方式，它们分别是：

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

appendfsync everysec #每秒钟同步一次，该策略为AOF的缺省策略。

appendfsync no #从不同步。高效但是数据不会被持久化。

5、参考资料

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

http://www.jb51.net/article/65264.htm