一个程序员的江湖

新手村只Redis

Posted by GuiLing on September 21, 2019

初出茅庐

Redis常用数据结构

  • String 最基本的数据类型
  • List 列表按照String插入的顺序排序

  • Hash String元素组成的字典适合存储对象
  • Set String 元素组成的无序集合通过Hash表实现
  • Sorted Set 通过分数为集合中的元素从小到大排序
  • 不常用的计数HyperLogLog 用于存储地理位置的GEO

从海量key中查询某一个固定前缀的key(当前redis正在给线上业务提供服务约有2千万个key)

  • SCAN 0 guiling* count 30
  • SCAN cursor 【match pattern】 【count】
  • count 制定每次返回多少个元素,但是只是建议
  • cursor 为每次查询的游标,制定从0开始,以返回的游标为下次开始查询的位置,返回0查询结束

实现分布式锁

  • SET key value 【ex(单位秒) /px(毫秒)】【NX(不存在时插入) XX(存在时插入)】

  • SET key value ex 10 nx 设置key是设置过期时间
  • SETNX key value 设置key
  • expire key expire 给key制定过期时间

大量key同时过期

  • 在过期时间上加一个随机值

使用Redis做异步队列

  • 使用List做为队列 RPUSH生产消息 LPUSH消费消息
  • 缺点:没有等待,队列有值就消费,没有值就返回

做延时等待队列(只能有一个客户端消费)

  • 使用List做为队列 RPUSH生产消息
  • 使用BLPOP key expire 使用BLPOP消费在阻塞等待消息,直到超时

做延时等待队列(多个客户端监听消费)pub/sub模式

  • subscribe myTopic 订阅一个消息

  • publish myTopic "hello !" 发布一个消息

    • 缺点:发布时无状态的,无法保证消息到达,需要使用专业消息队列解决

Redis持久化方式之RDB

  • redis.conf
    • save 900 1->900秒内有一条数据写入就进行备份(bgsave)
    • save 300 10->300秒内有十条数据写入就进行备份
    • stop-write-on-bgsave-error yes ->当备份进程出错时主进程停止写入操作,保证持久化数据一致
    • rdbcompression yes-> 备份时进行压缩,见设置成no
    • 禁用RDB save “”
  • 生产RDB文件
    • save 阻塞生产RDB文件
    • bgsave Fork出一个子进程生产RDB
  • 自动触发RDB时机
    • redis.conf中的 save m n (使用的是bgsave)
    • 主从复制时
    • 执行Debug Reload
    • 执行shoutdown 且没有开启AOF
  • BGSAVE的原理(此处保留一个疑问当持久化数据时新产生的数据如何同步)

    • 判断当前是否有bgsave子进程,如果有就报错

    • 调用系统fork()创建子进程,Linux使用的fork子进程方式是Copy-On-Write

    • 父进程继续接受客户端的处理请求,子进程开始将内存中的数据写入到磁盘

    • 当父进程需要进行写入时会copy一个副本进行写入而不是写入到共享的内存

    • 子进程复制完成之后替换掉之前的RDB文件

      屏幕快照 2019-09-21 下午5.35.16

Redis持久化之AOF

  • appendonly yes 开启aof 持久化
  • appendfsync always(一旦缓存区内容变化就同步)/eversec(每秒)/no(操作系统决定,一般是缓存区满)
  • AOF可以进行压缩
    • 直接对当前内存数据进行分析生产命令写入到新的AOF文件,不依赖老的AOF文件
    • 新的请求主进程会继续写到旧的AOF中和内存中
    • 主进程受到子进程完成AOF重写的信号,新的变动写入到新的AOF中
    • 替换旧的AOF

屏幕快照 2019-09-21 下午5.48.36

数据恢复

屏幕快照 2019-09-21 下午5.48.46

混合的持久化方式

  • BGSAVE 做镜像全量持久化,AOF做增量持久化

Pipeline

  • Pipeline批量执行指令,节省多次往返IO的时间
  • 有顺序以来的指令还是建议分批次发送

