Redis的分布式应用

最新推荐文章于 2022-05-15 22:01:43 发布

一个会写代码的文艺青年

最新推荐文章于 2022-05-15 22:01:43 发布

阅读量280

点赞数

分类专栏：中间件文章标签： redis

本文链接：https://blog.csdn.net/qq_41908550/article/details/108848253

版权

中间件专栏收录该内容

14 篇文章 0 订阅

订阅专栏

一. Redis配置文件

①可以include引入其他的配置文件组合成一个

②NETWORK

bind 0.0.0.0  绑定的IP
protected-mode yes  是否是收保护
port 6379   端口号
daemonize yes   是否是守护进程(是否可以后台运行)
pidfile /var/run/redis_6379.pid   制定的PID
loglevel notice   日志级别，根据级别输出不同的日志
logfile ""   日志的文件路径
databases 16   数据库数量
always-show-logo yes  是否显示logo

③快照 SNAPSHOTTING——> RDB文件

save 900 1   如果在900秒内，有一条数据放生了变化，则会进行持久化
stop-writes-on-bgsave-error yes   如果持久化出错了，是否继续工作
rdbcompression yes   是否需要压缩RDB文件，会消耗CPU的资源
dir ./   rdb文件的保存目录，默认是在当前路径

④主从复制 REPLICATION

⑤安全 SECURITY

requirepass root   #设置密码

⑥限制

maxmemory-policy noeviction   #最大内存策略

noeviction: 不删除策略, 达到最大内存限制时, 如果需要更多内存, 直接返回错误信息。大多数写命令都会导致占用更多的内存(有极少数会例外, 如 DEL )。
allkeys-lru: 所有key通用; 优先删除最近最少使用(less recently used ,LRU) 的 key。
volatile-lru: 只限于设置了 expire 的部分; 优先删除最近最少使用(less recently used ,LRU) 的 key。
allkeys-random: 所有key通用; 随机删除一部分 key。
volatile-random: 只限于设置了 expire 的部分; 随机删除一部分 key。
volatile-ttl: 只限于设置了 expire 的部分; 优先删除剩余时间(time to live,TTL) 短的key。

⑦持久化 APPEND ONLY MODE

appendonly no   #默认不开启AOF模式
appendfilename "appendonly.aof"       #持久化的文件名
# appendfsync always   每次修改都会同步
appendfsync everysec   每隔一秒，同步一次
# appendfsync no       不同步

二. Redis的持久化

Redis是内存数据库，如果不进行持久化，就会丢失

2.1 RDB

Redis的默认持久化方式，会将持久化文件存为一个RDB文件，在恢复至直接用该文件读取到内存

当满足配置快照的触发操作时，Redis就会自动进行RDB文件的快照存储

配置文件中默认的路径是在当前路径，默认的文件名是：dump.rdb

原理：

通过创建一个fork子进程，将内存中的数据写入磁盘。先写入一个临时文件，等持久化完成后，在用这个临时文件替换上一次保存的RDB文件。完成持久化。

整个过程中，主进程是不需要任何IO操作的。比AOF持久化性能高，但是缺点是最后一次持久化的数据可能是丢失的。因为没有出发RDB操作，最新的持久化文件并不是所有的内存集。

使用：

配置文件中修改策略：save 60 5 #表示如果60秒内有5个KEY值被更新，则触发执行RDB，更新dump文件

当执行flushAll时，也会自动生成RDB文件。

Redis关机时SHUTDOWN，也会生成RDB文件，但是kill -9 是不会自动执行RDB文件的

恢复：

将需要恢复的内存数据RDB文件，放在Redis的启动目录，Redis在启动时，会自动监测并执行dump.rdb文件，恢复数据

优点：

对数据的完整性要求不高

适合大量数据的恢复

缺点：

可能会导致最后一次修改的数据修饰

fork子进程需要占用一定的内存空间

2.2 AOF

