Redis小而巧的数据库真的很实用,掌握了用起来很舒服

743 篇文章 3 订阅
742 篇文章 2 订阅

Redis是一款开源的基于内存存储的Key-Value模型的No-SQL类型数据库
数据类型:key-String、key-List、key-Set、SortSet、key-Hash、Geo、Bit、Hyper
常用的客户端:1.Jedis 2.Redisson 3.SpringData Redis
Redis底层数据结构:
String类型:SDS(动态字符串,空间预分配、惰性空间释放)
组成:free区域-剩余空间,len区域-长度,buf存放字符数组
ziplist(压缩列表,连锁更新),底层存储键值对的核心技术,节约内存,连续的区域,避免内存碎片
Hash(拉链法),扩容和收缩
Skiplist(跳表),双链式,header:头,tail尾,level层数,length长度,实现快速访问-SortSet
RESP协议:Redis序列化协议,自定义客户端需要使用
现象
击穿:
高并发下,同时访问某个key,可是Key失效了,导致大量的请求落到了数据库上,导致数据库崩溃。
高并发,单Key,失效
解决:1.热点key设置永久有效 2.互斥锁MutexKey 3.同步+双锁检查
穿透:
高并发下,大量访问不存在的Key,导致请求落到了数据库上,从而数据库宕机
解决:1.布隆过滤器(Redisson-封装或者谷歌Gauva(布隆过滤器))Bitmap类型,容错率-哈希函数-误判率
雪崩:
高并发下,大量访问很多key,可是,这些key都失效了,导致请求落到了数据库上
解决:1.设置不同的有效期(有效期+随机时间)2.多重缓存机制 3.锁
倾斜:
集群下,高并发,大量请求某个key,结果都被分配到了固定某台的服务器上,导致这台服务器压力过大
解决:1.采用去中心化
2.从设计的角度去尽可能排除(避免大集合、不适应影响性能的命令:keys、monitor、功能单一,拆解大key)
Redis过期策略
key的生存时间到了,Redis会立即删除吗?不会立即删除。 过期策略:
●定时删除:在设置key的过期时间的同时,为该key创建一个定时器,让定时器在key的过期时间来临时,对key进行删除
●定期删除:Redis每隔一段时间就去会去查看Redis设置了过期时间的key,会再100ms的间隔中默认查看3个key。
●惰性删除:
key过期的时候不删除,每次通过key获取值的时候去检查是否过期,若过期,则删除,返回null(用的时候再检查删除)
当去查询一个已经过了生存时间的key时,Redis会先查看当前key的生存时间是否已经到了,是则直接删除当前key,并且给用户返回一个空值。
Redis采用的过期策略:惰性删除+定期删除
惰性删除流程:在进行get或setnx等操作时,先检查key是否过期,若过期,删除key,然后执行相应操作;若没过期,直接执行相应操作
定期删除流程:遍历每个数据库,检查当前库中的指定个数个key(默认是每个库检查20个key,注意相当于该循环执行20次,循环体时下边的描述)
如果当前库中没有一个key设置了过期时间,直接执行下一个库的遍历。
随机获取一个设置了过期时间的key,检查该key是否过期,如果过期,删除key。
判断定期删除操作是否已经达到指定时长,若已经达到,直接退出定期删除。
Redis的淘汰机制
在Redis内存已经满的时候,添加了一个新的数据,执行淘汰机制。
volatile-lru:在内存不足时,Redis会在设置过了生存时间的key中干掉一个最近最少使用的key。
allkeys-lru:在内存不足时,Redis会在全部的key中干掉一个最近最少使用的key。
volatile-lfu:在内存不足时,Redis会在设置过了生存时间的key中干掉一个最近最少频次使用的key。
allkeys-lfu:在内存不足时,Redis会在全部的key中干掉一个最近最少频次使用的key。
volatile-random:在内存不足时,Redis会在设置过了生存时间的key中随机干掉一个。
allkeys-random:在内存不足时,Redis会在全部的key中随机干掉一个。
volatile-ttl:在内存不足时,Redis会在设置过了生存时间的key中干掉一个剩余生存时间最少的key。
noeviction:(默认)在内存不足时,直接报错。
指定淘汰机制的方式:maxmemory-policy 具体策略,设置Redis的最大内存:maxmemory 字节大小
Redis持久化
Redis提供2种方式实现持久化:1.RDB 2.AOF
RDB
RDB是Redis默认的持久化机制
RDB持久化文件,速度比较快,而且存储的是一个二进制的文件,传输起来很方便。
RDB持久化的时机:
save 900 1:在900秒内,有1个key改变了,就执行RDB持久化。
save 300 10:在300秒内,有10个key改变了,就执行RDB持久化。
save 60 10000:在60秒内,有10000个key改变了,就执行RDB持久化。
RDB无法保证数据的绝对安全。
RDB存储的是数据,时间间隔无法实时持久化
AOF
AOF持久化机制默认是关闭的,Redis官方推荐同时开启RDB和AOF持久化,更安全,避免数据丢失。
AOF持久化的速度,相对RDB较慢的,存储的是一个文本文件,到了后期文件会比较大,传输困难。
AOF持久化时机:
appendfsync always:每执行一个写操作,立即持久化到AOF文件中,性能比较低。
appendfsync everysec:每秒执行一次持久化。
appendfsync no:会根据你的操作系统不同,环境的不同,在一定时间内执行一次持久化。
AOF相对RDB更安全,推荐同时开启AOF和RDB。
AOF存储的是命令(更改数据的命令),可以实时持久化
同时开启RDB和AOF的注意事项:
1.如果同时开启了AOF和RDB持久化,那么在Redis宕机重启之后,需要加载一个持久化文件,优先选择AOF文件。
2.如果先开启了RDB,再次开启AOF,如果RDB执行了持久化,那么RDB文件中的内容会被AOF覆盖掉。
Redis事务
Redis的事务:一次性、顺序性、排他性的执行一个队列中的一系列命令。
Redis 事务的本质是一组命令的集合。事务支持一次执行多个命令,一个事务中所有命令都会被序列化。在事务执行过程,会按照顺序串行化执行队列中的命令,其他客户端提交的命令请求不会插入到事务执行命令序列中。
可以理解为一个打包的批量执行脚本,但批量指令并非原子化的操作,中间某条指令的失败不会导致前面已做指令的回滚,也不会造成后续的指令不做。
集群策略(可以抗更高的并发量,高可用,避免单机故障)
1.Redis主从复制
实现:多台服务器,一主多从
主机负责读写,从机负责读--->读写性能增加,从机和主机保持一致
优点:防止数据的丢失,主机挂了,从机可以立即配置为主机,一定程度上可以解决单点故障。
缺点:1.主机挂了,从机不能自动上位,需要手动配置。
2.主机内存有限
无法解决存储上限的问题
Redis主从同步策略:主从刚刚连接的时候,进行全量同步;全同步结束后,进行增量同步。当然,如果有需要,slave 在任何时候都可以发起全量同步。redis 策略是,无论如何,首先会尝试进行增量同步,如不成功,要求从机进行全量同步。
2.哨兵机制
主机和从机每一个机器都有一个哨兵,哨兵之间会有相应的联系,如果说master (主机)挂掉了,哨兵会自动选举slave来作为主机,保证服务的高可靠。
保证主库存活,监控主库的状态 无法解决存储上限的问题
缺点:主机决定了当前集群的内存容量,决定整个集群的容量
3.Redis-Cluster 多主多从,去中心化 
去中心化模式中一般有三主三从,因为有多个主机,每个主节点只负责读写一部分数据。
去中心化模式中一共有16384个位置 ,多台主机平均分配。
优点:
1.有主从,可以自动切换,保证数据不丢失,服务不停止
2.大大提高了读写性能,集群的内存也成倍增加,完善了哨兵模式下的缺点。
3.提供数据槽,用来存储数据,方便数据的迁移。如果数据迁移,是整个数据操一块迁移。

a.哈希卡槽slot,分片策略(crc16和crc16(key)%16384计算存储的卡槽) 
b.请求随机分配到主节点,错误转向


基于Redis实现分布式锁:Redisson(RLock)红锁
结合项目,谈项目中的使用
你们项目中使用多少台机器?

 

青山不改,绿水常流。谢谢大家!

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值