redis菜鸟教程学习笔记,redis入门教程超详细

1. QPS达到10万/秒
2. 用C语言实现
3. 基于内存
4. 单线程，不用线程上下文切换及加锁

1. String，常见的缓存，存储登录session等
2. hash，存储对象，单独修改对象属性
3. List，有序列表，可实现简单的消息队列，阻塞队列
4. Set，分布式去重
5. Zset，也叫做sorted set，有序集合，关联一个double类型的分数，根据分数排序，可实现排行榜、延时队列
6. Stream，redis 5.0后的新数据类型，消费者可分组，一条消息只能被同组的一个消费者消费，但可以被不同组的多个消费者重复消费，借此实现可持久化的发布&订阅功能

1. Cache Aside Pattern
2. 应用程序同时对接缓存、数据库
3. 查询时先查询缓存，缓存未命中则查询数据库，同时更新数据库
4. 更新时先更新数据库，在删除缓存缓存
5. 最常用的模式
6. 会有数据不一致性问题
7. 适用读多写少的场景
8. 两种加载缓存的方式，读到再加载，或者启动时就加载

1. 为什么是先更新数据库再删除缓存，而不是先删除缓存再更新数据库？
2. 为什么是更新数据库后删除缓存，而不是更新缓存？

1. Read/Write Through Pattern
2. 应用程序只对接缓存，由缓存对接数据库，相当于Cache Provider中封装了数据库
3. 查询时若缓存未命中则，则Cache Provider去查询数据库，设置到缓存后再返回
4. 更新时，由Cache Provider同时更新缓存和数据库，这里有事务保证
5. 此模式很耗时，但能保证数据一致性
6. 少见的模式

1. Write Behind
2. 应用程序只更新缓存，不直接更新数据库
3. 在一定时间触发异步的方式写入数据库
4. 类似于mysql InnoDB 缓冲池的模式
5. 在写入数据库前断电挂机会有丢失数据可能
6. 放大了数据不一致性，但速度很快
7. 适用于高并发写，但对数据一致性要求不高且允许丢失的场景

电商首页热点数据会做缓存，定时任务刷新，所有key失效时间一样。

热点key大面积集中失效，大量请求一下子打到数据库，导致数据库挂掉。

1. 失效时间加随机值，不让它们集中失效
2. 设置热点key永不过期，有更新时就更新缓存
3. 如果Redis是集群部署，可让热点key分布在不同的Redis库中

缓存和数据库中都不存在的数据，被攻击者利用，如id = -1，发起攻击的时候会绕过换过，不断查询数据库。

1. 对参数合法性进行检验
2. 使用布隆过滤器，会有一定误判
3. 数据库查询为null时，可以缓存约定的数据，如“请稍后重试”，缓存时间设置短点，如30秒（防止正常了这个id下有数据了也无法正常使用）
4. 限流

一个热点key，在失效的瞬间，遭遇高并发，大量请求在缓存中查不到，会直接去查数据库

1. 设置热点key永不过期
2. 使用分布式互斥锁，保证在缓存失效时，只有一个请求能查到数据库

数据一致性就是指数据库和缓存的数据一致的问题。

根据三种缓存模式可知，在数据一致性和效率是两个极端，只能取一个中间平衡点。

一般是采用旁路缓存模式，且采用先更新数据库，后删除缓存的方式。

但就这时候还是会有少量请求因为删除缓存不及时而读到旧数据，不过一般都能顺利删除缓存，这已经是对业务影响最轻的做法。

这时候如果允许短期的数据不?致不会影响业务，那么只要下次更新时可以成功，能保证最终?致性就可以，那么可以不用再做处理。

如果还要再完美，可以捕捉删除缓存异常增加重试，对耗时敏感的可以进行异步补偿重试，即放到mq里面监听，但是这样对业务侵入性比较大，也可以采用监听MySQL binlog日志的方式进行重试。

一个元素被加入到集合时，通过k个哈希函数将这个元素映射成一个位数组中的k个点，把它们设置为1。

检索时，看这些位置是不是为1就知道这个元素在不在集合中了，如果都是1则可能存在，如果有一个是0则一定不存在。

