Java后端八股笔记

Redis八股

在这里插入图片描述

在这里插入图片描述
上两种都有可能导致脏数据
所以使用两次删除缓存的技术，延时是因为数据库有主从问题需要更新，无法达到完全的强一致性，只能达到控制一致性。

一般放入缓存中的数据都是读多写少的数据
在这里插入图片描述
业务逻辑代码👇

写锁👇

读写锁的方法确实可以达成强一致性，但是效率太低了。

👆默认一般使用everysec

RDB如果两次备份之间宕机了，会丢失数据

在这里插入图片描述

在这里插入图片描述

多端部署无法限制线程的互斥👆

👆EX 过期时间还是需要设定的，因为如果突然宕机了，锁设定了时间会按时间释放，不设定则无法释放会造成死锁。

同一个线程可重入锁！！！👆

在这里插入图片描述
👆主机宕机了后，一个从属机器变成了主机器，再次为新线程分配锁，造成了两个线程持有一把锁，无法保证主从的一致性

👆红锁可以保证主从数据的一致性。但是低效
一般业务中redis不能保证数据的强一致性，如果想保证强一致性可以使用zookeeper
在这里插入图片描述

在这里插入图片描述

👆当master down了之后哨兵选代替主节点(master)的过程

👇脑裂是因为哨兵监听主节点的时候网络不畅，又在可控范围选择了新的master节点，当网络通常后，清空了master(原)，让其成为slave，导致这段时间写在master里的数据被清空。
在这里插入图片描述

👆这个是解决脑裂的方法，write最少一个salve点，lag延迟不能超过5秒，这些不满足就拒绝客户端的请求，减少数据的进一步丢失。(不是很懂其中逻辑)
在这里插入图片描述

👆每个master保存不同的数据，彼此检测online状况(类似哨兵！)，访问任意一个master就可以获得其他master的数据（master之间有路由）。

👇有效实例就是master节点

等待数据就绪和读取时间浪费了很多时间。👆
在这里插入图片描述

👆IO是最耗时的操作