以日志的形式记录每个写操作。

AOF的持久化备份是将Redis执行的的所有指令记录下来(读指令不记录)，只许追加文件不可以改写文件，Redis启动的时候，会将AOF的持久化文件执行一次，也就是会将所有的指令从头到尾执行一遍。如果数据量很大，则执行起来将会比较耗时。

当文件达到默认值(64m配置文件中的)后，会进行重写操作，像RDB一样，fork一个进程，临时文件的方式重写AOF文件。

开启使用：

将配置文件中的appendonly yes 修改为YES就可以启用AOF的持久化功能了。

可以设置一些记录规则，此时AOF功能就启动了

此时启动Redis服务后，就会发现

如果AOF文件被损坏或者有错误，Redis启动会失败。此时就需要用Redis-check-aof工具来完成Redis的修复

redis-check-aof --fix appendonly.aof

优点和缺点

如果每次命令都同步的话，能够保证数据的完整性，但是会损失性能
相比于RDB，AOF文件大得多，而且执行恢复的效率也比RDB文件差

三. Redis的订阅发布

Redis支持类似MQ一样的发布订阅功能。Redis提供一个队列存储消息，生产者将消息发布，多个订阅了该channel的消费者都会受到消息，Redis也可以像MQ一样，订阅能够匹配通配符的概念，例如：msg.* 就能够接受到msg.*所有channel的消息了

原理：

Redis维护了一个字典，该字典的内容就是所有的channel，每一个channel都存放了一个链表，链表的内容就是所有订阅该channel的客户端。生产者将消息发布时，存放在channel中，然后循环发送到每一个客户端。完成发布订阅功能。

应用：

实时消息、聊天室、订阅、关注系统等。

四. Redis集群的搭建

4.1 主从复制

Redis的主从复制就是一个master节点，多个slave节点。master节点负责写入数据，slave节点负责读取数据

4.1.1 为何要搭建主从复制

一台Redis服务器是存在性能瓶颈的。搭建主从复制模式后，可以在多台Redis上通过负载均衡策略实现多台服务器提供读取。减少了压力。
一般主从复制也是一种持久化的方式，将某一台slave节点服务器配置持久化策略，一般用的是RDB持久化。
如果只有一台Redis的话，很有可能会发生单点故障，配置主从模式，能够保证Redis的高可用性，如果master节点Redis宕机后，可以通过切换节点的方式，完成主从切换。

4.1.2 搭建配置

不需要特意设置master节点，因为默认就是master，只需要修改为salve即可。

设置了主从模式后，默认主节点可以写，slave节点执行写入会报错。并且默认slave会自动复制主节点的全部信息

查询Redis的主从节点信息：info replication

搭建主从模式的Redis：可以在一台服务器搭建多个Redis服务，或者在多台服务器搭建多个Redis：

默认Redis服务启动就是master，所以只需要将需要设置的salve进行修改即可。

首先启动多个Redis服务
启动客户端后，通过命令：SLAVEOF host port #直接将当前的Redis服务设置为该IP的slave节点，但是是临时的。（如果master服务器有密码的话，则需要在配置文件中将：masterauth 123456 密码添加一下就好了），服务重启后，主节点连接会消失
通过修改配置文件的方式，将Redis设置为slave：此方式为永久的

在需要进行设置为salve节点的Redis服务配置文件REPLICATION模块中，修改如下内容：

①replicaof 124.71.112.168 6379

②masterauth root

完成！启动Redis服务后，就是该服务器的slave节点啦

结果：

4.1.3 复制原理

slave连接上master主节点后，会发送一个同步命令，masterRDB文件传输给salve节点，将master的所有数据进行同步，当master节点数据发生变动时，salve也会同步增量同步

全量复制：slave接收到master发送过来的全量数据文件时，将其存盘全量复制到内存中
增量复制：master与slave连接后，master会继续将收集到的命令依次传给slave，完成同步。
salve只要重新连接master，会一次性完成全量复制，自动执行

