redis刷新缓存
A. Docker NextCloud Redis缓存配置
转自我的博客:https://sleele.com/2019/04/19/docker-nextcloud-redis缓则悄存配置/
前言
nextcloud这个东西真的是挺慢的,文件一多等刷新都要等很久,孙衡渣如果配置了Redis做缓存就会快不少
搭建过程我就不再赘述了,可以参照我上篇博文
https://sleele.com/2019/03/03/linux-qbittorrent和nextcloud安装笔记/
部署redis
docker run --name redis -d redis
查看docker容器IP
docker inspect --format='{{.Name}} - {{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}' $(docker ps -aq)
之后修改nextcloud的配置文件
首先到本地
docker cp nextcloud:/var/www/html/config/config.php /tmp/
vi /tmp/config.php
添加如下内容
找准位置在拦早【'memcache.local' => '\OC\Memcache\APCu',】 这行后面添加
host那行换成你的redis地址
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => array(
'host' => '172.17.0.5',
'port' => 6379,
),
再回去,注意直接回去会导致nextcloud报错,需要修改权限
docker cp config.php nextcloud:/var/www/html/config/
docker exec -it nextcloud bash
cd /var/www/html/config/
chmod 777 config.php
重启nextcloud,教程结束
docker restart nextcloud
B. Redis缓存过期机制
一、针对与设置了过期时间的key值
1.(主动)定期删除:定时随机的检查过期的key,如果过期则清理删除
redis.conf(每秒检查的次数1-500)配置: hz 10
2.(被动)惰性删除:当客户端请求到一个已经过期的key时,redis会检查是否过期并删除
所以,虽然key过期了,但是没被清理的话,还是会占内存的。
二、内存淘汰管理机制Memory Management
当内存占满之后,redis提供缓存淘汰机制。
redis.conf: maxmemory <bytes>
* noeviction:旧缓存永不过期,新缓存设置不了,返回错误
* allkeys-lru:清除最少用的旧缓存,然后保存新的缓存(推荐使用)
* allkeys-random:在所有的缓存中随机删除(不推荐)
* volatile-lru:在那些设置了expire过期时间的缓存中,清除最少用的旧缓存,然后保存新的缓存
* volatile-random:在那些设置了expire过期时间的缓存中,随机删除缓存
* volatile-ttl:在那些设置了expire过期时间的缓存中,删除即将过期的
C. Redis分布式缓存搭建
花了两天时间整理了之前记录的Redis单体与哨兵模式的搭建与使用,又补齐了集群模式的使用和搭建经验,并对集群的一些个原理做了理解。
笔者安装中遇到的一些问题:
如果make报错,可能是没装gcc或者gcc++编辑器,安装之 yum -y install gcc gcc-c++ kernel-devel ,有可能还是提示一些个c文件编译不过,gcc -v查看下版本,如果不到5.3那么升级一下gcc:
在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable
scl enable devtoolset-9 bash
重新make clean, make
这回编译通过了,提示让你最好make test一下/
执行make test ,如果提示 You need tcl 8.5 or newer in order to run the Redis test
那就升级tcl, yum install tcl
重新make test,如果还有error就删了目录,重新tar包解压重新make , make test
o/ All tests passed without errors! ,表示编译成功。
然后make install即可。
直接运行命令: ./redis-server /usr/redis-6.0.3/redis.conf &
redis.conf 配置文件里 bind 0.0.0.0 设置外部访问, requirepass xxxx 设置密码。
redis高可用方案有两种:
常用搭建方案为1主1从或1主2从+3哨兵监控主节点, 以及3主3从6节点集群。
(1)sentinel哨兵
/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &
sentinel2.conf配置:
坑1:master节点也会在故障转移后成为从节点,也需要配置masterauth
当kill master进程之后,经过sentinel选举,slave成为了新的master,再次启动原master,提示如下错误:
原因是此时的master再次启动已经是slave了,需要向现在的新master输入密码,所以需要在master.conf
中配置:
坑2:哨兵配置文件要暴露客户端可以访问到的master地址
在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中,配置该哨兵对应的master名字、master地址和端口,以及达到多少个哨兵选举通过认为master挂掉。其中master地址要站在redis访问者(也就是客户端)的角度、配置访问者能访问的地址,例如sentinel与master在一台服务器(122.xx.xxx.xxx)上,那么相对sentinel其master在本机也就是127.0.0.1上,这样 sentinel monitor mymaster 127.0.0.1 6379 2 逻辑上没有问题,但是如果另外服务器上的springboot通过lettuce访问这个redis哨兵,则得到的master地址为127.0.0.1,也就是springboot所在服务器本机,这显然就有问题了。
附springboot2.1 redis哨兵配置:
坑3:要注意配置文件.conf会被哨兵修改
redis-cli -h localhost -p 26379 ,可以登到sentinel上用info命令查看一下哨兵的信息。
曾经遇到过这样一个问题,大致的信息如下
slaves莫名其妙多了一个,master的地址也明明改了真实对外的地址,这里又变成127.0.0.1 !
最后,把5个redis进程都停掉,逐个检查配置文件,发现redis的配置文件在主从哨兵模式会被修改,master的配置文件最后边莫名其妙多了一行replicaof 127.0.0.1 7001, 怀疑应该是之前配置错误的时候(见坑2)被哨兵动态加上去的! 总之,实践中一定要多注意配置文件的变化。
(2)集群
当数据量大到一定程度,比如几十上百G,哨兵模式不够用了需要做水平拆分,早些年是使用codis,twemproxy这些第三方中间件来做分片的,即 客户端 -> 中间件 -> Redis server 这样的模式,中间件使用一致性Hash算法来确定key在哪个分片上。后来Redis官方提供了方案,大家就都采用官方的Redis Cluster方案了。
Redis Cluster从逻辑上分16384个hash slot,分片算法是 CRC16(key) mod 16384 得到key应该对应哪个slot,据此判断这个slot属于哪个节点。
每个节点可以设置1或多个从节点,常用的是3主节点3从节点的方案。
reshard,重新分片,可以指定从哪几个节点移动一些hash槽到另一个节点去。重新分片的过程对客户端透明,不影响线上业务。
搭建Redis cluster
redis.conf文件关键的几个配置:
启动6个集群节点
[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]
这时候这6个节点还是独立的,要把他们配置成集群:
说明: -a xxxx 是因为笔者在redis.conf中配置了requirepass xxxx密码,然后 --cluster-replicas 1 中的1表示每个master节点有1个从节点。
上述命令执行完以后会有一个询问: Can I set the above configuration? yes同意自动做好的分片即可。
最后 All 16384 slots covered. 表示集群中16384个slot中的每一个都有至少有1个master节点在处理,集群启动成功。
查看集群状态:
坑1:暴露给客户端的节点地址不对
使用lettuce连接发现连不上,查看日志 Connection refused: no further information: /127.0.0.1:7002 ,跟之前哨兵配置文件sentinel.conf里边配置master地址犯的错误一样,集群启动的时候带的地址应该是提供给客户端访问的地址。
我们要重建集群:先把6个redis进程停掉,然后删除 nodes-7001.conf 这些节点配置文件,删除持久化文件 mp.rdb 、 appendonly.aof ,重新启动6个进程,在重新建立集群:
然后,还是连不上,这次报错 connection timed out: /172.xx.0.xx:7004 ,发现连到企鹅云服务器的内网地址上了!
解决办法,修改每个节点的redis.conf配置文件,找到如下说明:
所以增加配置:
然后再重新构建集群,停进程、改配置、删除节点文件和持久化文件、启动进程、配置集群。。。再来一套(累死了)
重新使用Lettuce测试,这次终于连上了!
坑2:Lettuce客户端在master节点故障时没有自动切换到从节点
name这个key在7002上,kill这个进程模拟master下线,然后Lettuce一直重连。我们期望的是应该能自动切换到其slave 7006上去,如下图:
重新启动7002进程,
7006已成为新master,7002成为它的slave,然后Lettuce也能连接上了。
解决办法,修改Lettuce的配置:
笔者用的是springboot 2.1 spring-boot-starter-data-redis 默认的Lettuce客户端,当使用Redis cluster集群模式时,需要配置一下 RedisConnectionFactory 开启自适应刷新来做故障转移时的自动切换从节点进行连接。
重新测试:停掉master 7006,这次Lettuce可以正常切换连到7002slave上去了。(仍然会不断的在日志里报连接错误,因为需要一直尝试重连7006,但因为有7002从节点顶上了、所以应用是可以正常使用的)
Redis不保证数据的强一致性
Redis并不保证数据的强一致性,也就是取CAP定理中的AP
关于一致性Hash算法,可以参考 一致性Hash算法 - (jianshu.com)
Redis cluster使用的是hash slot算法,跟一致性Hash算法不太一样,固定16384个hash槽,然后计算key落在哪个slot里边(计算key的CRC16值再对16384取模),key找的是slot而不是节点,而slot与节点的对应关系可以通过reshard改变并通过gossip协议扩散到集群中的每一个节点、进而可以为客户端获知,这样key的节点寻址就跟具体的节点个数没关系了。也同样解决了普通hash取模算法当节点个数发生变化时,大量key对应的寻址都发生改动导致缓存失效的问题。
比如集群增加了1个节点,这时候如果不做任何操作,那么新增加的这个节点上是没有slot的,所有slot都在原来的节点上且对应关系不变、所以没有因为节点个数变动而缓存失效,当reshard一部分slot到新节点后,客户端获取到新迁移的这部分slot与新节点的对应关系、寻址到新节点,而没迁移的slot仍然寻址到原来的节点。
关于热迁移,猜想,内部应该是先做复制迁移,等迁移完了,再切换slot与节点的对应关系,复制没有完成之前仍按照原来的slot与节点对应关系去原节点访问。复制结束之后,再删除原节点上已经迁移的slot所对应的key。
与哨兵模式比较类似,当1个节点发现某个master节点故障了、会对这个故障节点进行pfail主观宕机,然后会通过gossip协议通知到集群中的其他节点、其他节点也执行判断pfail并gossip扩散广播这一过程,当超过半数节点pfail时那么故障节点就是fail客观宕机。接下来所有的master节点会在故障节点的从节点中选出一个新的主节点,此时所有的master节点中超过半数的都投票选举了故障节点的某个从节点,那么这个从节点当选新的master节点。
所有节点都持有元数据,节点之间通过gossip这种二进制协议进行通信、发送自己的元数据信息给其他节点、故障检测、集群配置更新、故障转移授权等等。
这种去中心化的分布式节点之间内部协调,包括故障识别、故障转移、选主等等,核心在于gossip扩散协议,能够支撑这样的广播协议在于所有的节点都持有一份完整的集群元数据,即所有的节点都知悉当前集群全局的情况。
Redis高可用方案 - (jianshu.com)
面试题:Redis 集群模式的工作原理能说一下么 - 云+社区 - 腾讯云 (tencent.com)
深度图解Redis Cluster原理 - detectiveHLH - 博客园 (cnblogs.com)
Redis学习笔记之集群重启和遇到的坑-阿里云开发者社区 (aliyun.com)
云服务器Redis集群部署及客户端通过公网IP连接问题
D. 项目中redis多久刷新
1秒。Redis是最受欢迎的Nosql数据库之一,Redis是一个使用ANSIC编写的开源、包含卜戚多种数据结构、支持网络、基于内存、可选持久性的键值型皮陵对存储数据库。项目中redis每隔一秒刷新一次。Redis是完全开握缓源的,遵守BSD协议,是一个高性能的 key-value数据库。
E. 请问redis缓存删除后会不会影响网站的访问,会重新生成缓存吗
当从 Redis 缓存中删除某个键时,该键对应的数据将不再存在于缓存中,因此在接下来的访问中如果需要该数据,则需要重新生成缓存。
具体影响取决于您的网站如何处理缓存丢失的情况。如果您的网站在尝试从缓存中获取数据时,发现该数据不存在,则可能需要从数据库中重新查询数据并将其存储到 Redis 缓存中。这可能会增加一些延迟,但不会导致网站崩溃岁磨。
如果您的网站在缓存丢失时无法正常工作,则可能需要进行修复,例如乎扰斗李祥实现一些容错机制,如使用备份缓存服务器或在缓存丢失时使用其他方式获取数据。
F. redis做mysql的缓存
redis缓存其实就是把经常访问的数据放到redis里面,用户查询的时候先去redis查询,没有查到就执行sql语句查询,同时把数据同步到redis里面。redis只做读操作,在内存中查询速度快。
使用redis做缓存必须解决两个问题,首先就是确定用何种数据结构存储来自mysql的数据;确定数据结构之后就是需要确定用什么标识来作为数据的key。
mysql是按照表存储数据的,这些表是由若干行组成。每一次执行select查询,mysql都会返回一个结果集,这个结果是由若干行组成的。redis有五种数据结构:列表list,哈希hash,字符串string,集合set,sorted set(有序集合),对比几种数据结构,string和hash是比较适合存储行的数据结构,可以把数据转成json字符串存入redis。
全量遍历键: keys pattern keys *
有人说 KEYS 相当于关系性数据的库的 select * ,在生产环境几乎是要禁用的
不管上面说的对不对, keys 肯定是有风险的。那我们就换一种方案,在存数据的时候。把数据的键存一下,也存到redis里面选hash类型,那么取的时候就可以直接通过这个hash获取所有的值,自我感觉非常好用!
G. redis缓存穿透,频繁查询db,怎么解决
首先要明白redis数据库
redis内存数据库, 所数据基本都存于内存, 定追加或者快照式刷新硬盘.
由于redis内存数据库, 所读取写入速度非快, 所经用做数据, 页面等缓存
H. SpringBoot进阶之缓存中间件Redis
大家好,一直以来我都本着 用最通俗的话理解核心的知识点, 我认为所有的难点都离不开 “基础知识” 的铺垫
“大佬可以绕过 ~”
本节给大家讲讲 “java的SpringBoot框架” , 之前我们学习的都是java的基础知识和底层提供的一些能力,我们日常工作都是在写接口。在我们在产品开发中,一般我们都会选择比较稳定的框架来帮我们加速开发,不会自己去造轮子,而在java众多框架中,spring框架表现的非常好,大部分公司都会首选它作为开发框架,而至今,大部分企业都是以 springboot 来构建项目了,一个稳健的系统需要引入稳定的技术~
如果你是一路看过来的,很高兴你能够耐心看完。前几期都是带大家学习了 SpringBoot 的基础使用以及集成 mybatis 开发,这也是我们写业务的基础,如果你还不熟悉这些,请先看完它们。接下来的几期内容将会带大家进阶使用,会先讲解基础 中间件 的使用和一些场景的应用,或许这些技术你听说过,没看过也没关系,我会带大家一步一步的入门,耐心看完你一定会有 收获 ,本期将会给大家讲解最热门的缓存中间件技术 Redis ,同样的,我们集成到 Springboot 中。最近github可能会被墙,所以我把源码放到了国内gitee上,本节我们依然使用上期的代码
Redis 是由意大利人Salvatore Sanfilippo(网名:antirez)开发的一款内存高速缓存数据库。全称叫 Remote Dictionary Server(远程数据服务) 是由 C语言 编写的,Redis是一个 key-value 存储系统,它支持丰富的数据类型,如: string、list、set、zset(sorted set)、hash 。
它本质上是一种键值对数据库,我们之前学习的 mysql 它是持久层的关系型数据库,而 redis 它的存储主要存在 内存 中。我们都知道在 内存 中的数据读取是非常快的,就好比你把一个变量存到磁盘读取和直接放到代码中运行,肯定是在代码中拿到的速度快,因为运行时期,都是直接存到内存的。
给大家总结一下:
有了基本的概念之后,我们下面进行环境搭建,在学习阶段,安装 redis 很简单,生产环境一般我们也会选择云产品,一切为了服务保障,虽说它只是做缓存用,但也是系统的一把 保护伞
如果你是 mac 用户,你可以运行如下命令:
安装完成后会提示你运行命令,运行即可。
win 用户也很简单,直接下载 redis 软件,双击运行即可,运行之后它会有一个小方块的图案,和 locahost:6379 的log,说明运行成功了。初始阶段没有配置的 redis 默认 host 就是本地, port 就是 6379 , 而且是 没有密码 就可以访问的。
推荐一个客户端软件 Redis Desktop Manager ,它是 redis 的客户端界面软件,方便面我们学习的时候 清理缓存 使用,生产慎连。
我们不给大家讲它的基本命令使用,它也有语法,可以通过类似命令执行,如果想学习的小伙伴,可以自行搜索。本期重点内容是在 sprinboot 中的使用,我们平时开发不可能是去命令行里敲的,都是代码里执行,而目前市面上有很多封装好的库,我们可以直接调用它的方法,很方便的就可以操作它了,不用记一些繁琐的命令,下面我们就实际操作一下:
修改 pom.xml
修改 application.yml :
redis 默认是有 16 个库,不是 15 个啊,从 0 开始算的,我们随便连一个
通过代码很好理解, 首先需要引入 StringRedisTemplate ,然后需要设置一个 key ,那么思考一下,这个 key 允许重复吗
我们进客户端看一下,发现 key 还是只有一个,但是值变成了新的值了,所以可以得知 key 是唯一的,我们重新设置的时候相当于刷新了它。
在 redis 中删除缓存有两种方式,一种是自我消亡,也就是 过期 销毁,还有有一种是 主动 销毁,我们先看一下,过期时间如何设置
我们设置了 10s 后过期,过完10s后发现,这个```key data``消失了。我们在看看如何主动删除
我们可以利用 Redis 做一个计数器,实现自增功能,你可以用它做网站访问统计
通常做法,我们会把它封装一下,后续使用直接引入封装好的即可,把它直接交给 Springboot容器 管理
其实这个类,你还可以继续进一步封装,比如约束 key 的规范,约束过期时间,约束数据类型等等,这一切也都是为了规范和后期维护,防止滥用缓存
缓存的主要场景是用于解决热点数据问题,因为这些数据是访问频率比较高的,当大量的请求进来, mysql 可能压力很大,这样一来,数据查询效率就很慢,用户肯不高兴等了,这样用户体验很不好。所以我们一般做法,都是把这些热点数据放到缓存里,因为缓存读取速度很快。当有新数据的时候,我们再及时更新它,一般流程是先查询缓存,查到了直接返回缓存数据,查不到再走数据库,然后再刷回缓存。
但是并发足够大的时候,还是会暴露出很多问题,比如面试常问的一些高频问题 缓存雪崩、缓存穿透、缓存雪崩 ,这些问题后边会给大家专门讲,和如何去防范。所以总的来说,引入任何一门技术并不是万事大吉,还需我们不断的在实践中积累经验
本期到这里就结束了,总结一下,我们了解了什么是 redis ,以及在 springboot 中如何去使用它们,很简单,没什么复杂的东西。但这里想多说一点的是,缓存的设计却是很复杂的,因为工具是死的,人是活的,我们如何正确设计,需要我们在项目中不断的积累。
我们之前教大家查询列表数据,都是所有数据返回,还没有教大家如何去做分页,下期将带大家学习一下 mybatis 分页插件的使用 ,下期不见不散, 关注我,不迷路~
I. redis缓存中的数据怎么更新
伪代码如下,思路也清晰。
读写部分
if(redis){
读取redis数据
}else{
数据库读取,存redis+设置超时时间
}
更新部分
if(数据库update){
更新redis+设置超时时间
}
J. 怎么清理redis缓存
如果redis没有设置持久化的话,可以重启redis服务来清理配置的缓存。