文章目录
缓存雪崩：
双写一致性： 看业务需要：
强一致：redission读写锁可以允许短暂的数据不一致：延迟双删可以接受一定延时：canal、MQ
延时双删：先删除缓存再更新数据库，再延时删除缓存，一般不是要求强一致性基本采用的这种方式，虽然说在延时这部分时间内，还可能会读到脏数据：更新了数据库，这时还没同步到slave，但这时读了数据，读到的还是旧数据，并吧这个旧数据写到了缓存。
还可以采用Canal和MQ实现最终一致性：canal的话跟我们的代码更解耦。
RDB执行原理：执行bgsave非阻塞的这种方式，会fork一个子进程，将主进程的页表复制一份，由页表找到内存中的数据，然后写入RDB文件，fork采用的是copy-on-write，当此时主进程有写操作时，会拷贝一份数据执行写操作。
Redis数据淘汰策略：
红锁能解决分布式锁的主从一致性吗？ 不能，两位大佬的争论，红锁为了实现一致性损耗了性能，与AP思想冲突吧，要保证一致性，可以不使用红锁，只不过我们在代码中定义这种逻辑判断，避免有问题，或者选择CP的zookeeper。
zookeeper的分布式锁怎么实现的？ 基于临时的顺序节点和监听机制来实现的分布式锁，因为是顺序节点的方式，如果不是序号最小的节点的话，就会对前一个节点创建监听器，当它释放锁后就会通知自己。
redis哨兵模式脑裂问题：由于master与slave在不同的分区，master这里网络波动，使得sentinel心跳测试不成功了，那么sentinel执行故障转移，重新选出一个master，但是客户端还是对老的master进行操作，当网络恢复过来后，老的master成为新的master的slave，就会造成老的master中的数据的丢失。
解决脑裂
redis中的io模型：
精彩链接
您阅读本篇文章共花了：
发表评论