4.1.4 手动配置为master

讲一个slave节点手动配置为master节点，可以通过SLAVEOF ONE ONE将当前salve设置为手动的。

但是不会用，会用的是通过哨兵模式自动将salve替换为master节点。

4.2 哨兵模式：主从切换

当master节点故障宕机后，通过策略自动将某个slave节点切换为master节点。从Redis2.8后有了哨兵模式（sentinel），完成主从的自动切换。

哨兵是一个独立的进程

原理：是通过发送命令，等待Redis服务器的响应，监测Redis的实例是否是正常运行。类似于进行心跳检测。

原理剖析：

一般在使用Redis集群时，哨兵进程也会配置多个。用于哨兵之间相互监测以及监测Redis实例的作用：

当某个master节点宕机后，其中多个哨兵无法接收到该实例的响应时。哨兵之间会对slave节点进行一次投票。将票数多的slave节点进行故障转移。设置为master节点。然后通过发布订阅模式，让各个哨兵把新的master节点切换为主机。实现主从自动切换。

如果宕机的实例重新启动后，会默认作为slave从机使用。

使用：

Redis的安装路径中有个redis-sentinel，就是哨兵模式的启动进程文件。同时哨兵的启动需要配置文件：sentinel.conf

如果要配置多个哨兵，就需要在多个Redis实例上启动多个哨兵进程即可

启动： redis-sentinel sentinel.conf

核心配置文件：


1、sentinel monitor <master-name> <ip> <port> <quorum>  #配置即可使用

master-name：redis主节点昵称。

ip：redis主机ip。

port：redis主机端口。

quorum：哨兵判断主节点是否发生故障的票数。如果设置为2，表示2个哨兵节点认为主节点发生了故障，一般设置为：哨兵节点数/2+1。

2、sentinel down-after-milliseconds <master-name> <times>

哨兵会定期的向redis节点发送ping命令来判断redis是否可达，若超过指定的times毫秒内还未得到pong回复，则判读该redis不可达。

3、sentinel parallel-syncs <master-name> <nums>

当redis主节点挂了后，哨兵会选出新的master，此时，剩余的slave会向新的master发起同步数据，这个设置表示允许并行同步的slave个数。

4、sentinel failover-timeout <master-name>  <times>

进行故障转移时，如果超过设置的times毫秒，表示故障转移失败。

5、sentinel auth-pass <master-name> <password>

如果redis主节点设置了密码，则需要进行这个配置。

简单使用：

编写配置文件sentinel.conf，启动哨兵进程后，主节点宕机，slave节点会自动切换为主节点。切换后，哨兵的配置文件也会自动修改为最新主节点的IP与端口

4.3 springboot中配置Redis的集群读写分离

4.4 缓存穿透与缓存雪崩

缓存穿透(无效数据)

缓存穿透就是如果用户请求的数据不存在，缓存中不存在，数据库中也不存在，此处如果有大量的客户端请求发出来。则会穿过缓存直达数据库，导致数据库可能出现的异常崩溃。

解决方案：

使用布隆过滤器
将空对象添加到缓存

缓存雪崩(缓存失效)

热点数据或者大量数据出现缓存过期、Redis宕机，期间大量请求访问，导致缓存不存在，直接击穿访问到了数据库。导致数据库崩溃

解决方案：

一个会写代码的文艺青年

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Redis的分布式应用

一. Redis配置文件①可以include引入其他的配置文件组合成一个②NETWORK bind 0.0.0.0 绑定的IPprotected-mode yes 是否是收保护port 6379 端口号daemonize yes 是否是守护进程(是否可以后台运行)pidfile /var/run/redis_6379.pid 制定的PIDloglevel notice 日志级别，根据级别输出不同的日志logfile "" 日志的文件路径data...
复制链接

扫一扫