Redis

1：简介

- Redis4.0以及之后的版本中引入了惰性删除（也叫异步删除），意思就是我们可以使用异步的方式对Redis中的数据进行删除操作；
- Redis6.0中新增了多线程的功能来提高IO的读写性能，它的主要实现思路是将主线程的IO读写任务拆分给一组独立的线程去执行，这样就可以使用多个socket的读写并行化了，但Redis的命令依旧是主线程串行执行的。
- Redis6.0是默认禁用多线程
- Redis6.0是支持本地缓存来替代EHCache/Caffeine
- 总结：本文介绍了Redis在4.0之前单线程依然快的原因：基于内存操作、数据结构简单、IO多路复用和非阻塞IO、避免了不必要的线程上下文切换。并且在Redis4.0开始支持多线程，主要体现在大数据的异步删除方面，例如：unlink key、flushdb async、flushall async等。而Redis6.0的多线程则增加了对IO读写的并发能力，用于更好的提升Redis的性能。
- 数据库的缓存一般针对的是查询的内容，而且粒度也比较小。一般只有表中数据没有发生变动的时候，数据库对应的cache 才会发挥作用。但这并不能减少对数据库产生的增删改查的IO压力。
- 实现了对热点数据的高速缓存，提高应用的响应数据，极大缓解后端数据库的压力。
- 完全基于内存，绝大部分请求是纯粹的内存操作，执行效率高。
- 单进程单线程模型的K-V数据库，由C语言编写。读写的时候都不会受到硬盘IO的限制。
- 数据结构简单，对数据操作也简单，其存储结构就算键值对，类似于HashMap。
- 采用单线程，单线程也能处理高并发请求，想多核也可启动多实例。这里的单线程指的是主线程，包括IO事件的处理，以及IO事件的相关请求业务处理。
- 使用多路I/O复用模型，非阻塞IO。
- 100000+QPS（QPS即query per seconds，每秒查询的次数。）

2：Memcache 和 Redis 的区别

• Memcache：代码层次类似Hash
  • 支持简单数据类型。
  • 不支持数据持久化存储。 一旦服务器宕机的时，数据是没办法保存下来的。
  • 不支持主从同步。
  • 不支持分片。大数据分布到多个物理节点的方案。
• Redis
  • 数据类型丰富。
  • 支持数据磁盘持久化存储。
  • 支持主从。
  • 版本3.0之后支持分片。
• 没有最好的技术，只有更合适的技术。
  • 简单的Key，Value 选择Memcache。
  • 有持久化需求的选择Redis。
• Redis 数据类型
  • String ：最基本的数据类型，二进制安全。
  • Hash：String元素组成的字典，适合用于存储对象。
  • List：列表，按照String元素插入顺序排序。
  • Set：String 元素组成的无序集合，通过哈希表实现，不允许重复。
  • Sorted Set ：通过分数来为集合中的成员进行从小到大的排序。
  • 用于计数的HyperLogLog，用于支持存储地理位置信息的Geo。
• 从海量Key里面查询某一固定前缀的key
  • 摸清数据规模，数据量，即问清楚边界。
    • keys pattern ：查找所有符合给定模式pattern的key，eg：key dic* 。缺点：一次性返回所有匹配的key，键的数量过大会使服务卡顿，对于内存消耗和Redis都是一个隐患。
    • SCAN cursor [MATCH pattern] [Count count]
    • 列子：scan 0 match k1* count 10;开始迭代，返回模糊查询k1的key，一次大概率的返回10个。
      • 返回了两个东西
      • 1）cursor
      • 2）value
      • cursor则是我们下次将带进去再次查询的游标。
    • 基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程。
    • 以0作为游标开始一次新的迭代，直到命令返回游标0完成一次便利。
    • 不保证每次执行都返回某个给定数量的元素，支持模糊查询。
    • 一次返回的数量不可控，只能是大概率符合count 参数。
    • 返回的cursor 并不一定是递增的；Key可能获取到是相同的。
    • 因为是分批次查找的，所以花费的时间比Keys更长。
• 通过Redis实现分布式锁
  • 需要解决的问题如下
    • 互斥性：任意时刻只能有一个客户端获取锁，不能同时有两个或多个同时获取到锁。
    • 安全性：锁只能被持有的客户端进行删除；修改。
    • 死锁：获取锁的客户端因为某些原因而宕机而没有释放锁。
    • 容错：当部分节点宕机的时候，客户端仍然能获取锁和释放锁。
  • 实现方案：SET key value [EX seconds][PX milliseconds][NX|XX]
    • eg：set lockKey 12345 ex 10 nx；当key存在时候，就会操作失败。
    • EX seconde：设置键的过期时间为秒。
    • PX milliseconds ：设置键的过期时间为milliseconds毫秒。
    • NX ：只在键不存在时，才对键进行设置操作。
    • XX：只在键存在时，才对键进行设置操作。
    • SET操作成功完成时，返回OK，否则返回nil。
