Spring学习笔记—Spring集成Redis数据缓存技术（1）

RDB：在redis运行时，RDB程序将当前内存中的数据库快照保存在磁盘文件中，在redis重新启动时，RDB程序可通过载入RDB文件来还原Redis中的数据。在指定的时间间隔内，执行指定次数的写操作，将Redis内存中数据写入磁盘，生成一个dump.rdb文件。当redis重新启动时，读取该文件，将磁盘中数据恢复到内存中。打开redis目录下的redis.conf配置文件，SNAPSHOTTING的相关配置项，是配置持久化规则的：

save <指定时间间隔> <指定操作次数>

例如，save 900 1 表示在900s内 1次更改，就保存内存数据到磁盘。

AOF：默认是不开启的。它是以日志的形式记录每个写操作，并追加到文件中。redis重启时，会根据日志文件的内容将保存的写操作执行一次，完成内存数据的恢复。打开redis目录下的redis.conf配置文件，找到APPEND ONLY MODE的相关配置项，修改为开启：

appendonly yes

appendfilename 配置项控制AOF持久化文件的名称。

appendfsync always 每次发生变化会立刻写入磁盘中。

appendfsync everysec 每秒异步记录一次。

appendfsync no 不同步

Redis主从复制模式

主从复制模式的特点：主节点负责接受写入数据的请求，从节点负责接受查询数据的请求，主节点定期把数据同步给从节点，以保证主从节点的数据一致性。

搭建主从复制架构：

1. 创建Redis配置文件进入Redis目录，复制原redis.conf为redis6380.conf文件，操作如下：

2. 修改配置文件在redis6380.conf中修改启动端口和主从关系，代码如下：

3. 启动Redis主从服务分别启动Redis主节点127.0.0.1 6379和从节点127.0.0.1 6380，验证主节点和从节点启动情况，如图所示。

4. 查看主从状态。登录Redis主节点，执行info replication命令，从图中可以看出当前节点是master节点：

登录Redis从节点，执行info replication命令，从图中可以看出当前节点是slave节点。

5. Redis主节点写入操作。登录Redis主节点，执行写入操作。

#写入Hash master_slave中key-value对master ："127.0.0.1 6379"#写入Hash master_slave中key-value对slave ："127.0.0.1 6380"

6. 查询从节点查询同步状态登录从节点客户端，查询从节点同步状态

从以上步骤看出，Redis从节点127.0.0.1 6380虽然没有发生写入操作，但执行查询可以发现，Redis主节点127.0.0.1 6379发生写入的操作已经同步到Redis从节点127.0.0.1 6380。Redis主从架构有多种不同的拓补结构，以下是一些常见的主从拓扑结构。

Redis主从复制模式的拓扑结构:

1、一主一从拓扑结构：

Redis一主一从拓扑结构主要用于主节点故障转移到从节点。当主节点的写入操作并发高且需要持久化时，可以只在从节点开启AOF（主节点不需要），这样即保证了数据的安全性，也避免了持久化对主节点性能的影响。

2、一主多从

针对读取操作并发较高的场景，读取操作由多个从节点来分担；但节点越多，主节点同步到多节点的次数也越多，影响带宽，也对主节点的稳定性造成负担。

3、树形拓扑结构

一主多从拓扑结构的缺点是主节点推送次数多、压力大，可用树形拓扑结构解决，主节点只负责推送数据到从节点A，再由从节点A推送到B、C和D，可以减轻主节点推送的压力。

Redis主从架构的缺点：

主从复制架构虽然可以提交读并发，但这种方式也有缺点。

（1）主从复制架构中，如果主节点出现问题，则不能提供服务，需人工修改重新设置主节点。（2）主从复制架构中，主节点单机写能力有限。

Redis哨兵模式

Redis主从复制架构的缺点是当主节点master出现故障后，redis新的主节点必须由开发人员手动修改，因此在主从复制架构基础上，演变出了哨兵机制。

哨兵机制的原理：

当主节点出险故障时，由redis哨兵自动完成故障发现和转移，并通知redis客户端，实现高可用性。

Redis哨兵进程是用于监控Redis集群中Master主服务器工作状态的。在主节点Master发生故障的时候，可以实现Master和Slave服务器的自动切换，保证系统的高可用性。Redis哨兵是一个分布式系统，可以在一个架构中运行多个Redis哨兵进程，这些进程使用流言协议（gossipprotocols）来接收关于Master主服务器是否下线的信息，并使用投票协议（Agreement Protocols）来决定是否执行自动故障迁移，以及选择某个Slave节点作为新的Master节点。

每个Redis哨兵进程会向其他Redis哨兵、Master主节点、Slave从节点定时发送消息，以确认被监控的节点是否“存活着”。如果发现对方在指定配置时间（可配置的）内未得到回应，那么暂时认为被监控节点已死机，即所谓的“主观下线（Subjective Down，简称SDOWN）”。与“主观下线”对应的是“客观下线（Objectively Down，简称ODOWN）”。

当“哨兵群”中的多数Redis哨兵进程在对Master主节点做出SDOWN的判断，并且通过SENTINEL is-master-down-by-addr命令互相交流之后，得出MasterServer的下线判断，此时认为主节点Master发生“客观下线”。通过一定的选举算法，从剩下的存活的从节点中选出一台晋升为Master主节点，然后自动修改相关配置，并开启故障转移（failover）。

Redis哨兵虽然由一个单独的可执行文件redis-sentinel控制启动，但实际上Redis哨兵只是一个运行在特殊模式下的Redis服务器，可以在启动一个普通Redis服务器时通过指定sentinel选项来启动Redis哨兵，Redis哨兵的一些设计思路和Zookeeper非常类似。