本文主要是介绍Redis 基础知识介绍,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!
Redis 基础知识介绍
NoSql
- 海量用户+高并发,会造成服务器瘫痪,主要原因就是使用的是关系型数据库
原因
- 1.性能瓶颈:磁盘IO性能低下
- 关系型数据库存取数据的时候是要通过磁盘IO的。磁盘的性能本身是比较低的
- 2.扩展瓶颈:数据关系复杂,扩展性差,不便于大规模集群
- 关系型数据库表与表的关系非常复杂,十分影响查询效率,这个情况下,进行扩展也是十分困难的
解决思路
- 1.降低磁盘IO次数,越低越好
- 2.去除数据间的关系,越简单越好
这就是NoSql
NoSql概念
Redis
概念
- 概念:Redis (REmote DIctionary Server) 是用 C 语言开发的一个开源的高性能键值对(key-value)数据库。
特征
应用场景
- 1.为热点数据加速查询(主要场景)。如热点商品,热点新闻,热点资讯,推广类等高访问量信息等
- 2.即时信息查询。如各类排行榜、各类网站访问统计、公交到站信息、在线人数信息(聊天室、网站)、设备信号等
- 3.时效性信息控制。如验证码控制,投票控制等。
- 4.分布式数据共享。如分布式集群架构中的session分离
- 5.消息队列--已经弱化
Redis的使用
#启动服务器,默认启动端口为6379
redis-server
#启动服务器,指定6380端口启动
redis-server --port 6380
#启动客户端,默认连接6379端口 redis-cli [-h host] [-p port]
redis-cli
#启动客户端,指定6380端口连接
redis-cli -p 6380
持久化
什么是持久化
- 利用永久性存储介质将数据进行保存,在特定的时间将保存的数据进行恢复的工作机制成为持久化
- 持久化用于防止数据的意外丢失,确保数据安全性
持久化过程保存什么
- 将当前数据状态进行保存,快照形式,存储数据结果,存储格式简单,关注点在数据---RDB
- 将数据的操作过程进行保存,日志形式,存储操作过程,存储格式复杂,关注点在数据的操作过程---AOF
RDB
-
sava指令
- reids是单线程的,多台客户端同时操作redis会创建一个任务队列,save指令的执行会阻塞当前的redis服务器,直到当前RDB过程完成为止,有可能长时间阻塞,线上环境不建议使用
-
bgsave指令
- 1.指令bgsave指令,会先向redis发送指令
- 2.redis会返回一个后台保存开始执行 的消息
- 3.redis会去调用fork函数生成一个子进程
- 4.然后去创建rdb文件
- 5.最终redis返回执行结果
- 注意:bgsave命令是针对save阻塞问题做的优化,redis内部所有涉及到RDB的操作都使用bgsave指令进行操作,save命令可以放弃使用
- save配置
- 设置自动持久化的条件,满足限定时间范围内key的变化数量达到指定数量即进行持久化
#second:监控时间范围 changes:监控key的变化量
save second changes
save 10 2
- 从redis启动开始,如果十秒内key变化2次,在第十秒的时候直接保存操作,后台也还是bgsave进行保存
- 如果在十秒内变化了一次,那么redis会在变化第二次的时候进行后台保存操作,第二个周期会在第一次保存的时候开始计时
- 注意:save配置要根据实际业务情况进行设置,频度过高或者过低都会出现性能问题,结果可能是灾难性的,save配置启动后执行的是bgsave操作
-
RDB特殊启动形式
debug reload
shutdown save
-
RDB优点
- RDB是一个紧凑压缩的二进制文件,存储效率较高
- RDB内部存储的是redis在某个时间点的数据快照,非常适合用于数据备份,全量复制等场景
- RDB恢复数据的速度要比AOF快很多
- 应用:服务器中每X小时会执行bgsave备份,并将RDB文件拷贝到远程机器中,用于灾难恢复
-
RDB缺点
- RDB方式无论是执行指令还是利用配置,无法做到实时持久化,具有较大的可能性丢失数据
- bgsave指令每次运行要执行fork操作创建子进程,要牺牲一些性能
- redis的众多版本中未进行RDB文件格式的版本统一,有可能出现版本服务器之间数据格式无法兼容的现象--解决方案就是 导出来存到word或者Excel中,再导入回去即可。
-
RDB存储的弊端
- 存储数据量较大,效率较低,基于快照思想,每次读写都是全部数据,当数据量巨大时,效率非常低
- 大数据量下的IO性能较低
- 基于fork创建子进程,内存产生额外消耗
- 宕机带来的数据丢失风险
- 解决思路:
- 不写全数据,仅仅记录部分数据
- 降低区分数据是否改变的难度,改记录数据为记录操作过程
- 对所有操作均进行记录,排除丢失数据的风险
AOF
- AOF持久化:以独立日志的方式记录每次写命令,重启时再重新执行AOF文件中命令达到恢复数据的目的。与RDB相比可以简单理解为由记录数据改为记录数据变化
- AOF的主要作用就是解决了数据持久化的实时性,目前已经是redis持久化的主流方式
AOF重写
bgrewriteaof
RDB与AOF区别
数据删除策略
定时删除
- 创建一个定时器,当key设置有过期时间,且过期时间到达时,由定时器任务立即执行对键的删除操作
- 优点:节约内存,到时就删除,快速释放掉不必要的内存占用
- 缺点:CPU压力很大,无论CPU此时负载量多高,均占用CPU,会影响redis服务器响应时间和指令吞吐量
- 总结:用处理器性能换取存储空间(拿时间换空间)
惰性删除
数据到达过期时间,不做处理。等下次访问该数据时,我们需要判断
- 如果未过期,返回数据
- 发现已过期,删除,返回不存在
- 优点:节约CPU性能,发现必须删除的时候才删除
- 缺点:内存压力很大,出现长期占用内存的数据
- 总结:用存储空间换取处理器性能(拿空间换时间)
定期删除
定时删除和惰性删除这两种方案都是走的极端,那有没有折中方案?
我们来讲redis的定期删除方案:
- Redis启动服务器初始化时,读取配置server.hz的值,默认为10
- 每秒钟执行server.hz次serverCron()-------->databasesCron()--------->activeExpireCycle()
- activeExpireCycle()对每个expires[*]逐一进行检测,每次执行耗时:250ms/server.hz
- 对某个expires[*]检测时,随机挑选W个key检测
如果key超时,删除key
如果一轮中删除的key的数量>W*25%,循环该过程
如果一轮中删除的key的数量≤W*25%,检查下一个expires[*],0-15循环
W取值=ACTIVE_EXPIRE_CYCLE_LOOKUPS_PER_LOOP属性值
- 参数current_db用于记录activeExpireCycle() 进入哪个expires[*] 执行
- 如果activeExpireCycle()执行时间到期,下次从current_db继续向下执行
总的来说:定期删除就是周期性轮询redis库中的时效性数据,采用随机抽取的策略,利用过期数据占比的方式控制删除频度
- 特点1:CPU性能占用设置有峰值,检测频度可自定义设置
- 特点2:内存压力不是很大,长期占用内存的冷数据会被持续清理
- 总结:周期性抽查存储空间(随机抽查,重点抽查)
数据淘汰策略(逐出算法)
概述
什么叫数据淘汰策略?什么样的应用场景需要用到数据淘汰策略?
当新数据进入redis时,如果内存不足怎么办?在执行每一个命令前,会调用freeMemoryIfNeeded()检测内存是否充足。如果内存不满足新 加入数据的最低存储要求,redis要临时删除一些数据为当前指令清理存储空间。清理数据的策略称为逐出算法。
注意:逐出数据的过程不是100%能够清理出足够的可使用的内存空间,如果不成功则反复执行。当对所有数据尝试完毕, 如不能达到内存清理的要求,将出现错误信息如下
(error) OOM command not allowed when used memory >'maxmemory'
这篇关于Redis 基础知识介绍的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!