• 大量的key同时过期注意事项
  • 集中过期，由于清楚大量的key很耗时，会出现短暂的卡顿现象。
    • 解放方案：在设置key的过期时间的时候，给每个key加上随机值。
• Redis做异步队列
  • 使用List数据类型最为队列，RPUSH 生产消息，LPOP消费消息。
    • 缺点1：没有等待队列里面有值就直接消费。
      • 弥补1：可以通过在应用层引入Sleep机制去调用LPOP重试。
      • 弥补2：BLPOP key [key…] timeout；阻塞知道队列有消息或者超时。
        • 缺点：只能供一个消费者消费？。（待确定一个是什么，因为测试是可以支持多个客户端进行阻塞消费）
          • 弥补：pub/sub：主题订阅者模式
            • 发送者(pub)发送消息，订阅者（sbu）接收消息。
            • 订阅者可以订阅任意数量的频道。
            • 缺点：消息的发布是无状态的，无法保证消息是否被接收到，是否在传输过程种丢失；对于发布者来说，消息是即发即失的。此时如果某个消费者在生产者发送消息时下线，重新上线之后是接收不到该消息的。可使用专业的消息队列（kafka）来解决。
• Redis 做持久化
  • RDB（快照）持久化：保存某个时间点的全量数据快照。
    • 手动触发
      • Save：阻塞Redis的服务器进程，知道RDB文件被创建完毕。很少被使用，因为SAVE操作是在主线程种保存快照，由于REDIS是用一个主线程来处理所有的请求，这种方式会阻塞所有的请求。
      • BGSAVE：Fork出一个子进程来异步创建RDB文件，不阻塞服务器进程。可通过类似JAVA定时器来调用进行BGSAVE操作。
    • 自动触发
      • 根据redis.conf配置里的SAVE m n定时触发（用的是GBSAVE）
      • 主从复制时，主节点自动触发。
      • 执行Debug Reload
      • 执行Shutdown且没有开启AOP持久化。
  • RDB持久化缺点
    • 内存数据的全量同步，数据量大会由于I/O而严重影响性能。
    • 可能会因为Redis挂掉而丢失从当前至最近一次快照期间的数据。
      
  • AOF（Append-Only-File）持久化：保存写状态。默认是关闭的。
    • 记录下除了查询以外的所有变更数据库状态的指令
    • 以append的形式追加保存到AOF文件种（增量）
  • 日志重写解决AOF文件大小不断增大的问题，原理如下：
    • 调用fork（），创建一个子进程。
    • 子进程把新的AOF写到一个临时文件里，不依赖原来的AOF文件。
    • 主进程出须将新的变动同时写到内存和原来的AOF里。
    • 主进程获取子进程重写AOF的完成信号，往新AOF同步增量变动。
    • 使用新的AOF文件替换掉旧的AOF文件。
  • RDB和AOF的优缺点
    • RDB优点：全量数据快照，文件小，恢复快。
    • RDB缺点：无法保存最近一次快照之后的数据。
    • AOF优点：可读性高，适合保存增量数据，数据不易丢失。
    • AOF缺点：文件体积大，恢复时间长。
  • Redis 4.0版本之后的RDB-AOF混合持久化方式。RDB作为全量备份，AOF作为增量备份。
    • GBSAVE做镜像全量持久化，AOF做增量持久化。
      
• Copy-ON-Write
  • 如果又多个调用者同时要求相同资源（如内存或磁盘上的数据存储），它们会共同获取相同的指针指向相同的资源，直到某个调用者试图修改资源的内容时，系统才会真正复制一份专用副本给该调用者，而其它调用者所见到的最初的资源仍然保持不变。
• 使用Pipeline生成大量的redis数据
  • Pipeline 和 linux的管道类似。
  • Redis基于请求/响应模型，单个请求处理需要一一应答。
  • Pipeline批量执行指令，节省多次IO往返的时间。
  • 有顺序依赖的指令建议分批发送。
  • 执行的指令之间没有依赖的相关性，如果有的话建议还是通过Pipeline分批去发送。
• Redis的同步机制
  • 全同步过程
    • Salve 发送 sync命令道Master。
    • Master 启动一个后台进程，将Redis种的数据快照保存到文件中。
    • Master 将保存数据快照期间接收到的写命令缓存起来。
    • Master 完成写文件操作后，将该文件发送给Salve。
    • 使用新的AOF 文件替换掉旧的AOF 文件。
    • Master 将这期间收集的增量写命令发送给Salve端。
  • 增量同步过程
    • Master 接收到用户的操作指令，判断是否需要传播到Slave（增删改操作）。
    • 将操作记录追加到AOF文件。
    • 将操作传播到其它Slave：1，对齐主从库；2，往响应缓存写入指令。
    • 将缓存中的数据发送给Slave。
  • 解决主从同步Master 宕机后的主从切换问题：
    • 监控：检查主从服务器是否运行正常
    • 提醒：通过API向管理员或者其他应用程序发送故障通知。
    • 自动故障迁移：主从切换。
