Redis 的 key 的设置规范

1. redis 的 key 要求全大写，命令规范是 系统前缀 : 业务标识，其中系统前缀为，领域缩写_系统简称_子系统名，业务标识为，下划线分隔的业务特征字符串，要求在保证可读性的前提下，key 的长度尽可能短，value 小于10K；

缓存雪崩，击穿和穿透

1. 缓存雪崩是指，大量 key 同时失效，导致请求都进入存储层，给存储层造成压力，甚至宕机；

2. 缓存雪崩的解决方案是，设置 key 失效时间时添加一个随机值；

3. 缓存击穿是指，非常热点的 key 失效，导致大量请求都进入存储层来重建缓存，给存储层造成压力；

4. 缓存击穿的解决方案是，在同步代码块中重建缓存，保证 key 失效后，只有一个线程请求到数据库来重建缓存，或者设置 key 为不失效，依赖定时任务去刷新缓存；

5. 缓存穿透是指，大量请求访问缓存和数据库不存在的结果，导致每次请求都到达存储层，给存储层造成压力；

6. 缓存穿透的解决方案，一种是将数据库查询为 null 也存放到缓存中，如果出现大量查询 null 的请求，可能会占满缓存，导致有用缓存被淘汰，另一种方案，是在缓存和数据库之间加入一个布隆过滤器，过滤掉数据库不存在的请求，减少数据库压力；

		redis 4.0 之后就引入了布隆过滤器，通过 bf.add，bf.exists 来使用更多参考：https://www.zhihu.com/search?type=content&q=redis%20%E6%95%96%E4%B8%99

布隆过滤器

1. 类似 HashMap 的结构，底层是数组，数组元素是 bit，put 元素时，将元素值经过多次哈希，得到多个数组下标值，将这些数组下标值都设置为 1，这样判断元素是否存在时，只需要同样多次哈希，判断各个下标元素的与运算是否是 1；

2. 布隆过滤器，使用多次哈希，是为降低哈希冲突的概率，不同的元素，多次哈希得到的下标都相同的概率，比只一次哈希相同的概率要低，构造布隆过滤器时，参数有数据类型，插入值的个数和期望的误判率（默认是3%），误判率和存储空间，查找时间相关；

3. 布隆过滤器用于检索元素是否在海量集合中，优点是节省空间，查找效率高，但有一定的误判率和删除比较困难，集合中存在的元素，一定返回存在，集合中不存在的元素，可能因为与其他元素哈希冲突，会返回存在；

4. 在缓存击穿上的应用，将数据库表中的主键或唯一字段，放入布隆过滤器中，每次请求在缓存查找不存在时，首先在布隆过滤器中判断是否存在，如果存在才向数据库发送请求，否则直接返回结果不存在；

5. 布隆过滤器还可以用在垃圾邮箱过滤等海量数据查重的场景上；

Redis 构造分布式锁

1. 加锁，setnx(key, value)，只有 key 不存在才能设置成功，且是原子操作，所以只有一个线程能设置成功，表示加锁成功，通常加锁给 key 设置一个过期时间，来保证锁能被释放，不会因为业务节点问题，导致死锁；

2. 释放锁，删除掉 key 即可，del key；

3. 如何解决过期时间到了，但是同步操作还未执行完，还想继续持有锁的问题，通过加锁线程，同时启动一个守护线程，每间隔一定时间检查下，如果仍持有锁，就延长 key 的过期时间，这样能保证同步操作未完成，能继续持有锁，并且不会无限延期，因为锁释放，会显示关闭守护线程，节点宕机，守护线程也会自动终止；

4. 如果要实现可重入锁，在设置 value 的时候，将加锁的线程的唯一 id 放入，这样下次加锁判断一下节点 id 是否是自身，来决定是否加锁成功，

5. 真实生产应用场景，通常使用 Redisson 的开源框架来实现，并且 zookeeper 来实现分布式锁更容易；

	更多参考：https://cloud.tencent.com/developer/article/1349732https://blog.csdn.net/belongtocode/article/details/102511520

Redis 队列

1. redis 队列，使用 list 结构，生产者 rpush，消费者 lpop，可使用 blpop 来阻塞获取消息，如果要实现 1：N 的广播，可以使用 pub/sub 的订阅模式，这种模式当没有消费者时，消息会丢失，如果要保证消息不丢失，需要使用其他专业 mq；

2. 构造延迟队列，sortedset 结构，生产者 zadd myqueue score value 时，value 为消息内容，score 为时间戳，消费者通过 zrangebyscore 来获取 N 秒之前的消息，比如消息延时 20s 后可以被消费，那么生产者 zadd，score 为当前时间戳，而消费者每次获取消息通过 zrangebyscore myqueue 0 当前时间-20s 来获取消息，就只会获取 20s 之前生产的消息，起到延迟消费的作用；

Redis 持久化

1. 有 RDB 和 AOF 两种方式，RDB 是全量持久化，持久化 redis 的全量数据，单次耗时时间长，AOF 是增量持久化，只持久化操作命令，单次耗时时间短；

2. 每次 RDB，客户端会暂停几毫秒到几秒的时间，且两次 RDB 之间，如果发生 Redis 重启，会丢失该时间间隔的操作数据；

3. AOF 可以设置为按照时间间隔进行持久化，或者每次执行命令都进行持久化，前者可能发生数据丢失，后者不会丢失数据，但影响性能，并且 AOF 会定期重写，来压缩命令空间，如果有误操作，需要立即关闭重写，删除 aof 中的命令，然后通过 rdb 恢复备份，从备份时间点来重放 AOF 来恢复数据；

4. 通常两者结合使用，RDB 间隔时间长，进行全量备份，而 AOF 设置为 1s 进行一次备份，这样最多只丢失 2s 的数据；

Redis 主从同步，从从同步

1. 触发同步时，主节点执行一次 bgsave，生成 rdb 备份，这个过程中主节点接收的操作，都在内存 buffer 中记录，等待 rdb 备份被发送到从节点，从节点加载完数据后，主节点再将内存 buffer 的操作发送到从节点；

2. 之后，主从节点依赖通过 AOF 日志，进行同步；

Redis 的内存淘汰机制

1. 定期删除，redis 如果设置了 key 的过期时间，并不是到期马上删除，而是 redis 会将所有有过期时间的 key 集中存放，然后每隔一段时间（默认100ms)，随机选择 20 个 key，判断是否过期，来进行删除，并且如果需要删除的 key 比例超过 1/4，会重复选择删除的过程；

2. 惰性删除，是当应用主动获取某个 key 时，redis 会判断是否过期，如果过期，直接删除，不返回给应用；

3. 内存淘汰策略，是指当 redis 所占内存超过设置值时，redis 需要对内存中的一些 key 进行淘汰；

	noeviction：不淘汰任何key，返回错误allkeys-lru：针对所有 key，通过 LRU 算法淘汰最久没有使用的 keyvolatile-lru：针对有过期时间的 key，通过 LRU 算法淘汰最久没有使用的 keyallkeys-random：针对所有 key，随机删除volatile-random：针对有过期时间的 key，随机删除volatile-ttl：针对有过期时间的 key，删除马上要过期的 keyvolatile-lfu：针对有过期时间的 key，删除使用频率最少的 keyallkeys-lfu：针对所有 key，删除使用频率最少的 key