Redis 学习笔记01

129 阅读6分钟
  • 非关系型数据库:Nosql,泛指非关系型数据库,传统关系型数据库对于超大规模和高并发的SNS类型的WEB2.0已经力不从心,Nosql解决了大规模数据集合和多重数据种类带来的挑战,尤其是大数据带来的难题。
    • SNS : social network service 社交网络服务
  • 单线程模型
    • 我们的redis-client在操作的时候,会产生具有不同事件类型的socket。在服务端,有一段I/O多路复用程序,将socket们放置于队列之中。然后文件事件分派器,依次去队列中去取,转发到不同的事件处理器之中。
      • 多路复用机制是为了有效利用通信线路,希望一个信道同时传输多个传输多路信号,这就是多路复用技术。
  • 持久化
    • aof Append Only File
      • Redis 需要手动开启AOF持久化方式,默认是每秒将写操作日志追加到AOF文件中。
      • AOF 的数据完整性比RDB高,但记录内容多了,会影响数据恢复的效率。
      • Redis 针对 AOF文件大的问题,提供重写的瘦身机制。
    • rdb Redis DataBase
      • Redis 默认开启RDB持久化方式,在指定的时间间隔内,执行指定次数的写操作,则将内存中的数据写入到磁盘中。
      • RDB 持久化适合大规模的数据恢复但它的数据一致性和完整性较差。
    • 如果对数据的安全性要求非常高的话,那么最好俩个一起开启,如果能允许分钟内的数据丢失的话,就选择RDB
    • 如果数据需要时常备份的话,最好开启RDB
      • 俩中可以同时开启,也可以只使用一个,但是如果都开启的话,Redis重启时只会加载AOF文件来恢复数据
    • 若只打算用Redis 做缓存,可以关闭持久化。
  • rewrite
    • aof里存放了所有的redis 操作指令,当aof文件达到一定条件或者手动命令都可以触发rewrite。
    • rewrite之后aof文件会保存keys的最后的状态,清除掉之前冗余的,来缩小这个文件
  • 主从
    • Redis支持主从同步。数据可以从主服务器向任意数量的从服务器上同步,同步使用的是发布/订阅机制。
  • cluster
    • Redis Cluster是Redis在3.0版本推出的分布式解决方案。Redis Cluster由多个Redis节点组成。不同节点之间数据无交集,每个节点对应多个数据分片。节点内部分为主备节点,通过主备复制的方式保证数据的一致性。一个主节点可以有多个从节点,主节点提供读写服务,从节点提供读服务。
  • 数据类型
    • string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)。
  • 缓存常见问题
    • 缓存预热
      • 其实这个不是一个问题,是一种机制,在上线前先将需要缓存的数据放到缓存中去,这个的实现很简单,可以在启动的时候放(数据比较小),做一个开关(一个隐秘的接口),定时刷新缓存
    • 缓存更新
      • 这也不是一个问题,是一种机制,怎么样保证缓存中的key是实时有效的,以及及时的更新数据资源
      • 监测机制 : 定时去监测Redis,查看过期的缓存
    • 击穿
      • 缓存击穿是指热点key在某个时间点过期的时候,而恰好在这个时间点对这个Key有大量的并发请求过来,从而大量的请求打到db。
      • 双重校验(Dubbo Check)类似线程安全的懒汉单例模式实现,保证只会有一个线程去访问数据库
    • 穿透
      • 发生场景 : 此时要查询的数据不存在,缓存无法命中所以需要查询完数据库,但是数据是不存在的,此时数据库肯定会返回空,也就无法将该数据写入到缓存中,那么每次对该数据的查询都会去查询一次数据库
      • 解决方案 :
        • 布隆过滤 : 我们可以预先将数据库里面所有的key全部存到一个大的map里面,然后在过滤器中过滤掉那些不存在的key.但是需要考虑数据库的key是会更新的,此时需要考虑数据库 --> map的更新频率问题
        • 缓存空值 : 哪怕这条数据不存在但是我们任然将其存储到缓存中去,设置一个较短的过期时间即可,并且可以做日志记录,寻找问题原因
    • 雪崩
      • 发生场景 : 当Redis服务器重启或者大量缓存在同一时期失效时,此时大量的流量会全部冲击到数据库上面,数据库有可能会因为承受不住而宕机
      • 解决方案 :
        • 均匀分布 : 我们应该在设置失效时间时应该尽量均匀的分布,比如失效时间是当前时间加上一个时间段的随机值
        • 熔断机制 : 类似于SpringCloud的熔断器,我们可以设定阈值或监控服务,如果达到熔断阈值(QPS,服务无法响应,服务超时)时,则直接返回,不再调用目标服务,并且还需要一个检测机制,如果目标服务已经可以正常使用,则重置阈值,恢复使用
        • 隔离机制 : 类似于Docker一样,当一个服务器上某一个tomcat出了问题后不会影响到其它的tomcat,这里我们可以使用线程池来达到隔离的目的,当线程池执行拒绝策略后则直接返回,不再向线程池中增加任务
        • 限流机制 : 其实限流就是熔断机制的一个版本,设置阈值(QPS),达到阈值之后直接返回
        • 双缓存机制 : 将数据存储到缓存中时存储俩份,一份的有效期是正常的,一份的有效期长一点.不建议用这个方案,因为比较消耗内存资源,毕竟Redis是直接存储到内存中的。
    • 服务降级
      • 服务降级是不得已而为之的,在关键的时候丢卒保帅,保证核心功能正常运行
      • 服务拒绝 : 直接拒绝掉非核心功能的所有请求,其实基本就是直接废弃掉某些模块
      • 服务延迟 : 将请求加入到线程池中或队列中,延迟执行这些请求
    • 数据一致性
      • 应用先写到数据库,然后更新redis
      • 应用先写到数据库,然后其它daemon同步到redis
        • 优点:redis启动不用处理redis数据和数据库不一致
        • 缺点:redis启动给数据库很大的读压力
  • 一致性hash和分布式锁有点难下次看