1. 存在误判的肯定，可通过建立白名单来存储误判的元素
2. 删除困难，初始化要把所有合法元素加到过滤器中，删除时设置为0可能会影响其他元素的判断，可通过Count Bloom Filter

1. 使用zookeeper分布式锁保证线程安全
2. 如果也要更新数据库，涉及到双写，就会出现数据一致性问题，可以参考上面的删除key
3. 如果不能删除key，则在更新缓存时比较数据的更新时间

1. 记录内存快照的方式
2. 使用bgsave，fork一个子进程进行，不会阻塞set操作，类似于GC的守护进行
3. Copy On Write，写时复制机制，备份的时候发生写入操作，则备份的是写入之前的数据，所以会有数据丢失
4. 定期进行，一般是5分钟一次，断电可能会丢失较多数据
5. 恢复块、备份久
6. 可能把RDB快照文件定期放到远程存储，一般做冷备
7. RDB备份的文件体积小，恢复很快

1. 日志追加的方式，类似于MySQL innoDB引擎中redo.log，备份当前操作命令
2. 恢复慢、备份块
3. 会不会丢失数据取决于appendfsync配置，配置为实时备份则每次写操作都会备份，性能低，一般是配置为每秒一次，这样最多是丢失一秒的数据
4. 适合做灾备
5. 随着时间增长，AOF文件会越来越大，Redis提供了日志重写功能，可以压缩命令，重写后新的AOF文件仅包含旧AOF文件命令的最小集合
6. AOF备份的文件体积大，即使经过重写，仍然很大，恢复很慢

Redis 4.0后使用了RDB AOF混合持久化模式，生成RDB文件重新记录，这时AOF日志不再是全量的，而是增量的日志记录，体积很小。

Redis需要删除失效的数据以清空内存，过期策略就是怎么删除过期数据。

1. 定期删除：默认每隔100ms随机抽取部门设置了过期时间的key，检查key是否失效，失效了就删除。（不全部检查是因为效率低，类似于MySQL全表扫描）
2. 惰性删除：当应用程序来查key的时候，检查到key失效就会删除，未失效就返回。

Redis使用定期删除 惰性删除，能保证最终一定会删除过期的key，但是定期删除会有漏网之鱼，而应用程序又很久没来查询就会导致长时间滞留在内存之中，这时需要用到内存淘汰机制。

FIFO：First In First Out，先进先出

LRU：Least Recently Used，最近最少使用，从时间上看很久没有使用的被淘汰

LFU：Least Frequently Used，最不经常使用，从次数上看使用得最少的被淘汰

1. volatile-lru：将设定了超时时间的数据，采用LRU算法将数据提前删除
2. allkeys-lru：对所有的数据采用LRU算法进行删除
3. volatile-lfu：设定超时时间的数据采用LFU算法删除
4. allkeys-lfu：对所有数据采用LFU算法删除
5. volatile-random：设定了超时时间的数据随机删除
6. allkeys-random：所有数据随机删除
7. volatile-ttl：设定了超时时间的数据根据剩余时间少的删除数据
8. noeviction：不删除内存数据，如果内存溢出报错返回（默认策略）

全量同步主要发生在Slave初始化阶段，当启动一台Slave时，它需要连接到Master，把Master数据都复制一份。

1. Slave连接上Master，发送sync命令给到Master。
2. Master执行bgsave，按照全量备份方式生成一份RDB快照，并用内存缓冲区记录此后执行的所有写命令。
3. Master向Slave发送RDB快照。
4. Slave收到RDB文件后，丢弃所有旧数据，并载入收到的快照文件。
5. Master发送完RDB快照就接着发缓冲区中的写命令。
6. Slave载入完RDB快照，就开始接收&执行Master发送过来的写命令。

Master每执行一个写命令就会向Slave发送相同的写命令，Slave接收&执行收到的写命令。

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。redis策略是，无论如何，首先会尝试进行增量同步，如不成功，再要求从机进行全量同步。

主从复制，只是实现了容灾备份，不能故障转移，不是实现高可用。