huapro.vip的程序人生

Redis 是基于单线程模型实现的，也就是 Redis 是使用一个线程来处理所有的客户端请求的，尽管 Redis 使用了非阻塞式 IO，并且对各种命令都做了优化（大部分命令操作时间复杂度都是 O(1)），但由于 Redis 是单线程执行的特点，因此它对性能的要求更加苛刻，本文我们将通过一些优化手段，让 Redis 更加高效地运行。本文我们将使用以下手段，来提升 Redis 的运行速度：缩短键值对的存储长度；使用 lazy free（延迟删除）特性；设置键值的过期时间；禁用长耗时的查询命令；使用

redis是单线程，收割时间也会占用线程处理时间，如果收割过于频繁，会导致读写出现卡顿。1、主库过期策略1.1、定时扫描首先将每个设置了过期时间的key放到一个独立的hash中，默认每秒定时遍历这个hash而不是整个空间：并不会遍历所有的key，采用一种简单的贪心策略1.1.1、从过期key字典中，随机找20个key。1.1.2、删除20gekey中过期的key1.1.3、如果2中过期的key超过1/4，则重复第一步1.1.4、每次处理的时间都不会25ms如果有大量的key在同一时间段内过

slowlog 此命令用于读取和重置Redis慢查询日志。一、Redis slowlog 官方概述:Redis Slow Log是一个用于记录超过指定执行时间的查询的系统。执行时间不包括与客户端交谈，发送答复等I / O操作，而仅包括实际执行命令所需的时间（这是命令执行的唯一阶段，在该阶段线程被阻塞并且不能同时满足其他要求）。通俗的讲使用这个命令可以读取或重置 Redis 慢速查询日志。就是 redis 可以把执行时间超过我们设定值的命令记录下来，slowlog 是记录到内存中的，所以查询非常快。这里

懒加载延迟双删在写库前后都进行redis.del(key)操作，并且第二次删除通过延迟的方式进行。方案一（一种思路，不严谨）具体步骤是：1）先删除缓存；2）再写数据库；3）休眠500毫秒（根据具体的业务时间来定）；4）再次删除缓存。那么，这个500毫秒怎么确定的，具体该休眠多久呢？需要评估自己的项目的读数据业务逻辑的耗时。这么做的目的，就是确保读请求结束，写请求可以删除读请求造成的缓存脏数据。当然，这种策略还要考虑 redis 和数据库主从同步的耗时。最后的写数据的休眠时间：则在读数据业

缓存淘汰策略的实现从本质上来说，缓存算法并没有好坏之分，只有是否适用当前的业务场景。因此根据不同的业务场景设置不同的缓存算法会使缓存命中率更高。一、FIFOFIFO（First in First out）先进先出。可以理解为是一种类似队列的算法实现实现概念：最先进来的数据，被认为在未来被访问的概率也是最低的，因此，当规定空间用尽且需要放入新数据的时候，会优先淘汰最早进来的数据。优点：没什么优点缺点：算法逻辑设计所实现的缓存的命中率是比较低，没有任何额外逻辑能够尽可能的保证常用数据不被淘汰掉。二

AOF定义：以日志的形式记录每个操作，将Redis执行过的所有指令全部记录下来（读操作不记录），只许追加文件但不可以修改文件，Redis启动时会读取AOF配置文件重构数据换句话说，就是Redis重启就会根据日志内容从头到尾执行一次来完成数据的恢复工作。Tip:　　一.RDB与AOF同时开启 默认先加载AOF的配置文件　　二.相同数据集，AOF文件要远大于RDB文件，恢复速度慢于RDB　　三.AOF运行效率慢于RDB,但是同步策略效率好，不同步效率和RDB相同1.RDB持久化(以快照的方式) 策

Mybatis 一级缓存作用域是 session，session commit 之后缓存就失效了。Mybatis 二级缓存作用域是 sessionfactory，该缓存是以 namespace 为单位的（也就是一个 Mapper.xml 文件），不同 namespace 下的操作互不影响。所有对数据表的改变操作都会刷新缓存。但是一般不要用二级缓存，例如在 UserMapper.xml 中有大多数针对 user 表的操作。但是在另一个 XXXMapper.xml 中，还有针对 user 单表的操作。这会导

雪崩造成的原因？1 如果你不是主从或者集群部署，那么当你的一个 redis 节点挂掉，或者机器掉电了，那么你这个节点的 key 就会全部丢失 ，此时以前这个 key 的流量就会流向其他节点，而其他节点没有这些 key，那么流量就会到达 db 重新加载数据到 cache，那么你的 db 就可能被大流量超过你的所能承载的流量而被压垮。2 如果你的大部分 key 设置了相同的过期时间，那么 key 就会在相同的时刻失效，那么也会造成大流量流入到 db 而压垮你的 db，一般会出现在你直行了一个离线任务定时更新