🦆博主介绍:小黄鸭技术
🌈擅长领域:Java、实用工具、运维
👀 系列专栏:📢 八股文之路
📧如果文章写作时有错误的地方,请各位大佬指正,一起进步!!!
🧡欢迎大家点赞➕收藏⭐➕评论💬支持博主🤞
目录
Redis是什么?
全称:REmote DIctionary Server
简介:Redis 是一个高性能的key-value数据库。 用作数据库、缓存、消息代理和流引擎。Redis 提供数据结构,例如 字符串、散列、列表、集合、带范围查询的排序集合、位图、超日志、地理空间索引和流。Redis 内置了复制、Lua 脚本、LRU 驱逐、事务和不同级别的磁盘持久性,提供高可用性Redis Sentinel和Redis Cluster的自动分区。
Redis的基本数据类型
String(字符串)
业务场景
数据缓存
- 缓存一些常用的基本信息,比如用户信息或者常用配置等。
- Key:userId | Value:用户信息
第一次查询时从数据库查询并放入Redis中缓存,下次取用从Redis中,减少数据库压力。
计数器
- 点赞数
- 粉丝数
- 访问数
- Key:userId | Value:用户信息
上面的场景当出现比较爆款的信息时,访问量、点赞数、粉丝数短时间会增加的比较多,存放数据库效率比较低,压力也比较大,先存放进Redis后续同步到数据库。
验证码
- 短信验证码
- 邮箱验证码
- Key:手机号或者邮箱 Value:验证码
验证码属于短期有效数据,放入数据库效率太低,验证通过则删除,还可以通过设置过期时间非常方便的移除验证码。
分布式锁
- 扣减库存
- 集群部署定时任务
- 接口防重
一般用来在分布式场景下锁定资源,保证数据的正确性,通过SETNX或者LUNA脚本来对资源加锁。
Hash(哈希)
业务场景
购物车
- 添加商品进入购物车
- Key:客户Id Field:商品Id Value:商品数量
例如:hmset customer:1 product:1 2 添加客户1的1号商品2个
存储对象
- Key:对象名称 Field:属性 Value:值
例如:hmset user 1:name duck 1:age 18 添加一个ID为1,名称为duck,年龄为18的用户
List(列表)
业务场景
消息队列
List 提供了两个阻塞的弹出操作:blpop/brpop,能用来做点对点的消息队列,不过不推荐,实际中用Kafk,RokectMQ这些成熟的消息队列去做就好了
排行榜
List 提供了lrange的命令可以分区间查看队列中的数据,但只有定时计算的排行榜才适合存储在List中,比如每日销量排行,成绩排行等。
Set(集合)
业务场景
共同好友
- sinter:获得A和B两个用户的共同好友
- sismember:判断A是否是B的好友
- scard:获取好友数量
点赞
- sadd:添加点赞
- srem:取消点赞
- sismember:检查是否点赞
- scard:获取点赞总人数
随机播放
- srandmember:从列表中随机获取几条数据。
ZSet(有序集合)
业务场景
实时排行榜
- row:Redis根据score生成的序号
- value :用户ID或者业务ID
- score:排序的分数,一般set value时同时指定score
ZREVRANGE:取出排行榜前N的数据。
延时队列
可以通过score进行按照时间戳排序,轮询从队列中取出数据消费。
Redis淘汰策略
- noeviction:当内存使用达到阈值的时候,所有引起申请内存的命令会报错。
- allkeys-lru:在主键空间中,优先移除最近未使用的key。(推荐)
- volatile-lru:在设置了过期时间的键空间中,优先移除最近未使用的key。
- allkeys-random:在主键空间中,随机移除某个key。
- volatile-random:在设置了过期时间的键空间中,随机移除某个key。
- volatile-ttl:在设置了过期时间的键空间中,具有更早过期时间的key优先移除。
Redis常见问题
缓存雪崩
Redis缓存中的大量数据在同一时间全部失效,大量的请求打到数据库上,严重则可能导致数据库压力增加或者宕机。
解决方案
- 对每个Key设置不同的失效时间,避免同时失效。
- 集群部署,分布热点key在不同的库中。
- 永不失效,对于一些非常重要但是更新不太平凡的数据可以采用永不过期的策略。
缓存穿透
大量的请求Redis和数据库中都没有的key,导致请求打到数据库上,严重则可能导致数据库压力增加或者宕机。
例如:查询数据库中Id小于0的数据,或者特别大的Id,就会打到数据库,从而拖垮数据库。
解决方案
- 添加参数校验,小于0的Id直接return出去
- 缓存无效key,把请求的key缓存下来并设置一定的失效时间,防止大量不同的key占用太多Redis内存。
- 布隆过滤器
缓存击穿
一个承受大量并发的一个热点key突然失效,这时候key突然失效,导致大量的请求都打到了数据库上,严重则可能导致数据库压力增加或者宕机。
解决方案
- 永不失效
- 多级缓存
Redis持久化机制
什么是Redis持久化,有哪些持久化机制?
一般来说我们常用的持久化机制有RDB和AOF两种。
RDB和AOF分别是什么,优缺点有哪些?
RDB
全称:Redis DataBase,可以在指定时间生成数据集的快照。
优点:
- 占用空间小
- 可以存不同日期版本的数据集,恢复时可以选择不同节点回滚
- 恢复速度比AOF快
缺点:
- 容易造成数据丢失,服务器宕机会丢失在备份间隔中的数据变更。
- 数据集比较大的话,fork子线程备份数据会造成服务器停顿。
AOF
全称:Append Only File,记录服务器执行的所有写操作命令。
优点:
- 数据比RDB可靠,默认每秒记录一次,哪怕服务器宕机,也只会丢失1s内的数据
- 日志追加的形式进行持久化,即使错误也可以通过工具来修复
- 可读性比RDB高
缺点:
- 因为是以日志形式进行持久化的,所以体积相比RDB快照更大。
- AOF文件频繁刷盘会导致磁盘IO的性能,从而影响Redis性能。
RDB和AOF混合持久化
在RDB备份的间隔期间,利用AOF来记录Redis的操作记录,默认关闭,可以通过aof-use-rdb-preamble开启。
优点:
- 避免RDB fork子线程备份时时对主线程的影响
- 结合了RDB和AOF的优点
缺点:
- 可读性较差
选择那种持久化方式较好?
- 如果需要保证数据的安全性,对于数据丢失的容忍性较低,那么选择混合持久化或者AOF持久化机制。
- 如果可以容忍丢失一部分数据,那么采用RDB的方式较好。
- 如果可以允许丢失全部数据,那么关闭持久化来提高Redis的性能也可以。
Redis宕机时采用什么持久化文件来恢复数据?
- 在同时开启AOF和RDB时,Redis重启时会使用AOF来进行数据重建,数据更完整。
- 如果开启了混合持久化,通过判断文件头是否时REDIS来载入RDB,然后在利用为客户端进行AOF补全。
主从复制
前提
需要开启主服务器的持久化机制,不然主服务器宕机同步会使从服务器丢失所有数据。
最常见的主从复制架构
一主一丛或者一主二从
太多的从服务器同步会导致带宽被占用,影响服务器性能。
2.8版本之前
全量同步+命令传播
全量同步:
从服务器向主服务器发送SYNC命令,主服务器生成一个RDB文件让从服务器加载,达到主从服务器完全一致。
命令传播:
当全量同步完成后,通过命令传播同步主从服务器之间的数据来保持一致。
2.8版本之后
全量同步+部分同步,引入了PSYNC代替SYNC命令执行复制时的同步操作。
全量同步和旧版全量同步是一致的,通过记录偏移量的方式同步宕机时主从服务器不一致的数据。
哨兵模式
什么是哨兵模式?
Sentinel(哨岗、哨兵)是Redis的高可用性(high availability)解决方案:由一个或多个Sentinel实例(instance)组成的Sentinel系统(system)可以监视任意多个主服务器,以及这些主服务器属下的所有从服务器,并在被监视的主服务器进入下线状态时,自动将下线主服务器属下的某个从服务器升级为新的主服务器,然后由新的主服务器代替已下线的主服务器继续处理命令请求。
摘自《Redis设计与实现》
为什么需要哨兵模式?
主从架构下Master宕机,需要手动的选举Slave成为Master,但是人工干预效率较低,容易出错导致Redis不可用。而哨兵模式可以监控主从服务器状态,发生故障时进行自动选举。
哨兵模式有那些功能?
- 监控(Monitoring):持续监控Redis Master和Slave是否出现故障。
- 通知(Notification):当Redis运行出现故障时可以把故障信息通过API通知到运维人员或者其他应用中。
- 自动故障恢复(Automatic failover):当Master运行故障时,哨兵会启动自动故障恢复操作:将某个Slave会升级为Master,其他Slave会使用新的Master进行主从复制,当客户端连接时,会向客户端推送新的Master地址,保证服务可用。
Redisson看门狗机制
看门狗WatchDog的作用?
防止任务还未完成,redis的锁就失效了,导致其他线程抢占,从而线程不安全导致业务出现问题。所以看门狗就是用来检测任务是否完成,未完成则对锁进行续期,防止其他线程抢占带来的安全问题。
🧡欢迎大家点赞➕收藏⭐➕评论💬支持博主🤞