点一下关注吧！！！非常感谢！！持续更新！！！
目前已经更新到了：
Hadoop（已更完）
HDFS（已更完）
MapReduce（已更完）
Hive（已更完）
Flume（已更完）
Sqoop（已更完）
Zookeeper（已更完）
HBase（已更完）
Redis （正在更新…）
章节内容
上节完成了的内容如下：
Redis慢查询日志
Redis监视器
Redis慢查询定位和处理
持久化原因
- Redis 是内存数据库，宕机后数据消失
- Redis 重启后快速恢复数据 需要提供持久化机制
- Redis 持久化是为了快速恢复
持久化方式
Redis 的持久化不保证数据的完整性！
- RDB
- AOF
我们可以通过 INFO 指令查看Redis当前持久化的信息：
./redis-cli info
RDB（Redis Database）
RDB 持久化是通过生成内存快照的方式，将 Redis 数据写入到磁盘上的二进制文件中。
RDB 文件可以在指定的时间间隔内进行创建（快照方式），例如每隔一段时间或者每达到一定数量的写操作时。
具体特性如下：
自动备份：RDB 文件可以设置在特定时间间隔自动生成，用于数据备份和恢复。
高效恢复：由于 RDB 文件是紧凑的二进制格式，恢复数据时速度非常快。
性能开销低：在持久化的过程中，Redis 仍然可以处理客户端请求，只是在生成 RDB 文件时会稍微影响性能。
数据丢失风险：如果 Redis 意外崩溃，最后一次 RDB 快照之后的数据会丢失，因为快照是周期性的而不是实时的。
AOF（Append Only File）
AOF 持久化是将每一个写操作记录到日志文件中。
AOF 文件以文本形式记录了每一条修改命令，通过不断追加的方式来保证数据持久化。
具体特性如下：
实时性更高：AOF 可以设置为每次写操作都进行持久化（always），或者每秒持久化一次（every second），因此数据丢失的可能性较低。
可重写：随着时间推移，AOF 文件会越来越大，但可以通过 AOF 重写机制将文件压缩，保持较小的文件大小。
日志冗长：由于每个写操作都被记录，AOF 文件比 RDB 文件要大，而且恢复速度相对较慢，因为需要逐条执行日志命令。
安全性高：AOF 更适合需要最大化数据持久性的场景，例如金融数据处理。
如何选择 RDB 和 AOF
选择 RDB 还是 AOF 取决于你的具体需求：
如果需要快速恢复数据，并且对少量数据丢失不敏感，可以选择 RDB。
如果需要更高的持久化保证，并且能够接受较大的磁盘和恢复开销，可以选择 AOF。
许多场景下，可以结合两者使用，即开启 RDB 作为定期备份，开启 AOF 作为实时持久化，以获得更好的数据安全性和恢复性能。
模式对比
RDB存在某个时刻的快照，采用二进制的方式压缩存储，AOF存操作命令，采用文本存储
RDB性能高，AOF性能低
RDB在配置触发状态会丢失最后一次快照以后更改的所有数据，AOF每1秒都保存一次，最多丢2秒。
Redis以主服务模式运行，RDB不会保存过期键值数据
Redis以从服务模式运行，RDB会保存过期数据，但是同步时会清空
应用场景
RDB（Redis Database）
RDB 持久化适用于以下场景：
快速恢复数据：
场景：需要在服务器重启或故障后快速恢复数据。
例子：游戏状态数据、会话管理等需要在短时间内恢复大量数据的应用。
较少的数据变更：
场景：数据变更不频繁，允许在一段时间内进行定期快照。
例子：只读数据集或数据变更较少的应用，如配置管理、静态内容缓存等。
定期备份：
场景：需要定期对数据进行备份以防止数据丢失。
例子：日终备份、每小时备份等场景，适用于数据分析和报表生成。
较低的持久化需求：
场景：可以容忍一定的数据丢失，追求更高的性能。
例子：缓存应用、临时数据存储等。
AOF（Append Only File）
AOF 持久化适用于以下场景：
高数据安全性要求：
场景：需要最大限度地保证数据持久性，尽量避免数据丢失。
例子：金融系统、电子商务平台等数据极其重要的应用。
高实时性要求：
场景：数据变更频繁，需要实时记录每一次操作。
例子：实时日志记录、消息队列等需要保证每条记录都持久化的应用。
增量备份：
场景：希望通过增量方式备份数据，而不是定期全量快照。
例子：交易系统、用户行为记录等。
易于故障恢复：
场景：需要逐条重放命令来恢复数据，确保数据完整性。
例子：数据分析系统、数据同步等需要逐条命令执行恢复的场景。