Redis的全量同步机制

  • Salve发送同步请求到Master
  • Master受到请求后将内存数据写入到文件中
  • Master将在持久化期间的变更数据写入到缓存中
  • Master将持久化文件发送给Salve
  • Salve接受到Master的持久化文件后加载到内存中生产AOF指令替换旧的AOF
  • Master将同步期间的写命令发送给Salve
  • 屏幕快照 2019-09-21 下午6.16.12

Redis的增量同步

  • Master进行写操作
  • 判断是否是写操作
  • 将操作追加到AOF
  • 将数据传播给其他Salve

Redis Sentinel(哨兵)

  • 监控:检查主服务器是否正常
  • 提醒:通过API向管理员发送故障消息
  • 自动故障迁移:主从切换

Gossip流言协议

  • 每个节点随机的和其他节点通信,最终所有节点达到一致
  • 种子节点定期随机向其他节点发送节点列表和要传播的消息
  • 不保证信息一定传递给所有节点,但最终趋于一致

Redis集群原理

  • 一致性Hash算法

屏幕快照 2019-09-21 下午6.38.24

缓存穿透

  • 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时被动写的,并且出于容错考虑,如果从存储层查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到存储层去查询,失去了缓存的意义。在流量大时,可能DB就挂掉了,要是有人利用不存在的key频繁攻击我们的应用,这就是漏洞。

  • 解决方案:

    • 有很多种方法可以有效地解决缓存穿透问题,最常见的则是采用布隆过滤器,将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被 这个bitmap拦截掉,从而避免了对底层存储系统的查询压力
    • 另外也有一个更为简单粗暴的方法(我们采用的就是这种),如果一个查询返回的数据为空(不管是数 据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。

缓存雪崩

  • 缓存雪崩是指在我们设置缓存时采用了相同的过期时间,导致缓存在某一时刻同时失效,请求全部转发到DB,DB瞬时压力过重雪崩
  • 解决方案:
    • 缓存失效时的雪崩效应对底层系统的冲击非常可怕。大多数系统设计者考虑用加锁或者队列的方式保证缓存的单线 程(进程)写,从而避免失效时大量的并发请求落到底层存储系统上。这里分享一个简单方案就时讲缓存失效时间分散开,比如我们可以在原有的失效时间基础上增加一个随机值,比如1-5分钟随机,这样每一个缓存的过期时间的重复率就会降低,就很难引发集体失效的事件

缓存击穿

  • 对于一些设置了过期时间的key,如果这些key可能会在某些时间点被超高并发地访问,是一种非常“热点”的数据。这个时候,需要考虑一个问题:缓存被“击穿”的问题,这个和缓存雪崩的区别在于这里针对某一key缓存,前者则是很多key。缓存在某个时间点过期的时候,恰好在这个时间点对这个Key有大量的并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。

  • 解决方案:

      1. 使用互斥锁(mutex key): 这种解决方案思路比较简单,就是只让一个线程构建缓存,其他线程等待构建缓存的线程执行完,重新从缓存获取数据就可以了

        屏幕快照 2019-09-22 下午3.45.26

      2. “提前”使用互斥锁(mutex key):

        在value内部设置1个超时值(timeout1), timeout1比实际的memcache timeout(timeout2)小。当从cache读取到timeout1发现它已经过期时候,马上延长timeout1并重新设置到cache。然后再从数据库加载数据并设置到cache中。

      3. “永远不过期”:

        这里的“永远不过期”包含两层意思:

        ​ (1) 从redis上看,确实没有设置过期时间,这就保证了,不会出现热点key过期问题,也就是“物理”不过期。

        ​ (2) 从功能上看,如果不过期,那不就成静态的了吗?所以我们把过期时间存在key对应的value里,如果发现要过期了,通过一个后台的异步线程进行缓存的构建,也就是“逻辑”过期

        屏幕快照 2019-09-22 下午3.50.33

      4. 资源保护:

        ​ netflix的hystrix,可以做资源的隔离保护主线程池,如果把这个应用到缓存的构建也未尝不可。

        屏幕快照 2019-09-22 下午3.50.02