月守护的博客

LRU简介LRU 缓存淘汰算法就是一种常用策略。LRU 的全称是 Least Recently Used，也就是说我们认为最近使用过的数据应该是是「有用的」，很久都没用过的数据应该是无用的，内存满了就优先删那些很久没用过的数据。过程思考我的思路是这样的：我们维护一个数组，越靠近数组尾部的结点是越早之前访问的。当有一个新的数据被访问时，我们遍历数据1.如果此数据之前已经被缓存在数组中了，我们遍历得到这个数据，返回成功，并将其从原来的位置删除，然后再插入到数组的头部。2.如果此数据没有在缓存在数组中，

常见问题缓存击穿缓存雪崩缓存击穿具体说明缓存穿透说简单点就是大量请求的 key 根本不存在于缓存中，导致请求直接到了数据库上，根本没有经过缓存这一层。举个例子：某个黑客故意制造我们缓存中不存在的 key 发起大量请求，导致大量请求落到数据库。解决办法参数校验最基本的就是首先做好参数校验，一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。缓存无效key如果缓存和数据库都查不到某个 key

分布式锁是什么？为什么需要它分布式锁就是在两个系统进程（可以不在同一台机器上）之间的加锁操作，使其实现原子操作上面这样讲，可能还是不明白。下面从一个案例出发：比如常见的电商系统，一般采用微服务架构。我们以其中的库存服务为例。在并发量不大的时候，一个库存服务就可以搞定。如下图，系统A代表一个库存服务：但是在并发量上来之后，我们需要水平扩展库存微服务。假设现在有两个库存服务，同一样商品有两个订单生成。但是这样一来会产生一个问题：假如某个时刻，redis里面的某个商品库存为1，此时两个请求同时到来，

redis应用场景缓存和分布式锁等等举例：记录帖子点赞数，评论数和点击数（hash）记录用户的帖子ID列表（排序），便于快速显示用户的帖子列表（zset）记录帖子的标题，摘要，作者和封面信息，用于列表页展示（hash）记录帖子的相关文章ID，根据内容推荐相关帖子（list）如果帖子的ID是整数自增的，可以使用Redis来分配帖子ID（计数器）等等redis安装有docker方式，Github源码编译方式，直接安装方式这里推荐docker安装方式，docker-compose搭建re

一，登录redis1.查询所有容器docker ps -a2.进入redis客户端docker exec -it xxx（ID） redis-clieg：3.需要退出直接ctrl + c 即可二，操作redis1.执行操作之前要验证密码Authentication required (如果你在config中进行了配置)auth 123456782.清除缓存flus...

持久化定义：将数据从掉电易失的内存，放到永久存储的设备上redis为什么需要持久化因为redis服务中所有数据都在内存中，所以必须持久化处理redis的两种持久化方式RDB（默认开启）和 AOF优先级关系：默认是开启了rdb，aof是关闭的。若开启了aof，一般aof更新频率高，所以优先aof还原数据库。只有aof关闭时，才会使用rdb还原数据库。aof开启时，没有appendonly.aof文件或为空，redis重启还是执行aof，不会还原rdb，所以结果上没有持久化的效果RDB持

cmd进入安装目录启动服务：redis-server --service-start停止服务：redis-server --service-stop