redis全面总结

  1. redis是什么 redis是c语言开发的一个开源的高性能键值对的内存数据库,一个内存中的数据结构存储系统,他可以用做数据库,缓存,消息中间件.支持多种类型的数据结构,如字符串,列表,哈希,集合,有序集合,bitmaps,Hyperloglogs,geo(地理空间) 字符串,是redis的基本类型,一个key对应一个value,最大可以存储512M,常用的命令有set,get,mget等,应用场景微博数,粉丝数 列表,是一个字符串列表,按照插入的顺序排序,是一个双向链表,支持反向查找和遍历,常用命令lpush,rpush,lpop,rpop,lrange等命令,使用场景关注列表,好友列表等 哈希,和我们java中的hashmap类似,hash特别适合存储对象常用命令,hget,hset,hgetall等,应用场景可以存储用户的信息商品的信息等, set,是一种无序集合,支持去重操作,但没有顺序,常用命令,sadd,spop,smemebers,sunion操作,方便集合之间的操作,引用场景,判断某个元素是否存在set集合中 zset,和set类似,且有序,使用一个额外的参数score为成员排序,内部使用hashmap和跳跃表实现存储和有序,HaspMap存放成员到score的映射,而跳跃表存放所有的成员,使用跳表实现比较高的查询效率,常用命令zadd,zrange,zrem,zcard等待,使用场景用分数进行成员的从小到大的排序 bitmaps(位图),实际上就是字符串,但是他可以对字符串的位进行操作,可以把位图当做一个以位为单位的数组,数组中只有0或1,如[00111010010010...],数组的下表就是偏移量,最大长度是512M,即2^32个比特币,常用命令setbit ,getbit,bitcount,使用场景,如用户的打卡,网站的浏览次数等等,(如果我们使用String记录用户的打卡,当用户量非常大的时候,就会占用内存,但是使用位图,一年365天相当于365bit,1字节=8bit,也就46字节而已,比如setbit user1 0 1表示user1第一天打卡成功,setbit user1 1 0表示user1第二天打卡失败) Hyperloglogs,提供一种不太准确的基数统计算法(统计一批数据中的不重复的个数),常用命令pfadd,pfcount,pfmerge等等,使用场景网页的UV(用户访问网站的次数) geospatial(地理空间),把指定的地理空间位置添加到指定的key中,如geoadd city 116.40 39.9 北京(geoadd key longitude latitude member),常用命令geoadd,geopos,geodist,georadius使用场景,计算两点之间的距离,查看指定位置附近范围的人.
  2. redis雪崩,缓存穿透,击穿是什么意思,如何解决 redis雪崩,我们认知的缓存都是存储热点数据,我们查询数据,先去缓存查找,如果缓存不存在,就直接到数据库查找,但是有一种情况我们要注意,比如,我们把缓存的key的有效时间是晚上0点,然而再0点正好有一次大促销活动,假设0点的请求量为8000请求/秒,同时所有的key失效了,因此8000个请求直接落到了数据库,此时数据库还没有反映过来,就直接过了,这就是雪崩。 如果遇到这种情况,我们可以给redis存储的数据设置一个随机事件,而不是设置同一时刻,这样就可以保证不会大面积失效,当然如果redis是集群,可以把热点数据分布在不同的redis库中也能避免全部失效,最暴力的就是不设置过期时间,更新操作在修改缓存就可以了 缓存穿透,其实就是缓存和数据库都没有数据,此时有大量的请求,获取不存在的数据,如我们数据的id都是大于1的值,但是黑客使用id=-1的请求不断的攻击,导致数据库压力过大,严重的时候会导致数据挂掉 如果遇到这种情况,我可以给请求入参添加校验,只有合法的参数才能请求服务,也可以利用布隆过滤器,当不存在的时候就必要查询请求了。 缓存击穿,是指一个大热点key,百万级用户不断请求,但是在某一刻失效了,也会导致大量请求到数据库,导致数据库挂掉, 如果遇到这种情况,我也可以设置缓存不过期,或者使用分布式锁。
  3. redis是单线程吗,为什么这么快 resi是单线程,但是官方声称redis的QPS可达100000+,为什么是单线程还这么快,如下原因
    1. redis基于内存,所有数据都在内存中,类似hashMap,时间复杂度为O(1)
    2. 数据结构简单,对数据操作也简单
    3. 使用单线程,避免了不必要的上下文切换和竞争条件不存在多线程的CPU切换,也不存在加锁释放锁操作。
    4. 使用多路复用IO模型,非阻塞IO.
  4. redis和memcached有什么区别
    1. redis可以持久化,而memcached数据全部在内存中
    2. redis支持多种数据结构,memcached支持key-value
    3. 使用的协议不一样,memcached的客户端通过TCP连接服务器通信,redis使用RESP协议通信,是专门为Redis设计的通讯协议,redis直接构建自己的VM机制,因为一般的系统调用系统函数,会浪费一定的时间去移动和请求.
    4. value的大小,redis可以达到1GB,而memcached只有1MB
  5. Redis的淘汰策略有哪些 策略 描述 volatile-lru 从已设置过期时间的KV集中,优先对最近最少使用的淘汰 volatile-ttl 从已设置过期时间的KV集中,优先对剩余时间短的数据进行淘汰 volatile-random 从已设置过期时间的KV集中,随机选择数据淘汰 volatile-lfu 从已设置过期时间KV集中,优先选择最不经常的数据进行淘汰 allkeys-lru 从所有KV集中,优先对最近最少的数据进行淘汰 allkeys-random 从所有KV集中,随机选择数据淘汰 allkeys-lfu 从所有kV集中,最不长用的数据进行淘汰 noeviction 不淘汰,直到超过最大内存,返回错误信息
  6. redis的持久化有几种 redis的持久化操作有两种,一种是RDB,RDB是以快照形式直接把内存的数据保存在一个dump文件中,而另外一种AOF,是把每一次修改命令存储在文件里,redis默认是RDB持久化方式,但是在重启的的时候,他会优先使用AOF,因为AOF保存的数据比RDB更加完成, RDB触发的方式
    1. 手动触发,使用save,bgsave命令
      1. save会阻塞redis服务器进行直到RDB文件创建完毕之后,否则服务器在这期间一直阻塞,而bgsave是会fork一个子进程,有子进程负责创建RDB文件,而父进程会继续处理请求。
    2. 自动触发,通过配置文件的命令save m n,满足下面任何一个条件如
      1. save 900 1,到900秒内的时候,如果redis至少发生一次变化
      2. save 300 10,到300秒内,至少发生10变化
      3. save 69 10000,到10000秒内,知道发生10000变化
    3. 其他原因如主从复制场景,从节点执行全量复制操作,或执行shutdown命令时,都会执行RDB持久化
  7. redis中bgsave执行流程
  1. redis父进程判断是否有执行save,bgsave,bgrewriteaof的子进程,如果在执行则bgsave命令直接返回,
  2. 父进程执行fork操作创建子进程,这个过程父进程阻塞,redis不能执行客户端的任何命令
  3. 父进程fork后,bgsave命令返回"backgroud saving started"信息并不再阻塞父进程,并可以相应其他命令
  4. 子进程创建RDB文件,根据父进程内存快照生成临时文件,完成对原来文件的替换
  5. 子进程发送信号给父进程表示完成,父进程更新统计信息
  1. AOF运行原理

