一位打工仔的博客

我们平常使用redisson的分布式锁是怎么做的？是不是基本都用的这个模板，既然是模板，那为何不把他抽出来呢？

RedisTemplate、StringRedisTemplate： 操作redis的工具类。要从redis的连接工厂获取链接才能操作redis。属于 JPA 操作，也不用管。属于响应式编程，不用管。

a、同步阻塞：服务员说快到你了，先别离开我后台看一眼马上通知你。客户在海底捞火锅前台干等着，啥都不干。b、同步非阻塞：服务员说快到你了，先别离开。客户在海底捞火锅前台边刷抖音边等着叫号。c、异步阻塞：服务员说还要再等等，你先去逛逛，一会儿通知你。客户怕过号在海底捞火锅前台拿着排号小票啥都不干，一直等着店员通知。d、异步非阻塞：服务员说还要再等等，你先去逛逛，一会儿通知你。拿着排号小票+刷着抖音，等着店员通知。

面试题：谈谈Redis数据类型的底层数据结构：官网：GitHub - redis/redis: Redis is an in-memory database that persists on disk. The data model is key-value, but many different kind of values are supported: Strings, Lists, Sets, Sorted Sets, Hashes, Streams, HyperLogLogs, Bitmaps.源码

数据到达过期时间，不做处理。等下次访问该数据时，如果未过期，返回数据；发现已过期，删除，返回不存在。开启隋性淘汰，配置文件中修改：lazyfree-ay-eviction=yes惰性删除策略的缺点是，它对内存是最不友好的。如果一个键已经过期，而这个键又仍然保留在redis中，那么只要这个过期键不被删除，它所占用的内存就不会释放。在使用惰性删除策略时，如果数据库中有非常多的过期键，而这些过期键又恰好没有被访问到的话。

失败了多少个机器实例后我还是可以容忍的，所谓的容忍就是数据一致性还是可以Ok的，CP数据一致性还是可以满足。加入在集群环境中，redis失败1台，可接受。2X+1 = 2 * 1+1 =3，部署3台，死了1个剩下2个可以正常工作，那就部署3台。加入在集群环境中，redis失败2台，可接受。2X+1 = 2 * 2+1 =5，部署5台，死了2个剩下3个可以正常工作，那就部署5台。

1.数据共享，分布式Session2.分布式锁3.全局ID5.位统计6.购物车7.轻量级消息队列：list、stream8.抽奖10.差集交集并集，用户关注、可能认识的人，推荐模型11.热点新间、热搜排行榜。

面试题：@PostConstruct初始化白名单数据详情地址可查看代码：Redis BitMap/HyperLogLog/GEO/布隆过滤器案例_Please Sit Down的博客-CSDN博客1、redis中key设置为永不过期 or 过期时间错开2、redis缓存集群实现高可用3、多缓存结合预防雪崩4、服务降级 请求去查询一条记录，先查redis无，后查mysq无，都查询不到该条记录，但是清求每次都会打到数据库上面去，导致后台数据库压力暴增。这种现象我们称为缓存穿适，这个redis变成了

是否存在：有，是很可能有；无，是肯定无，100%无。使用时最好不要让实际元素数量远大于初始化数量，一次给够避免扩容。当实际元素数量超过初始化数量时，应该对布隆过滤器进行重建，重新分配一个size更大的过滤器，再将所有的历史元素批量add进行。

【先更新缓存，再更新数据库】，A、B两个线程发起调用【正常逻辑】【异常逻辑】多线程环境下，A、B两个线程有快有慢有并行结果：mysql100,redis80。

这个指令没有offset、limit参数，是要一次性吐出所有满足条件的key，由于redis是单线程的，其所有操作都是原子的，而keys算法是遍历算法，复杂度是O(n)，如果实例中有千万级以上的key，这个指令就会导致Redis服务卡顿，所有读写Redis的其它的指令都会被延后甚至会超时报错，可能会引起缓存雪崩甚至数据库宕机。， 第一个元素是用于进行下一次迭代的新游标， 第二个元素则是一个数组， 这个数组中包含了所有被迭代的元素。非常特别，它不是从第一维数组的第零位一直遍历到末尾，而是。

I/O 的读和写本身是堵塞的，比如当 socket 中有数据时，Redis 会通过调用先将数据从内核态空间拷贝到用户态空间，再交给 Redis 调用，而这个拷贝的过程就是阻塞的，当数据量越大时拷贝所需要的时间就越多，而这些操作都是基于单线程完成的。，你站在讲台上等，谁解答完谁举手。比如当我（Redis）需要删除一个很大的数据时，因为是单线程原子命令操作，这就会导致 Redis 服务卡顿，于是在 Redis 4.0 中就新增了多线程的模块，当然此版本中的多线程主要是为了解决删除数据效率比较低的问题的。

