文章目录
1. 性能测试 - 【redis-benchmark】
//进入含有redis-benchmark执行文件的目录
// 解释:访问localhost:6379 模拟10个用户,每个用户请求100次
./redis-benchmark -h localhost -p 6379 -c 10 -n 100
2. 持久化
- 在指定的时间间隔内将内存中的数据集快照写入磁盘【Snapshot快照】,它恢复时是将快照文件直接读到内存里。Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件蓄换上次持久化好的文件。整个过程中,主进程是不进行任何I0操作的。这就确保了极高的性能。如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失
2. 持久化文件路径: 【 dir + dbfilename 】
2.1 RDB(Redis DataBase)模式 - 针对数据快照 - 默认 - 人类读不懂乱码
2.2 AOF(Append Only File)模式 - 针对Redis命令快照 - 人类可读懂
//开始aof持久化记录 - 配置文件
appendonly yes
测试Redis持久化是否生效
//开启Redsi服务
redis-server 配置文件
//客户端连接Redsi
redis-cli
//随便设置一个键值对
set school gdmu
//获取school,查看是否保存成功
get school
//正常退出Redis - 自动会生成aof文件在redis根目录中
shutdown
exit
//重新连接开启Redis服务,查看是否aof载入内存中
redis-server 配置文件
//可见载入文件成功
get school
2.3 AOF文件经过私自篡改,修复文件
//修复aof文件
redis-check-aof.exe --fix <需要修复的AOF文件>
2.4 同时开启 - 两种恢复顺序
2.5 性能建议
-
- RDB文件只用作后备用途 - 主从Redis中,建议从Redis进行持久化RDB文件 - 每15分钟一次 - 即 save 900 1
- RDB文件只用作后备用途 - 主从Redis中,建议从Redis进行持久化RDB文件 - 每15分钟一次 - 即 save 900 1
-
- 如果Enable AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了,代价一是带来了持续的IO,二是AOF rewrite的最后将 rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超过原大小100%大小重写可以改到适当的数值
- 如果Enable AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了,代价一是带来了持续的IO,二是AOF rewrite的最后将 rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上,默认超过原大小100%大小重写可以改到适当的数值
-
- 如果不Enable AOF,仅靠Master-Slave Repllcation实现高可用性也可以,能省掉一大笔10,也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个,微博就是这种架构
3. 发布订阅(pub/sub) - 消息通信模式
//订阅多个渠道 - 【接收消息】
subscribe <channel> <channel> ...
//发送消息到某个渠道,订阅者接收到message - 【发送消息】
publish <channel> <message>
//退订多个频道
unsubscribe <channel> <channel>
4. 主从复制 - 主机可读可写,从机只能读
注意:只要是某主机的从节点,该节点都是只能读不能写
4.1 概述
- 数据复制单向 - 只能从主节点到从节点 - Master已写为主,Slave已从为主
- 每台Redis都是主节点,并可以有多个从节点,但是从节点只能有一个主节点Redis
- 建议:单台Redis使用内存超过20G,上Redis集群,减缓内存压力
- 使用命令行配置主从机,如果从机Redis重启,就会变回主机,如果需要变回从机,则需要重新的配置主从命令,一配置自动获取主机的数据
从主机同步流程
//查看当前库的信息
info replication
4.2 配置
启动多个Redis,则需要同等的Redis配置文件
//修改的信息
//1. 端口号 port
//2. 持久化rdb文件:dbfilename
//3. 日志文件:logfile
//4. pid文件:pidfile -- linux才有
方式1 - 命令配置主从机器 - 只有暂时性
//启动Redis
redis-server 配置文件
//连接Redis
redis-cli -p 端口号
配置一台master机器,两台备用slaver机
//一般只要配置从机即可
//意思是:我是某个ip,端口号的奴隶
slaveof <ip号> <端口号>
方式2 - 配置文件中配置主从机 - 永久性起作用 - 真实开发场景
Linux - redis.conf文件
//从机的配置文件中 - 配置主机的端口号与Ip地址
replicaof <masterip> <masterport>
//从机配置主机的授权码
masterauth <master-password>
windows - redis.windows.conf文件
//从机的配置文件中 - 配置主机的端口号与Ip地址
slaveof <masterip> <masterport>
//从机配置主机的授权码
masterauth <master-password>
方式3- 从机变主机 - 但一开始从主机同步的数据不会被删除
//变为主机
slaveof no one
5. 哨兵[Sentinal]模式 - Redis集群中自动选举主机 - Linux才有哨兵模式
5.1 概述
1. 主机宕机,自动从从机中选举一台作为主机
2. 假设主服务器Redis宕机,哨兵1先检测到这个结果,系统并不会马上行failover过,仅仅是哨兵1主观的认为主服务器不可用,这个现象成为主观下线,当后面的哨兵也检测到主服务器不可用,并且数量达到一定值时,那么哨兵之间就会进行一次投票,投票的结果由一个哨兵发起,进行failover[ 故障转 ]操作。切换成功后,就会通过发布订阅模式,让各个哨兵把自己监控的从服务器实现切换主机,这个过程称为客观下线
5.2 配置
启动哨兵
//创建文件
touch redisSentinel.conf
//往上述文件添加内容
sentinel monitor 被监控名字[随意起] Redis的IP号 端口号 1
//启动哨兵
redis-sentinel redisSentinel.conf
5.3 哨兵配置文件 - Linux
6. 缓存穿透、雪崩、击穿
6.1 概述
6.2 缓存穿透解决方案
方案1 - 布隆过滤器 - 丢弃
方案2 - 布隆过滤器 - 不存在则在缓存中存空值
6.3 缓存击穿解决方案
6.4 缓存雪崩解决方案
其实集中过期,倒不是非常致命,比较致命的缓存雪崩,是缓存服务器某个节点宕机或断网。因为自然形成的缓存雪崩,一定是在某个时间段集中创建缓存,这个时候,数据库也是可以顶住压力的。无非就是对数据库产生周期性的压力而已。而缓存服务节点的若机,对数据库服务器造成的压力是不可预知的,很有可能瞬间就把数据库压垮。
雪崩情况