Redis篇-01-redis开篇_哔哩哔哩_bilibili
预热：redis类型使用场景
Redis八种数据类型及应用场景介绍_redis中数据类型的应用场景-CSDN博客
我知道的：Stream类型用来做消息队列（黑马点评）
BitMap可以做布隆过滤器（缓存穿透那里用到）
Redis高级特性(一)-Bitmaps与布隆过滤器_bitmaps 与 布隆过滤器-CSDN博客
HashMap做Redisson锁可重入计数（分布式锁）
String的递增做订单号生成（保证唯一性同时也能根据传入的key统计）
1.缓存穿透
2.缓存击穿
逻辑过期里的互斥锁是为了保证只有一个线程去缓存重建
3.缓存雪崩
4.双写一致性
4.1要求一致性（延迟双删/互斥锁）
延迟双删无法保证强一致性
那么前两步删缓和更新数据库哪个先呢？都有问题
双删是为了保证再次删除旧的缓存（上图的两种情况旧缓存）
延迟是因为保证db的主从同步，如果提前删除，那么有查询过来到数据库从节点，里面还没同步，那么查到了旧数据，还把旧数据写到缓存里，等于白删了。
后删虽然无法保证DB主从同步期间查询的有效性，但是能保证删除之后，再查询一定是新数据。
延迟双删无法保证强一致性
互斥锁能够保证强一致性，但是效率低--->用读写锁
4.2要求高可用，最终一致性（异步通知）
5.redis持久化 RDB + AOF
aof只记录写命令，不记录读命令。
bgwrite会屏蔽连续的修改，只记录同一个记录的最后一次修改
aof自动记录频率
6.redis 的key过期策略（过期删除）
7.redis 的key淘汰策略（内存满了删除）
8.分布式锁
Redis篇-10-redis分布式锁-实现原理（setnx、redisson）_哔哩哔哩_bilibili
redisson重入重试看门狗
9.分布式锁主从一致性-->红锁RedLock
主节点加锁宕机，从节点变主节点但是锁没来得及更新过来，那么其他线程可以获取锁。
但是红锁一般不用，性能不好又复杂。
redis一般保证高可用性和最终一致性，不怎么用红锁，因为服务器宕机是小概率
如果要保证强一致，用zookeeper。
10.redis集群方案（主从、哨兵、分片)
10.1主从模式（高并发）
redis主从如何同步（全量同步，增量同步）
10.2哨兵模式（高可用）
10.2.1脑裂
主节点和从节点断联，仍然接收到客户端数据。但哨兵选出了新的主节点，老主节点降成从节点并被主从复制，那么这段时间的操作会丢失。
意思就是你主节点和从节点的联系有问题，那你就别写入
10.2.2单redis读（10万）写（8万）并发能力
10.3分片集群
11.redis为什么快
11.1 I/O多路复用
11.2 阻塞I/O
11.3非阻塞I/O
11.4 多路复用I/O
多路复用IO会用一个select去轮询监听一个socket集合，一个socket能代表一个需要拷贝的数据，在第一阶段谁先就绪就谁来，可以看成并行，先来先服务，第二阶段循环调用recvfrom去处理各个socket。
而阻塞IO和非阻塞IO每个数据都有顺序（串行），即使别的数据好了只要当前没有数据也会死等这一个数据。导致效率低。
11.5Redis网络模型
redis速度主要受网络IO影响，所以易受影响的部分加了多线程升级，但是最终命令执行还是串行的。