开启AOF,需要在配置文件中配置appendonly yes,而AOF执行流程包括下面三种

  1. 命令追加,将redis的写命令追加到缓冲区aof_buf
  2. 文件写入和文件同步,根据不同的同步策略将aof_buf的内容同步到磁盘
  3. 文件重写,定期重写AOF文件,达到压缩的目的

命令追加

redis是将写命令追加到缓冲区,而不是直接写入文件,主要是为了避免每次写命令直接写入磁盘,导致硬盘IO成为redis负载的瓶颈

文件写入和文件同步

为了提高文件写入的效率,在现在操作系统中,当用户调用write函数将数据写入文件的时候,操作系统通常将数据暂存到一个内存缓冲区里,当缓冲区慢了或者超过了指定大小后,才会将内存缓存区中的数据写入到内存,这样虽然提高了效率,但是存在安全问题,比如计算机停机,内存缓存区的数据就会丢失,因此操作系统提供了文件同步的同步函数fsysnc,fdatasync函数,可以强制把操作系统立刻将缓存区中的数据写入到硬盘里,从而保证数据的安全性,文件同步策略的策略由参数appendfsync控制

appendfsync always,
//命令写入aof_buf后立刻调用系统fsync操作同步到AOF
appendfsync no
//命令写入aof_buf后调用系统write操作,不对AOF文件做fsync同步,
//此时的同步有操作系统负责,通常同步周期30s
appendfsync everysec
//命令写入aof_buf后调用系统write操作,write完成后线程返回,fsync同步文件操作由专门
//的线程每秒同步一次

