在Redis数据永久化方面，以及在服务运行时切换的注意事项有以下几种类型和方式
条件
前提是 Redis 2.8 或更高版本。
Redis数据持久化的类型
在Redis中，有三种数据管理方法。
– 使用内存来管理数据的方式（易失性基础）
– 在特定时机将数据保存到磁盘上的方式（RDB基础）
– 随时将数据保存到磁盘上的方式（AOF基础）
通过将Redis配置为’RDB’或’AOF’，即使重新启动Redis，也可以从文件中重新加载数据到内存中，实现数据的持久化。
由于存在诸如性能下降等不利因素，您需要根据所提供服务的内容和优缺点进行选择。
蒸发性基底
将数据全部保存在内存中进行处理。
由于在Redis重新启动时会导致数据全部丢失，因此只在可以容忍此情况下使用。
设定示例：
save ""
RDB基础
在指定的时间将数据保存到文件中（异步快照）。
由于Redis重新启动时可能发生轻微的数据丢失，因此只有在可以接受这种情况的情况下才使用。
可以使用Redis的“save”指令来设置保存的时间。
设定示例：保存[在□□秒内] [〇〇次更新后]。
dir /var/run/redis # RDB/AOFの格納ディレクトリを指定する
dbfilename 6379.rdb # RDBのファイル名を指定する
rdbcompression yes # RDBの圧縮要否を指定する
save 900 1 # 1回の更新後 900 秒以内に同期する
save 300 10 # 10回の更新後 300 秒以内に同期する
save 60 10000 # 10,000回の更新後 60 秒以内に同期する
AOF 基础
一直保存数据到文件中。（默认是以秒为单位保存的，所以几乎是同步保存的）
适用于不可容忍数据丢失的情况。
虽然可以与RDB并行运行，但是没有感受到明显的优势。
・リソース大量消費（データ保存時に格納サイズの倍以上のメモリが必要）
假設例子：
dir /var/run/redis # RDB/AOFの格納ディレクトリを指定する
appendonly yes # AOFの利用要否を指定する
appendfilename 6379.aof # デフォルトは appendonly.aof となる
appendfsync everysec # デフォルトで秒単位に同期する（中速で動作する）
# appendfsync always # 常に同期する（低速だが安全に動作する
# appendfsync no # OSに任せる（高速に動作する）
auto-aof-rewrite-min-size 32mb # AOFのファイルサイズが32MByte以下はリビルド（最適化）の対象外とする
auto-aof-rewrite-percentage 100 # AOFのファイルサイズが倍増(100%)した場合にリビルド（最適化）する
永久化方式的变更需注意正在运行的服务。
在运行中进行模式更改时，如果不同时进行基于’CONFIG’命令的服务模式更改和redis.conf配置文件的更改，可能会由于运行时数据的持久化模式差异导致在运行和重新启动时丢失操作数据。
数据丢失案例
（１）从AOF切换到RDB的情况
为了提高正在运行的Redis的性能，使用’CONFIG SET’命令将其切换到’RDB’模式。原计划还打算将配置文件也改为’RDB’，但却忘记了。几天后重新启动服务器时，配置文件仍然是’AOF’，导致使用旧的’AOF’文件启动，从而丢失了使用’RDB’模式运营期间的数据。
（２）从关系型数据库（RDB）切换至追加写日志（AOF）的情况。
为了增加可用性，我将正在运行的Redis切换到使用AOF作为配置文件。
我原本计划使用”CONFIG SET”命令来切换到AOF，但是我忘记了。
几天后的服务器重新启动，AOF按预期启动了，但是AOF文件不存在，导致启动时没有数据，之前使用RDB进行操作的数据全部丢失。
※ 在Redis并行运行RDB和AOF时，会按照AOF优先于RDB的顺序重新加载数据。
（３）从关系数据库（RDB）切换到追加写入日志（AOF）的情况下。
为了增加正在运行的Redis的可用性，我通过’CONFIG SET’命令将其切换到了’AOF’。我本打算同时将配置文件更新为’AOF’，但是却忘记了。（也就是说，继续使用’AOF’运作）几天后重新启动服务器（Redis）时，我错误地使用了错误的’RDB’配置启动，导致使用旧的’RDB’文件启动。（因为切换到’AOF’后的数据全部丢失了）
最后
由于Redis的特性，它是一个不断更新信息的功能，所以在考虑重新启动服务后的回退时，应该考虑到这一点（几乎不可能实现！）。因此，在更高级别的过程中，应该提前确定持久化方式。如果不得不在中途进行更改，应该注意不至于出现错误的步骤。
