江苏龙网

  1. 首页 > 资讯 > 科技 > >

技术编程|Redis面试知识点

NOSQL与大数据的特点
NOSQL与大数据的特点Redis 事务Redis乐观锁Redis的持久化redis的消息发布与订阅：Redis 集群Redis的缓存穿透 ， 击穿和雪崩命令
NOSQL： Not only SQL ， 不只是数据库 ， 泛指非关系型数据库 ， 比如redis 。
大数据的3V + 3高： 3V：海量Velum ， 多样Variety 实时Velocity
3高：高并发 高可扩 高性能
Redis： Remote Dictionary Server 远程字典服务 。是一个开源的 ， 使用C编写的 ， 支持网络、可基于内存亦可以持久化的日志型,key-value数据库 ， 并提供了多种语言的支持 。Redis 事务
Redis 事务： redis事务的本质是一组命令的集合 ， 一个事务的所有命令都会被序列化 ， 在事务的执行过程中 ， 会按照顺序执行 。
所有的命令并不是直接就执行 ， 而是发起执行命令才会执行！所以事务的执行为：开启事务-》命令入队-》执行事务 。Node02:6379>MULTIOKNode02:6379>setkey1123QUEUEDNode02:6379>getkey1QUEUEDNode02:6379>EXEC1)OK2)"123"Node02:6379>还可以取消事务：用discardnode02:6379>MULTIOKnode02:6379>setkey1345QUEUEDnode02:6379>DISCARDOKnode02:6379>getkey1"123"
如果在事务中有异常 ， 如果是编译时异常 ， 比如是命令写错了 ， 整个事务都不会执行 ， 但是如果是运行时异常 ， 则其他命令照样可以执行成功 。Redis乐观锁
Redis乐观锁：使用watch 和事务同时使用 ， 意思是Wath监控key ， 之后开启事务执行相应的操作 ， 这个时候如果有别的线程更改了这个key的值 ， 那么等你执行事务的时候就会执行失败 。这个是个乐观锁 。原理就是watch 监控key ， 进行exec的时候 ， 再去获取key 。去和Wath的比较 ， 如果相同则执行 ， 否则就会失败 。Redis的持久化
Redis的持久化：指的是在指定的时间间隔内 ， 将内存的数据集快照写入磁盘 ， 防止机器宕机时数据的丢失 ， 恢复的时候将快照内容读取到内存 。
两种方式 ， 一种是RDB模式 ， 一个是AOF 。
RDB模式保存的文件是以rdb ， Redis会fork一个一个子进程来进行持久化 ， 会将数据先写入一个临时文件 ， 当持久化结束之后用这个临时文件替换之前的文件 。整个过程主进程不进行任何的IO操作 ， 这个就保证了性能 。
这种方式默认在配置文件中是开启的：save9001save30010save6010000#save51dbfilename"dump.rdb"dir"位置"#前三个选项表示的是多长时间内进行了多少次操作就会进行保存一次 ， #比如第一个#表示的是900秒内至少有一个key发生了变化就#进行保存操作 ， 第二个表示300秒内至少10个key发生了变化就会就行保存 ， dbfilename指的是数据库的名称 ， dir是位置#rdbcompressionyes#说明：设置存储至本地数据库时是否压缩数据 ， 默认为yes ， 采用LZF压缩#经验：通常默认为开启状态 ， 如果设置为no ， 可以节省CPU运行时间 ， 但会使存储#的文件变大（巨大）#rdbchecksumyes#说明：设置是否进行RDB文件格式校验 ， 该校验过程在写文件和读文件过程均进行#经验：通常默认为开启状态 ， 如果设置为no ， 可以节约读写性过程约10%时间消耗 ， #但是存在一定的数据损坏风险
这个持久化的优点是：1. 存储的是一个压缩的二进制文件 ， 效率高 。2. 存储的是某一个时间点的所有数据 ， 适合数据的 ， 全量复制等场景 ， 3 ， 恢复速度要比AOF快 ，
缺点是：可能会丢失一部分数据 ， 比如说在60秒还没有1000个key发生变化 ， 就宕机了 ， 这个时候发生变化的kye就丢失了 。单独fork一个子进程 ， 也是要耗费一些性能的 。
AOF方式的是追加文件 ， 指的是把我们所有的写命令以日志的形式记录下来 ， 追加到文件里面后缀为aof ， redis恢复的时候去读取aof文件重新构建数据 ， 达到恢复的目的 。这种方式也是单独的开启一个子线程进行操作 。appendonlyno#默认这种方式是关闭的 ， yes打开appendfilename"appendonly.aof"#aof文件名appendfsynceverysec#aof持久化策略的配置#no表示不执行fsync ， 由操作系统保证数据同步到磁盘 ， 速度最快 。#always表示每次写入都执行fsync ， 以保证数据同步到磁盘 。#everysec表示每秒执行一次fsync ， 可能会导致丢失这1s数据 。no-appendfsync-on-rewriteno#在aof重写或者写入rdb文件的时候 ， 会执行大量IO ， #此时对于everysec和always的aof模式来说 ， 执行fsync会造成阻塞过长时间 ， #no-appendfsync-on-rewrite字段设置为默认设置为no 。如果对延迟要求很高的应用 ， 这个字段可以设置为yes ， #否则还是设置为no ， 这样对持久化特性来说这是更安全的选择 。#设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入 ， 默认为no ， #如果是yes 。Linux的默认fsync策略是30秒 。可能丢失30秒数据 。auto-aof-rewrite-percentage100#aof自动重写配置 。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少#进行重写 ， 即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写 。#当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时 ， 自动启动新的日志重写过程 。auto-aof-rewrite-min-size64mb#设置允许重写的最小aof文件大小 ， #避免了达到约定百分比但尺寸仍然很小的情况还要重写aof-load-truncatedyes#aof文件可能在尾部是不完整的 ， 当redis启动的时候 ， #aof文件的数据被载入内存 。重启可能发生在redis所在的主机操作系统宕机后 ， #尤其在ext4文件系统没有加上data=http://www.sos110.com/show/12/136533/ordered选项（redis宕机或者异常终止不会造成尾部不完整现象 。）出现这种现象 ， #可以选择让redis退出 ， 或者导入尽可能多的数据 。如果选择的是yes ， 当截断的aof文件被导入的时候 ， #会自动发布一个log给客户端然后load 。如果是no ， 用户必须手动redis-check-aof修复AOF文件才可以 。


推荐阅读


上一篇：红米手机|跑分超53万，价格不到2500，最值得买的5G中端机

下一篇：小米手机|公认"性价比最高"的4款手机，配置强价格低，好看年轻又时尚