1、模拟节点下线：人为模拟，master-6381机器意外宕机，手动shutdown，先对redis集群命令方式，手动验证各种读写命令，6384上位替换原主节点6381。SpringBoot2.X版本，Redis默认的连接池采用Lettuce，当Redis集群节点发生变化后，Lettuce默认是不会刷新节点拓扑。Lettuce是一个Redis的Java驱动包，Lettuce翻译为生菜，没错，就是吃的那种生菜，所以它的Logo长这样。当master宕机主从切换成功，redis手动OK，but 2个经典故障。

Redis集群不保证强一致性，这意味着在特定的条件下，Redis集群可能会丢掉一些被系统收到的写入请求命令。

吹哨人巡查监控后台 master 主机是否故障，如果故障了根据投票数自动将某一个从库转换为新主库，继续对外服务。上述的failover操作均由sentinel自己独自完成，完全无需人工干预。

其实就是主从复制，，当master数据变化的时候，自动将新的数据异步同步到其它slave数据库。

Redis可以实现消息中间件MQ的功能，通过发布订阅实现消息的引导和分流。仅代表我个人，不推荐使用该功能，专业的事情交给专业的中间件处理，redis就做好分布式缓存功能。Pub/Sub缺点：发布的消息在ds系统中不能持久化，因此，必须先执行订阅，再等待消息发布。如果先发布了消息，那么该消息由于没有订阅者，消息将被直接丢弃。消息只管发送对于发布者而言消息是即发即失的，不管接收，也没有ACK机制，无法保证消息的消费成功。

Pipeline与原生批量命令对比1、原生批量命令是原子性(例如：mset,mget)，pipeline是非原子性2、原生批量命令一次只能执行一种命令，pipeline支持批量执行不同命令3、原生批命令是服务端实现，而pipeline需要服务端与客户端共同完成Pipeline与事务对比1、事务具有原子性，管道不具有原子性2、管道一次性将多条命令发送到服务器，事务是一条一条的发，事务只有在接收到 exec 命令后才会执行，管道不会。

开启：以 MULTI 开始一个事务入队：将多个命令入队到事务中，接到这些命令并不会立即执行，而是放到等待执行的事务队列里面执行：由EXEC命令触发事务。

以日志的形式来记录每个写操作，将Redis执行过的所有写指令记录下来（读操作不记录），只许追加文件但不可以改写文件，redis启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。默认情况下，redis 是没有开启AOF(append only file)的开启 AOF 功能需要设置配置AOF 保存的是 appendonly.aof 文件。

Redis Stream 主要用于消息队列（MQ，Message Queue），Redis 本身是有一个 Redis 发布订阅 (pub/sub) 来实现消息队列的功能，但它有个缺点就是消息无法持久化，如果出现网络断开、Redis 宕机等，消息就会被丢弃。的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定且是很小的。集合中最大的成员数为 2^32 - 1。Redis 中Set集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是 O(1)。

最后然后再执行firewall-cmd --query-port=6379/tcp，返回yes，证明端口已经成功开启。firewall-cmd --add-port=6379/tcp，将6379端口开启，返回success。一遍，出现小黑框闪烁一下说明连接没有问题。解决办法将标准错误去除即可，追加2>/dev/null，将标准错误丢弃即可，就没有烦人的警告了。首先输入firewall-cmd --query-port=6379/tcp，2（标准错误）我们的命令，即包含1也包含2，2即是我们想要去除的提示。

每个系统通 过 zookeeper 获取分布式锁，确保同一时间，只能有一个系统实例在操作某个 key，别人都不 允许读和写。这个也是线上非常常见的一个问题，就是多客户端同时并发写一个 key，可能本来应该先到的 数据后到了，导致数据版本错了；你要写入缓存的数据，都是从 mysql 里查出来的，都得写入 mysql 中，写入 mysql 中的时候必 须保存一个时间戳，从 mysql 查出来的时候，时间戳也查出来。如 果是的话，那么可以写，否则，就不能用旧的数据覆盖新的数据。

原因很简单，很多时候，在复杂点的缓存场景，缓存不单单是数据库中直接取出来的值。比如可能更新了某个表的一个字段，然后其对应的缓存，是需要查询另外两个表的数据并进行 运算，才能计算出缓存最新的值的。另外更新缓存的代价有时候是很高的。是不是说，每次修改数据库的时候，都一定要将其对应 的缓存更新一份？也许有的场景是这样，但是对于比较复杂的缓存数据计算的场景，就不是 这样了。如果你频繁修改一个缓存涉及的多个表，缓存也频繁更新。但是问题在于，

指查询一个一定不存在的数据，由于缓存是不命中，将去查询数据库，但是 数据库也无此记录，我们没有将这次查询的null写入缓存，这将导致这个不 存在的数据每次请求都要到存储层去查询，失去了缓存的意义。缓存雪崩是指在我们设置缓存时key采用了相同的过期时间，导致缓存在某一时刻同时失效，请求全部转发到DB，DB瞬时压力过重雪崩。大量并发只让一个去查，其他人等待，查到以后释放锁，其他 人获取到锁，先查缓存，就会有数据，不用去db。风险： 利用不存在的数据进行攻击，数据库瞬时压力增大，最终导致崩溃。