Redis实战--Redis的数据持久化与搭建Redis主从复制模式和搭建Redis的哨兵模式

        Redis作为一个高性能的key-value数据库，广泛应用于缓存、消息队列、排行榜等场景。然而，Redis是基于内存的数据库，这意味着一旦服务器宕机，内存中的数据就会丢失。为了解决这个问题，Redis提供了数据持久化的机制，包括RDB和AOF两种方式。此外，为了提高数据的可用性和可扩展性，Redis还支持主从复制和哨兵模式。本文将详细介绍Redis的数据持久化机制、如何搭建Redis主从复制模式以及如何搭建Redis的哨兵模式。

Redis简单介绍与安装应用-优快云博客

Redis实战--Windows上的Redis使用及Java代码操作Redis-优快云博客

一、Redis的数据持久化

1）为什么要持久化？

        Redis是基于内存的数据库，其优点是速度快，但缺点是数据容易丢失。为了解决这个问题，Redis提供了两种持久化机制：RDB和AOF。

2）RDB持久化

        RDB持久化是通过创建数据的快照来实现的。

在redis.conf文件中，默认开启了RDB持久化：

操作越频发，保存的间隔时间越短

目前默认的配置：

save 900 1 代表如果用户在900秒内（15分钟）操作redis一次以上就保存一下。
通过如上的配置，我们得出一个结论，用户只要操作redis越频繁，保存的间隔时间就短。

RDB持久化有两种命令：SAVE和BGSAVE。

SAVE 和 BGSAVE 两个命令都会调用 rdbSave 函数，但它们调用的方式各有不同：
1）SAVE 直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。
2）BGSAVE 则 fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。

bg = backgroud的意思，这两个命令都是手动的保存数据。

RDB方案优点

1、对性能影响最小。如前文所述，Redis在保存RDB快照时会fork出子进程进行，几乎不影响Redis处理客户端请求的效率。

2、每次快照会生成一个完整的数据快照文件，所以可以辅以其他手段保存多个时间点的快照（例如把每天0点的快照备份至其他存储媒介中），作为非常可靠的灾难恢复手段。3、使用RDB文件进行数据恢复比使用AOF要快很多

RDB方案缺点

1、快照是定期生成的，所以在Redis crash时或多或少会丢失一部分数据。

如果数据集非常大且CPU不够强（比如单核CPU），Redis在fork子进程时可能会消耗相对较长的时间，影响Redis对外提供服务的能力

3）AOF持久化

        AOF持久化是通过记录每次执行的命令来实现的。这种方式每操作一次就保存一次，数据安全性更高，但性能会有一定影响。