文件重写

文件重写是指定期重写AOF文件,减少AOF文件的体积,重写就是把redis中的数据转成写命令,同步到AOF文件,不会对旧的AOF文件进行任何读取写入操作。具体的操作流程

  1. redis父进程判断是否存在bgsave/bgrewriteaof的子进程,如果存在就直接返回,
  2. 父进程fork出子进程,这个过程父进程阻塞
  3. 父进程fork后,bgrewriteaof命令就返回"Background append only file rewrite started",此时父进程不在阻塞,同时redis客户端写命令写入AOF缓存区,并根据同步策略同步到旧的AOF文件
  4. 在上图中3.2步骤,在子进程生成新的AOF文件的同时,新的命令会同时写入aof_rewrite_buf中,这样就可以防止数据丢失,
  5. 子进程根据内存的快照,按照命令合并规则写入新的AOF文件
  6. 子进程完成新AOF文件后,就会通知父进程,父进程更新统计信息,
  7. 在5.2步骤,父进程会把aof_rewrite_buf的数据写入到新AOF文件,这样就保证了新的AOF保证了数据的完成性
  8. 最后使用新AOF文件替换旧的AOF文件
  1. RDB和AOF的优缺点 命令 RDB AOF 启动优先级 低 高 体积小大 恢复速度 快慢 数据安全性 丢数据 根据策略决定 轻重 重 轻
  2. 如何选择RDB和AOF持久化策略

两种持久化策略持久化都是有性能代价的,RDB持久化,在使用bgsave的时候会阻塞主进程,子进程向硬盘写数据会带来Io压力,AOF持久化,向硬盘写数据的频率越大,IO压力更大,甚至导致AOF阻塞问题,

而在实际场景,根据数据量,应用数据安全的要求,预算限制等不同情况,会有各种各样的持久化策略,我们可以单独用一种策略,也可以两种混合使用.

如果数据完全对丢失数据对业务没有任何影响,就可以不进行任何持久化如果在单机情况,如我们自己练习,如何可以接受丢失数据,可以使用RDB,如果只能接受秒级别的数据丢失,可以选择AOF

如果是我们的生产环境,主从环境,一般我们可以master关闭持久化,可以在slave关闭RDB,开启AOF,然后关闭自动重写,添加定时任务,定时调用bgrewriteaof

上面只是简单的举例,所以如果你可以接受几分钟你的数据丢失,那么可以使用RDB,否则可以使用AOF持久化,但是AOF每一条命令追加磁盘,会降低redis性能,对于数据备份和灾难恢复,定时生成RDB快照非常便于进行数据库备份,但是RDB的回复数据集的速度比AOF恢复速度快,如果混合持久化,AOF重写的时候就直接把RDB的内容写到AOF文件开头,这样做的好处是可以结合RDB和AOF的优点,快速加载同时避免丢失过多的数据,当然AOF里面的RDB部分是压缩格式不再是AOF格式,可读性差.

  1. redis主从复制过程 主从模式结合哨兵模式能够解决掉单点模式,提高redis可用性,从节点仅提供读服务,而主节点提供些操作,对于读多写少的情况,可以从节点的数量,从而提高响应效率,而主节点和从节点直接的复制过程如下
    1. 从节点执行slave masteip masterPort.保存主节点信息
    2. 从节点的定时任务发现主节点信息,建立和主节点的socker链接
    3. 从节点发送ping信号,主节点返回pong,两边就能互相通讯
    4. 连接建立以后,主节点将所有数据发送给从节点进行数据同步
    5. 主节点把当前的数据同步给从节点后,便完成了复制的建立过程,接下来,主节点就会持续把写命令发送给从节点,保证主从数据一致性。
  2. 主从复制的原理