• 流言协议Gossip
  • 在杂乱无章中寻求一致。
    • 每个节点都随机地与对方通信，最终所有节点的状态达成一致。
    • 种子节点定期随机向其它系欸但发送节点列表以及需要传播的消息。
    • 不保证信息一定会传递给所有节点，但是最终会趋于一致。
• 集群原理
  • 分片：按照某种规则去划分数据的Key，分散存储在多个节点上。
  • 常规的按照哈希划分无法实现节点的动态增减。
  • 一致性哈希算法：对2^32取模，将哈希值空间组织成虚拟的圆环。将数据Key使用相同的函数Hash计算出哈希值。
  • 问题：Hash环数据倾斜问题。
    • 解决方案：引入虚拟节点。

缓存穿透

什么是缓存穿透？

• 缓存可以说是我们对数据库的一道保护墙，缓存穿透相当于是冲破了我们的保护墙， 每个缓存都有一个缓存的 Key， 当相同的 Key 过来时，我们就直接取缓存中的数据返回给调用方，而不用去查询数据库，如果调用方传来的永远都是我们缓存中不存在的 Key，这样每 次都需要去数据库中查询一次，就会导致数据库压力增大，这样缓存就失去意义了，这就是所谓的缓存穿透。

缓存穿透的危害

• 当大量的请求过来时， 首先会从缓 存巾去寻找数据，当缓存中没有对应的数据时又转到了数据库中去寻找，瞬时数据库的压
  力会很大，相当于没有用到缓存，同时还增加了去缓存中查找数据的时间。

解决方案

• 如果查询数据库也为空的时候，把这个 key 缓存起来，这样在下次请求过来的时候就可以走缓存了。 当然这种方案有个弊端，那就是请求过来的 key 必须大部分相同，如果受到攻击的话，每次的 key 肯定不是固定的，只要不固定 key，这个方案就没用。
• 可以用缓存 k町的规则来做一些限制，当然这种只适合特定的使用场景，比如我们 查询商品信息，我们商品存储在 Mongodb 中 ， Mongodb 有一个 id 是自动生成的， 它有一定的生成规则，如果是直接根据 id 查询商品，在查询之前我们可以对这个 id 做认证，看是不是符合规范，当不符合的时候就直接返回默认的值，既不用去缓存 中查询，也不用操作数据库了。 这种方案可以解决一部分问题，使用场景比较少。
• 利用布隆过滤器来实现对缓存 key 的检验，需要将所有可能缓存的数据 Hash 到一个 足够大的 BitSet 中，在缓存之前先从布隆过滤器中判断这个 key 是否存在，然后做 对应的操作

缓存雪崩

什么是缓存雪崩?

• 就是在某一时刻，大量缓存同时失效导致所有请求都去查询数据库，导致数 据库压力过大，然后挂掉的情况。 缓存穿透比较严重的时候也会导致缓存雪崩的发生。

缓存雪崩的危害

• 缓存雪崩最乐观的情况是存储层能抗住，但是用户体验会受到影响，数据返回慢，当压力过大时会导致存储层直接挂掉，整个系统都受影响。 对于要做到 99.99% 高可用的产品，是绝对不允许缓存雪崩的发生。

解决方案

• 缓存存储高可用， 比如 Redis 集群，这样就能防止某台 Redis 挂掉之后所有缓存丢失 导致的雪崩问题。
• 缓存失效时间要设计好，不同的数据有不同的有效期，尽量保证不要在同一时间失 效，统一去规划有效期，让失效时间分布均匀即可。
• 对于一些热门数据的持续读取，这种缓存数据也可以采取定时更新的方式来刷新缓 存，避免自动失效。
• 服务限流和接口限流，如果服务和接口都有限流机制，就算缓存全部失效了，但是 请求的总量是有限制的，可以在承受范围之内，这样短时间内系统响应慢点，但不 至于挂掉，影响整个系统。
• 从数据库获取缓存需要的数据时加锁控制 ，本地锁或者分布式锁都可以。 当所有请 求都不能命中缓存，这就是我们之前讲的缓存穿透，这时候要去数据库中查询，如 果同时并发的量大，也是会导致雪崩的发生，我们可以在对数据库查询的地方进行 加锁控制，不要让所有请求都过去，这样可以保证存储服务不挂掉。