1. redis的应用场景

1.热点数据的缓存: 减少对数据库的访问频率，提供的应用程序的效率。

2.限时业务的运用: 比如短信验证码。

3.计数器相关问题: 比如:点赞 关注数

4.排行榜相关问题: 比如: 销售量 观看量

5.分布式锁： 比如: syn自动锁 和 lock 手动锁

2. redis持久化

扩充知识：

redis持久化理解：其就是将内存中的数据保存在磁盘的过程，作为持久化，更快捷读取数据，为减轻数据库的缓存压力，防止数据的丢失

redis持久化有两种方式：

1.RDB快照模式  【注：RDB快照模式是根据多长时间进行拍照储存，没拍照一次，新的数据将覆盖老的数据】

2.AOF日志追加模式  【注：把每个写命令通过write函数进行追加到日志中】

2.1 RDB快照模式

【注：每个一段时间对redis内存中的数据进行拍照存储。它是redis默认的持久化方式】

【注：优点是数据恢复快】

【注：缺点是可能会出现丢失最后一段时间的数据--数据完整性比较差】

RDB快照模式有两种触发模式：

2.1.1 通过save/bgsave进行手动触发

首先观察：我们进入到redis解压目录中找到dump.rdb文件

【注：我的redis软件放在/usr/local/app 下，你们的进入你们的饿redis下即可】

现在我们手动删除这个文件

rm -rf dump.rdb

 删除后，我们连接redis

redis-cli

在这其中，我随便向其中存储了一个set集合类型的元素

这时，我们手动触发RDB快照模式

返回查看redis解压目录中：

 又出现了，说明RDB手动触发成功

--------------------------------------------------------------------------------------------------------------------------------

【注：这里只演示save命令，因为bgsave一样，都是手动触发RDB的命令，只是优缺点不同】

save命令：该命令会阻塞当前Redis服务器，执行save命令期间，Redis不能处理其他命令，直到RDB过程完成为止。
执行完成时候如果存在老的RDB文件，就把新的替代掉旧的。我们的客户端可能都是几万或者是几十万，这种方式显然不可取。

bgsave命令：执行该命令时，Redis会在后台异步进行快照操作，快照同时还可以响应客户端请求。具体流程如下：

 -----------------------------------------------------------------------------------------------------------------------------------------

 2.1.2 自动触发模式

 【注：其是在一定时间内被执行多少次数后自动触发】

【注：其是通过修改配置文件产生效果，但是底层原理使用的还是bgsave】

【注：只需要将注释解开即可，其中，参数已经被官方所定义好，如需必要不需要改动】

这里只做演示使用。为方便，我们将其改成save 10 3

 其意义为在10秒触发3次及以上，触发RDB模式

2.2 AOF持久化

 【注：把每个写命令通过write函数追加到日志文件中。当redis启动时会读取日志文件中的命令，并把这些命令由上到下执行一遍】

 【注：优点：数据的完整性】

 【注：缺点：数据恢复慢】

【注：AOF默认不开启，需要到redis.conf文件中修改配置启动AOF模式】

进入我们的/usr/local/app/redis7 下直接打开redis.conf文件

修改：

# 需要改为yes  开启aof模式  配置文件1387行
appendonly yes

# 默认aof的日志文件名为appendonly.aof  配置文件1414行
appendfilename "appendonly.aof"

# 默认aof文件存放的目录名  配置文件1420行
appenddirname "appendonlydir"

# 触发的机制。always一直触发  everysec:每秒触发 no:如果开启aof那么就不能设置为no  配置文件1445 - 1447行
appendfsync always
#appendfsync everysec
# appendfsync no

 【注：修改配置文件后一定要保存，保存后一定要重启redis】

只能先杀掉redis进程在重启以达到重启的目的

pkill -9 redis

redis-server redis-conf

 再次进入到redis解压目录中，发现有一个appendonlydir的目录

 进入其中找到

 打开此文件，发现一片空白

 这时我们连接redis，在其中随便存储set集合类型的元素，再次打开此文件发现

AOF触发成功，将数据追加到日志中，以便数据的持久性

【注：AOF只有在写的情况下触发，只有在往其中存储的时候会触发】

3.redis集群模式

 集群模式有三种不同的表现形式：

1.主从模式

2.哨兵模式

3.集群分片模式

3.1 主从模式

【注：如果多个客户操作redis，进而导致redis承受到极限宕机，为了避免不必要的损失，首次出现的主从模式】

准备：

【注：需要准备至少三台redis服务器，虚拟机也行，一台为主节点，两台为从节点】

【注：最核心的一句话叫：配从不配主】【注：意为每增加一台redis服务器只需要将此服务器加入到主节点即可】

这里已经准备好了三台服务器用来演示：

首先需要查看这三台redis服务器当前的角色身份

命令

info replication     #查看当前redis服务器的角色身份

现在，我以ip为111.173.104.101这台服务器为主redis服务器，另外两台为从redis服务器

在另外两台从redis服务器分别输入

slaveof ip  port    #配置主从，这里ip需要的是主redis服务器的ip，端口是主redis服务器的端口

配置完后，再次输入info replication命令查看各自角色

发现，主服务中含有两个从服务节点，这时我们随便存入一个set的集合类型的元素数据

在从节点服务器中发现，数据可以共享。

【注：主从服务器中，数据共享】

【注：从服务器中只能读，不能写】

【注：主节点增加一些数据后，数据会同步到从服务器中】

【注：新增一个从节点，那么该从节点是可以把主节点之前的数据同步过来】

【注：当主节点宕机后，从节点不可以上位】

3.2 哨兵模式

【注：

上面的从主有缺点：主节点出现故障后，redis集群中就没有写操作。

其中，如果主节点宕机，应该让其他某台从节点自动上位。那么就需要使用哨兵模式】

准备一台哨兵服务

在redis解压目录中：

发现有这个文件，为哨兵配置文件，启动哨兵将从此开始

打开此文件，我们将进行哨兵配置：

#配置哨兵，监控   哨兵集群的名称 监控主节点的ip 主节点的端口 获取哨兵的票数
sentinel monitor mymaster 192.168.235.135 6379 1        #配置文件中的第93行

启动哨兵

redis-sentinel  sentinel.conf

启动成功

这个时候继续查看当前服务器的角色：

【注：哨兵模式是在主Redis服务器中设置】

这时我们手动关闭主节点服务器来模拟服务器宕机的情况

SHUTDOWN    #停止redis连接

主节点关闭后，发现哨兵监控立即有了反应 

其会在从节点中进行投票，当选票数最多的从节点会被选为主节点代替

【注：当之前宕机的主节点恢复后，并不会恢复主节点的身份，而是变成从节点连接着现推选的主节点】

以上便是Redis应用中的内容，如有漏缺请在下方留言告知，我会及时补充