redis2.8之前使用的sync runid offset同步命令,redis2.8之后使用的psync runid offset命令,连个都是同步的命令,但是sync仅支持全量同步,而psync支持全量同步和增量同步,

runid:每个redis节点都有一个唯一的id,且每次重启都是重新生成

offset:主节点和从节点各自维护自己的主从复制的偏移量offset,当主节点写入命令时候,会记录offset=offset+命令字节长度,从节点在收到主节点发送的命令后,也会记录自己的offset,并把自己的offset同步给主节点,这样主节点保存自己的和从节点的offset,通过对比就可以知道数据是否一致

repl_backlog_size:保存在主节点的一个固定长度的先进先出的队列,默认大小是1MB

  • 主节点发送数据给从节点过程中,主节点还会进行一些写操作,这个时候数据就会写入复制缓存区中,从节点完成主节点数据同步后,主节点将缓存继续发送给从节点,用于部分复制
  • 主节点不但会把写命令发送给从节点,而且会写入复制缓冲区,用户复制命令丢失的数据补救

全量复制的过程和部分复制过程如下图

全量复制的主要步

  1. 从节点发送psync ? -1命令,第一次发送,不知道主节点的runid因此使用?,且默认offset=-1
  2. 主节点发现是第一次复制,返回FULLRESYNC runid offset,runid是主节点的runid,offset是主节点的offset
  3. 从节点接收到主节点的信息,保存到info中
  4. 主节点发送FULLRESYNC后,启动bgsave命令,生成RDB文件进行持久化
  5. 主节点发送RDB文件给从节点,到从节点加载数据完成期间,主节点会把写命令放到缓冲区中
  6. 从节点清理自己的数据库数据
  7. 从节点加载RDB文件,将数据保存在自己的数据库中
  8. 如果从节点开启了AOF,从节点异步重写AOF文件

增量复制过程如下

  1. 当出现网路抖动,超过了连接时间,主从就会断开连接
  2. 但是在这期间主节点还会接受到命令,会把命令写入到复制缓冲区中(repl-bacjlog-buffer)
  3. 当网络恢复以后,从节点会主动再次连接
  4. 从节点发送psync runid offset,runid是当前自己的runid,offset是主节点给他偏移量
  5. 主节点接受到从节点的runid,和offset,会进行核对,其中master如果发现偏移量在复制缓冲区中,根据offset查找复制缓存的数据,且对从节点发送continue表示可以继续部分复制
  6. 主节点把缓存中的数据发送给从节点,保证主从的数据保持一致
  1. 主从复制会有什么问题
    1. 一旦出节点宕机,从节点晋升为主节点,同时需要修改应用方的主节点地址,还要使用命令使所有的从节点去复制新的主节点,整个过程需要人工干预
    2. 主节点的写能力受到单机的限制
    3. 原生复制在复制中断后,从界定会发起psync,此时如果同步不成功,则进行全量复制,期间会导致短暂的停顿
  2. 如何解决主从复制的问题 当然我可以使用哨兵模式,下图就是就是哨兵模式

如图,是哨兵的架构图,哨兵的主要功能就是主从节点存活检测,主从运行情况检测,自动故障转移,主从切换,可以执行以下四个任务

  • 监控,不断检查主服务器和从服务器是否正常运行
  • 通知,当redis服务器出现问题,哨兵通过api通知管理员发出通知
  • 自动故障转移,当主节点不能正常工作的时候,sentinal就会开启一次自动故障转移操作,会把其中一个从节点晋升为新的主机节,且会把其他从节点重新指向新的主节点,不需要任何人为干预
  • 配置提供者,在哨兵模式下,客户端在初始化的时候链接的是sentine节点,从中获取主节点的信息

  1. 哨兵原理

