点一下关注吧!!!非常感谢!!持续更新!!!
目前已经更新到了:
- 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 持久化适用于以下场景:
高数据安全性要求:
- 场景:需要最大限度地保证数据持久性,尽量避免数据丢失。
- 例子:金融系统、电子商务平台等数据极其重要的应用。
高实时性要求:
- 场景:数据变更频繁,需要实时记录每一次操作。
- 例子:实时日志记录、消息队列等需要保证每条记录都持久化的应用。
增量备份:
- 场景:希望通过增量方式备份数据,而不是定期全量快照。
- 例子:交易系统、用户行为记录等。
易于故障恢复:
- 场景:需要逐条重放命令来恢复数据,确保数据完整性。
- 例子:数据分析系统、数据同步等需要逐条命令执行恢复的场景。
版权归原作者 武子康 所有, 如有侵权,请联系我们删除。