1.redis用途
数据缓存，特别是热点数据，减少数据库压力
手机验证码，失效时间来设置验证码的过期时间；
分布式锁，seNX+expire来设置，value设置uuid，unlock时要判断value值必须是自己线程设置的才可解锁，保证只有当前线程才可以解锁
计数器，INCR,DECR，单线程能保证线程安全
分布式队列，通过redis的list能保证队列的线程安全
排行榜，通过sorted set实现
限流，只能做最简单的限流，不平滑
附近的人，地址位置，通过GEO实现
共同好友，集合的交集，并集等操作
签到，使用位图实现，节省内存空间
UV，通过HyperLogLog实现，但是会存在部分误差，适用于对数量精确性不敏感的场景
位图功能实现签到，统计一年登录次数，在线用户数等，节约空间
2.缓存挂掉，穿透，击穿，雪崩
缓存挂掉：
1.redis哨兵或者集群模式保证缓存不会挂掉；
2.增加本地缓存和限流，避免缓存挂掉全部走数据库；
3.缓存恢复后通过持久化方案恢复数据
雪崩：
多个缓存同时失效，导致大量的请求会去查询数据库，导致数据库压力暴增
解决方案：
1.超时时间不要设置相同，过期时间加上个随机值，避免同时失效；
2.设置热点数据永不过期；
击穿：
热点数据的失效，导致顺时大量请求访问数据库，将数据库宕机，进而导致整个系统的崩溃，和雪崩不同的是，它是单个数据的顺时失效，雪崩是多个
解决方案：
1.热点数据设置永不过期
2.加互斥锁
互斥锁
使用互斥锁不能精确到key维度，可以通过分布式锁或者本地缓存来解决问题
穿透：
请求数据库中不存在的记录，会导致每次都无法命中缓存，每次都要去数据库获取
解决方案：
1.对于不存在的记录，缓存中设置一个空值；
2.使用布隆过滤器
3.redis缓存失效
3.1 过期删除策略：
定时扫描
首先将每个设置了过期时间的key放到一个独立的hash中，默认每秒定时遍历这个hash而不是整个空间：
并不会遍历所有的key，采用一种简单的贪心策略
1、从过期key字典中，随机找20个key。
2、删除20个key中过期的key
3、如果2中过期的key超过1/4，则重复第一步
4、每次处理的时间都不会25ms
如果有大量的key在同一时间段内过期，就会造成数据库的集中访问，就是缓存雪崩！
惰性策略
客户端访问的时候，会对这个key的过期时间进行检查，如果过期了就立即删除。惰性策略是对定时策略的补充，因为定时策略不会删除所有过期的key
3.2 内存淘汰机制
当内存不够时，触发内存淘汰机制，主要有：
1.不删除，内存不足直接报错
2.所有key:随机删除
3.所有key:删除最近最少使用
4.设置失效时间的key:随机删除
5.设置失效时间的key:删除最近最少使用
6.设置失效时间的key:优先删除剩余时间短的key
4.redis速度快原因
1.纯内存操作，内存处理速度远远大于磁盘
2.采用异步阻塞reactor模型
3.单线程，减少了线程切换和阻塞的消耗
5.redis数据类型和底层实现
string
如果value可以转化成long，使用数值存储
字符串<=44,使用embstr, redisObject和sds连续，分配一次
字符串>44，使用raw，redisObject和sds不连续，分配两次
例子：
字符串
list
底层结构:quicklist，quickList 是 zipList 和 linkedList 的混合体，它将 linkedList 按段切分，每一段使用 zipList 来紧凑存储，多个 zipList 之间使用双向指针串接起来。
// 快速列表
struct quicklist {
quicklistNode* head;
quicklistNode* tail;
long count; // 元素总数
int nodes; // ziplist 节点的个数
int compressDepth; // LZF 算法压缩深度
...
}
// 快速列表节点
struct quicklistNode {
quicklistNode* prev;
quicklistNode* next;
ziplist* zl; // 指向压缩列表
int32 size; // ziplist 的字节总数
int16 count; // ziplist 中的元素数量
int2 encoding; // 存储形式 2bit，原生字节数组还是 LZF 压缩存储
...
}
struct ziplist_compressed {
int32 size;
byte[] compressed_data;
}
struct ziplist {
...
}
例子:
hash
底层结构：ziplist或者dict(字典)
和上面列表对象使用 ziplist 编码一样，当同时满足下面两个条件时，使用ziplist（压缩列表）编码：
1、列表保存元素个数小于512个
2、每个元素长度小于64字节
不能满足这两个条件的时候使用 hashtable 编码。第一个条件可以通过配置文件中的 set-max-intset-entries 进行修改
例子:
set
底层结构：intset(数值集合)或者dict(字典)
如果集合中元素都可转为long，则用intset，不能转则用dict
例子：
sortset
底层结构：ziplist和skiplist
为什么需要跳表而不是红黑树？
跳表实现简单，维护性好，对于范围查询时，跳表速度较好，而sortset有范围查询的场景，其他方面跳表性能比红黑树差。
6.LRU实现方式
思想：利用一个链表来实现，每次新插入数据的时候将新数据插到链表的头部；每次缓存命中（即数据被访问），则将数据移到链表头部；那么当链表满的时候，就将链表尾部的数据丢弃
// 继承LinkedHashMap
public class LRUCache<K, V> extends LinkedHashMap<K, V> {
private final int MAX_CACHE_SIZE;
public LRUCache(int cacheSize) {
// 使用构造方法 public LinkedHashMap(int initialCapacity, float loadFactor, boolean accessOrder)
// initialCapacity、loadFactor都不重要
// accessOrder要设置为true，按访问排序
super((int) Math.ceil(cacheSize / 0.75) + 1, 0.75f, true);
MAX_CACHE_SIZE = cacheSize;
}
@Override
protected boolean removeEldestEntry(Map.Entry eldest) {
// 超过阈值时返回true，进行LRU淘汰
return size() > MAX_CACHE_SIZE;
}
}
7.redis分布式锁实现
SET key value EX 10086 NX
将setnx和expire结合在一个指令中，保证原子性
执行完后执行del删除key
但是会有问题：假设A线程执行，这时候拿到锁，执行时间很长，导致锁的时间过期了，这时候B线程也能拿到锁，然后执行代码，未执行完锁代码块，这时候A线程执行完执行了删除逻辑，这样会导致另外的线程又能拿到锁。为了解决这样的漏洞，一般会对value值做限制，可以用uuid生成value，在删除时校验redis的value值必须是该线程生成的，会避免上述说的问题。一般使用LUA脚本：
if redis.call('get', KEYS[1]) == ARGV[1]
then
return redis.call('del', KEYS[1])
else
return 0
end
参考文章：
https://www.cnblogs.com/ysocean/p/9102811.html
https://blog.csdn.net/lusic01/article/details/92001898
https://blog.csdn.net/elricboa/article/details/78847305
网友评论