上图就是一张哨兵的架构图,我接着说他是如何工作的

  1. 每个sentinel节点都需要定期执行向所有主从服务器以及其他sentinel实例发送ping命令
  2. 但是当主节点最后一次回复ping命令超过了设置的时间(down-after-milliseconds参数指定的值),那么就会认为这个节点主观下线
  3. 如果一个主服务器被标记为主观下线,此时全部的sentinel节点都会每秒一次的频率确认主服务器的确是否进入主观下线状态
  4. 此时大多数sentinel确认主服务器为下线,那个这个主服务器标记为客观下线
  5. 正常情况下,每个sentinel会以每10秒一次的频率向已知的所有主从服务器发送info命令,但当一个主服务被标记为客观下线时,sentinel就会把info命令的频率改为每秒一次
  6. sentinel和其他sentinel协商客观下线的主节点状态,如果处于sdown状态则重新投票选出新的主节点,将剩余的节点指向新的节点进行数据复制
  7. 但是如果没有足够sentinel认为主服务下线时候,主服务器的客观下线状态就会移除,同时当主服务器的ping命令返回有效的恢复时候,就会移除主观下线。

本文分享自微信公众号 - 洁癖是一只狗(rookie-dog),作者:洁癖汪

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2021-01-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • redis面试总结

    (1) 速度快,因为数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1)

    三哥
  • Redis 全中文总结

    林万程
  • Redis哨兵功能全面分析与总结[实战操作篇]

    本文将通过理论+实践的方式从头到尾总结Redis中的哨兵机制。文章内容从主从复制的弊端、如何解决弊端、什么是哨兵、哨兵监控的图形结构、哨兵监控的原理、如何配置哨...

    A梦多啦A
  • Mysql全面总结

    常见的存储引擎有MyISAM,InnoDB,MEMORY,MERGE.今天我们就分别介绍一下,

    小土豆Yuki
  • Mybatis全面总结

    一级缓存,即本地缓存,作用域默认为sqlSession,本地缓存不能关闭,但是可以清空,同一次会话期间只要查询过的数据都会保存在当前sqlsession的一个m...

    小土豆Yuki
  • RabbitMQ全面总结

    是指应用程序对应用程序的一种高效可靠的消息传递的通信方法,通过提供消息传递和消息排序模型,他可以在分布式环境下扩展进程间的通信,典型的生产者和消费者的代表

    小土豆Yuki
  • Android WebView全面总结

    WebView是安卓中用来显示html文本内容的的控件,对html5也有很好的支持,ios的控件UIWebView差不多。网上对WebView的解释很多,但都是...

    晚晴幽草轩轩主
  • MySQL——锁(全面总结)

    latch称为闩锁(shuang suo),其要求锁定的时间必须非常短。若持续的时间长,则应用的性能会非常差。在InnoDB存储引擎中,latch又分为mute...

    用户5325874
  • 面试最全面经总结

    OSI 的 七层网络模型,主要有 物理层,数据链路层,网络层,传输层,会话层,表示层以及应用层;

    黑白格
  • Redis总结

    爱撒谎的男孩
  • Flutter填坑全面总结

    Flutter是一个新的跨平台开发的工具,博主也玩了一段时间,一步步的踩着坑摸石头过河,这其中受尽了各种各样的坑,各种谷歌,stackoverflow,Flut...

    AWeiLoveAndroid
  • pyquery用法全面总结

    版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明...

    云雀叫了一整天
  • 前端-Ajax的全面总结

    Ajax在前端开发中有着举足轻重的地位,关于Ajax的使用和注意事项一直是一个重要的话题,借此机会,本文希望对Ajax做一个全面的总结,彻底揭开Ajax的神秘面...

    grain先森
  • Java面试高频知识点总结 Redis

    高性能:从内存读取数据比从硬盘读取要快很多。如果数据库中对应的数据改变之后,同步改变缓存中相应的数据即可。

    Steve Wang
  • 面试java基础总结大全

    JVM(Java Virtual Machine):java虚拟机,用于保证java的跨平台的特性。

    Java团长
  • java内部类的全面总结

    三哥
  • Android之Intent用法全面总结

    [代码] 调用拨号程序 // 给移动客服10086拨打电话 Uri uri = Uri.parse("tel:10086"); Intent intent = ...

    晚晴幽草轩轩主
  • PHP超时处理全面总结

    这些地方都需要考虑超时的设定,但是PHP中的超时都是分门别类,各个处理方式和策略都不同,为了系统的描述,我总结了PHP中常用的超时处理的总结。

    明哥的运维笔记
  • 最全面的HTTP知识总结

    HTTP网络通信协议在任何的开发工作中都起到非常重要的作用,今天,我们来讲解下关于HTTP的相关知识。

    Carson.Ho

扫码关注云+社区

领取腾讯云代金券