简洁大气的网站模板查法人信息的网站
Redis八股
上两种都有可能导致脏数据
所以使用两次删除缓存的技术，延时是因为数据库有主从问题需要更新，无法达到完全的强一致性，只能达到控制一致性。
一般放入缓存中的数据都是读多写少的数据
业务逻辑代码👇
写锁👇
读写锁的方法确实可以达成强一致性，但是效率太低了。
👆默认一般使用everysec
RDB如果两次备份之间宕机了，会丢失数据
多端部署无法限制线程的互斥👆
👆EX 过期时间还是需要设定的，因为如果突然宕机了，锁设定了时间会按时间释放，不设定则无法释放会造成死锁。
同一个线程可重入锁！！！👆
👆主机宕机了后，一个从属机器变成了主机器，再次为新线程分配锁，造成了两个线程持有一把锁，无法保证主从的一致性
👆红锁可以保证主从数据的一致性。但是低效
一般业务中redis不能保证数据的强一致性，如果想保证强一致性可以使用zookeeper
👆当master down了之后哨兵选代替主节点(master)的过程
👇脑裂是因为哨兵监听主节点的时候网络不畅，又在可控范围选择了新的master节点，当网络通常后，清空了master(原)，让其成为slave，导致这段时间写在master里的数据被清空。
👆这个是解决脑裂的方法，write最少一个salve点，lag延迟不能超过5秒，这些不满足就拒绝客户端的请求，减少数据的进一步丢失。(不是很懂其中逻辑)
👆每个master保存不同的数据，彼此检测online状况(类似哨兵！)，访问任意一个master就可以获得其他master的数据（master之间有路由）。
👇有效实例就是master节点
等待数据就绪和读取时间浪费了很多时间。👆
👆IO是最耗时的操作
