• redis学习随笔


    常用5大数据类型
    String,List,Hash,Set,ZSet;

    redis的模式是:单线程+多路io复用

    Redis的发布订阅是一种消息通信模式,发送者发送消息,订阅者接收消息

    Redis客户端客户端可以订阅任意数量的频道
    在这里插入图片描述
    客户端1订阅:subscribe channel1

    客户端2发送信息:publish channel1 hellloooo,此时客户端1获取到信息

    redis的事务是一个单独的隔离操作,事务中的所有命令都会序列化、按顺序执行,事务在执行的过程中,不会被其他客户端发送来的命令请求打断;

    redis事务的主要作用是串联多个命令防止别的命令插队
    如果队列中的命令在组队时某个命令出现了错误,那么执行时整个队列都会被取消
    如果队列中的命令在执行时某个命令出现了错误,那么只有该命令会失败,队列中的其他命令继续执行

    内存中的数据存入到硬盘中,称为数据的持久化;

    RDB(Redis DataBase)方式:

    在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是snapshot快照,它恢复时是将快照文件直接读到内存里;通俗说法是每隔几秒或者其他时间,对当前的数据集进行拍照,记录当前数据集;

    底层是先将数据写入到一个临时文件,待数据持久化结束后,将临时文件替换上次持久化完成的文件,期间主进程不进行任何IO操作,保证了极高的性能,如果数据恢复的要求对数据的完整性不敏感,那么rdb方式是非常合适的,缺点是最后一次持久化后的数据可能会丢失,例如设置20秒至少3个数据变化则拍一次快照,如果修改了3个数据,但是20秒保存一次的时间间隔还没到服务器就宕机了,则会丢失最后一次修改的数据;
    AOF(append only file)方式:

    以日志方式记录每个写操作,不记录读操作,只能追加文件但不能改文件,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作;

    AOF默认不开启,如果AOF和RDB都开启了,那么默认会使用AOF
    AOF持久化流程:

    客户端请求写命令被append追加到AOF缓冲区内;
    AOF缓冲区根据AOF持久化策略【always,everysec,no】,将操作同步到磁盘的AOF文件中;
    AOF文件大小超过重写策略或者手动重写时,会对AOF文件rewrite重写,压缩AOF文件容量;
    reids服务重启时,会重新加载AOF文件的写操作达到数据恢复的目的;

    RDB优势:

        适合大规模数据恢复
    
        对数据的完整性的完整性不高更适合使用
    
        节省磁盘空间
    
        恢复速度快
    
    • 1
    • 2
    • 3
    • 4
    • 5
    • 6
    • 7

    RDB劣势:

        过程中,内存中的数据被克隆了一份,数据会膨胀为原来的两倍,需要提前考虑
    
        最后一次数据可能会丢失
    
    • 1
    • 2
    • 3

    AOF的优势:

    备份机制更稳健,数据丢失率更低;
    可读的日志文本,通过操作AOF文件,可以修复误操作
    AOF的劣势:

    比RDB更占用磁盘空间
    恢复速度更慢
    每次读写都同步,性能压力更大
    存在潜在BUG,造成无法恢复数据

    RDB针对的是数据,AOF针对的是操作
    官方推荐两个都启用
    如果对数据不敏感,可以单独用RDB
    不推荐单独使用AOF,因此存在一些BUG
    如果只是做纯内存缓存,可以两个都不用

    缓存穿透
    一般redis是用来缓存数据的,当并发量大或者遭受攻击时,一个请求来redis查找一个不存在的数据,此时redis会向主数据库查找数据并缓存,这就导致redis不断的向主数据库查询数据,这样无疑加大了主数据库压力;

    解决方案:

    对空结果缓存:如果一个查询返回是数据是空,仍然对空结果进行缓存,并设置很短的空结果过期时间,一般为5分钟;
    设置可访问的白名单:使用bitmaps类型定义一个可以访问的白名单,每次访问和bitmaps里面ip做比较,如果访问的ip不在bitmaps里面,进行拦截,不允许访问;
    布隆过滤器:原理与上面类似,但是效率高一些;
    实时监控:当发现redis缓存命中率急速降低时,可以和运维人员配合,排查访问对象和数据,设置黑名单限制服务;
    但是一般遇到这个情况是遭遇黑客攻击了,第一时间报警最重要;

    缓存击穿
    当redis中并没有大量的key过期,只是某个key过期了,但此时某个热词出现,导致访问量突然加大,同时访问这个过期的key,此时对数据库的压力就会超载,导致缓存击穿;

    解决方案:

    预先设置热门数据:在redis访问高峰之前,把一些热门数据提前存入到redis缓存里面,加大这些热门key的缓存时长;
    实时调整:现场监控某些key的热门程度,实时调整这些key的过期时间;
    使用锁:在缓存失效的时候(判断取出来的key是否是空),不是立即去load db;先对这个缓存设置排他锁,然后再查询数据库,如果别的线程已经在查询这个数据,则需先等待其他线程查询完毕,此方式可以完全解决缓存击穿问题,但是效率较低;

  • 相关阅读:
    代码随想录总结
    (论文翻译)UFO: Unified Feature Optimization——UFO:统一特性优化
    前端css样式小知识点(大杂烩)
    废纸篓清空的文件怎么恢复?
    Synchronized锁升级原理与过程深入剖析
    单商户商城系统功能拆解26—营销中心—限时秒杀
    OpenStack学习笔记(二)
    大厂搅局网约车,聚合平台别有用心?
    CRM项目记录(四)
    [Linux入门]---进程优先级
  • 原文地址:https://blog.csdn.net/xiaocaij_icai/article/details/126511297