Redis总结
2023-09-11 08:51:23 1 举报AI智能生成
为你推荐
查看更多
Redis史上最全总结
作者其他创作
大纲/内容
优点：读写性能高
内存存储
优点：天然原子性，没有并发安全问题
读写单线程
key 只能是String类型
set key value
get key value
具有独占的特点（可以用于实现分布式锁）
setnx key value
设置一个key自增1（可以作为分布式数据id使用）
incr key
设置一个key自增 incrnum个长度（incrnum 可正可负）
incrby key incrnum
常用命令
对应JAVA中的String
String
添加一个key的 map数据 ，feild 是map的 key 值是value
hset key feild value
hget key feild
获取一个key的 所有map数据
hgetall key
删除一个key的 map数据
hdel key feild
对应JAVA 中的 Map
Hash
从左边依次添加键为key，值为val1 val2 的list结构数据。值可重复。列出时，先添加的元素，后列出
lpush key val1 val2 ...
从右边依次添加键为key，同上 lpush
rpush key val1 val2 ...
取出左边第一个元素，取出后元素从队列删除
lpop key
取出右边.... 同上 lpop
rpop key
列出键对应的元素，从start索引开始，到end索引结束。如果end为-1表示到倒数第一个结束。不删除元素
lrange key start end
列出指定键为key的值中指定索引的元素。index为指定的索引号。不删除元素
lindex key index
对应JAVA中的List
List
sadd key val1 vla2
列出这个key的所有元素
smembers key
判断集合中是否有这个val元素
sismember key val
列出key1和key2中共同存在的元素 （交集）
sinter key1 key2
列出key1和key2中所有不重复的元素（并集）
sunion key1 key2
列出key1中有，key2中没有的元素（差集）
sdiff key1 key2
对应JAVA的Set
Set
向key中添加一个元素，元素绑定一个score分数值。列出数据时，会根据这个绑定分数值进行排序
zadd key score member
列出索引从start开始到end结束的元素，并且展示元素对应的分数值(升序)
zrange key start end withscores
列出索引从start开始到end结束的元素，并且展示元素对应的分数值（降序）
zrevrange key start end withscores
对应JAVA中的TreeSet
ZSet
value有五大数据类型
key-value的存储结构
特点
del key
列出匹配指定模式的键
keys pattern
查看key的存活时间 -1永久存活 -2过期
ttl key
设置key的存活时间
expire key senconds
查看key的类型
type key
从下标0开始查询两个，key中以user开头的value
scan 0 match user* count 2
key通用命令(常用)
setbit key offset value
getbit key offset
bitcount key start end
命令
2亿个数据才25mb
位图数组，只要是这个事件只有两种情况的都可用这个来记录
设置id为5000000的用户为登录状态
setbit loginstatus 5000000 1
获取id为5000000的用户的登录状态
getbit loginstatus 5000000
统计所有登录的用户人数
bitcount loginstatus 0 -1
示例
它是按字节来存的，一个字节是由8个bit位也就是8个0或1，这样一个字节就能存8个用户的状态了
原理
使用位图数组来记录
记录大量用户的登录状态
工作机制：日志快照(拍摄照片)，每一次记录都是当前这一时刻的全量数据
所占用的内存小
数据恢复快
优点
每次记录所需要的时间长
记录间隔长（一旦数据发生丢失，丢失的数据多）
缺点
优缺点
原因：redis读写单线程
数据量非常大的情况下，容易造成redis宕机
这个是前台保存，相当于把这个操作加紧读写操作中
save
bgsave
在redis.conf中配置自动保存
保存方式
这两个都是后台持久化，通过linux的fork函数开辟一条子线程，进行持久化数据
RDB
工作机制：日志记录(录视频)：对所有的操作都进行记录，是一种增量式的记录
每次记录所需要德时间短
记录间隔短（一旦发生数据丢失，丢失的较少）
执行bgrewriteaof（对AOF文件进行重写）去除掉一些无关的指令
重写后，AOF的扩充比例（在基数基础上，达到增长比例后触发重写）
auto-aof-rewrite-percentage 100
文件达到指定大小才会触发重写
auto-aof-rewrite-min-size 64mb
指令
或者在redis.conf配置自动重写
针对这个情况的解决方案
所占用的内存较多
数据恢复慢
AOF
如果追去恢复效率，对数据安全要求不高，使用RDB
如果不追求恢复效率，对数据安全要求高，选择AOF
开启方式在redis.conf中配置aof-use-rdb-preamble yes
在redis 4.0中默认就是混合持久化
如果对两个都有要求，那么久混合使用
方案
持久化
三高：高并发、高性能、高可用
优点：架构简单
缺点：一旦主机宕机，则整集群不能对外提供写能力，只能提供读能力
主从架构
优点；可以防止主机宕机后，不能对外提供写能力
缺点：不能支持高并发的写操作；增加经济成本
哨兵集群
过半机制，必须要有超过一半的哨兵推选，才能成为主机
过半机制的好处： 防止脑裂
缺点：一旦哨兵集群由于某些原因，不能推选主机，就会使整个集群出现问题
哨兵集群的选举
优点：支持高并发的写操作；也有哨兵集群的优点
缺点：读写操作都在主机上；从机只负责数据备份
有16384个槽位，在插入数据时，会对key进行hash运算，在对16384取模，得到对应的槽位，然后插入到对应的主机
槽位分配，可以手动配置。不然在集群启动时，会自动分配。
一旦某个集群全部宕机了，它的槽位不会自动重新分配到其它集群上
cluster集群
主机将数据的rdb文件通过socket通信的方式发送到从机，从机进行同步，在这之前从机会先删除老的数据
全量复制
当从机再次连接上主机时，从机将当前的数据偏移量发送给主机，主机回去缓存中看，这个偏移量是否是在缓存中，如果在就直接把缓存中的数据发送给从机，如果不在就进行全量复制。
增量复制
数据同步方式
高可用
集群数量最小是3，而且都是奇数，主要是为了经济成本
redis中未使用
定时删除
当一个可以设置过期时间后，会将这key放到过期字典中。然后redis中会有一条线程，去扫描这个过期字典。抽取出W个key进行检测。如果发现这些key有超过0.25的都过期了，那么就会继续扫描再删除。
定期删除
有一个key过期了，但是没有做定期删除和定时删除，等下次访问时删除
惰性删除
删除策略
删除key2（时间局部概念）相对于key1 10点使用一次，key2的9:59 使用就是最近最少使用的
LRU（最近最少使用）
删除key1（全局）key1总使用2次 key2总是用3次
LFU（最少使用）
举例：key1 9:30、10::00使用；key2 9:40、9:45、9:59使用
LRU与LFU解释
volatile-lru
volatile-lfu
随机删除一个
volatile-random
移除即将过期的
volatile-ttl
过期字典的淘汰策略
allkeys-lru
allkeys-lfu
allkeys-random
全局的淘汰策略
淘汰策略
产生原因：大量访问数据库中不存在的数据
会浪费内存，如果内存满了，就会触发淘汰策略
缓存空对象
相当于一个位图数组，利用桶排序的思想，在Spring的所有bean都初始化完成后，把数据库总的数据查询出来，把数据库中的数据所对应的主键，当做位图数组的下标，把对应的位图数组的值从0变为1
初始的位置：在所有bean都初始化完成后进行
实现方式：实现ApplicationListener<ContextRefreshedEvent>接口，重写方法onApplicationEvent(ContextRefreshedEvent event)
Spring监听器
SpringBoot监听器
实现方法：监听器
布隆过滤器
解决方案
缓存穿透
产生原因：刚好大量请求过来访问一个key，但是刚好这个key过期了，造成请求直接到达数据库上了。
对热点数据设置永不过期
不可重入
1、使用redis的setnx来做分布式锁
它是可重入的，内部使用的是redis的hash结构来做的
为了保证原子操作，使用lun脚本来执行的
2、使用Redisson的锁
使用分布式锁
记得要二次判断缓存
基于服务保护做一些限流操作
解决方案：
缓存击穿
产生原因：同一时间大量访问不同的key，恰好这些key又在这一时间，同时过期
设置key的过期时间分布随机的，防止同时间过期
热点数据永不过期
缓存雪崩
缓存问题
1、可以使用Redis的setnx来做（不可重入锁）
2、使用Redisson的分布式锁（可重入锁）
解决方案：Redisson的 红锁（RedLock）
红锁的工作机制：加锁时，是向集群中所有的master发起加锁申请，只有超过半数认为加锁成功，最后才是加锁成功
为了防止主从数据同步导致的加锁失败
Redis分布式锁
有多窗口就是说有多个进程同时买票，就是同时抢锁，一旦一个抢到锁后其它的就在那里自旋等待（使用while(true)）
1、一个抢到锁的进程突然宕机了，锁没来得及释放（死锁）
1的解决方案：给锁添加一个过期时间，到时间自动释放锁
2、但是解决完1的问题会衍生出来一个问题，就是这个进程并不是宕机了，它只是处理业务的时间大于你所设置的过期时间了，这就会导致加锁失败
解决方案：看门狗机制（watch Dog） 开启一条子线程，来进行检测这个锁的过期时间，如果快过期了，但是进程并没有宕机，那就对它进行续时操作
这会有两个问题
特性：主进程结束，它也就结束了
守护进程
刚开始是默认是给这个锁添加30s的过期时间，每隔10s 这个线程就会检查一下，看这个锁的过期时间是不是小于原来设置过期时间的1/3，如果是就进行续时操作，一直到主线程结束，释放锁
Redisson中是 定时器
watch Dog的实现方式
举个例子：买票
zoopeeker分布式锁
分布式锁
产生原因：数据库中的数据反生改变时，怎样保证redis中的数据也发生改变
如果需要保持数据的强一致性：加读写锁
如果不需要，就可以正常执行
双写一致性
读写单线程，不需要CPU切换
多路复用，提高并发能力1
Redis为啥快
Redis
0 条评论
回复 删除
下一页
