Redis

Redis

AOF/RDB

RDB

• 特性（是将支持当前数据的快照存成一个数据文件的持久化机制。）

  • 1.在生成快照时，将当前进程fork出一个子进程.
  • 2.然后再子进程中循环所有的数据，将数据写入到二进制文件中。
  • 3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

• 优点

  • 1.一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这样非常方便进行备份。比如你可能打算每1天归档一些数据。
  • 2.方便备份的同时，我们也很容易的将一个RDB文件移动到其他存储物质上。
  • 3.RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

• 劣势

  • 如果你想在服务器上避免数据的丢失，那么RDB就不适合了，因为RDB文件需要保存整个数据集的状态，因为你可能会在5分钟才保存一次RDB文件，在这种情况下，一旦发生故障停机，你可能会损失好几分钟的数据。
    每次在保存RDB的时候，Redis都要fork出一个子进程，并由子进程来进行实际的持久化工作，如果在数据集比较庞大时，fork可能会非常耗时，造成服务器在那么一瞬间会停止处理客户端；虽然AOF重写也需要进行fork，但AOF重写的执行时间间隔有多长，数据的耐久性都不会有任何损失。

AOF

• 特性

  • Redis 默认不开启。它的出现是为了弥补RDB的不足（数据的不一致性），所以它采用日志的形式来记录每个写操作，并追加到文件中。Redis 重启的会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。AOF的工作原理就是是将写操作追加到文件中，文件的冗余内容会越来越多。所以Redis 新增了重写机制。当AOF文件的大小超过所设定的最大值时，Redis就会对AOF文件的内容压缩。

• 优点

  • 1.一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这样非常方便进行备份。比如你可能打算每1天归档一些数据。
  • 2.方便备份的同时，我们也很容易的将一个RDB文件移动到其他存储物质上。
  • 3.RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。

• 劣势

  • 如果你想在服务器上避免数据的丢失，那么RDB就不适合了，因为RDB文件需要保存整个数据集的状态，因为你可能会在5分钟才保存一次RDB文件，在这种情况下，一旦发生故障停机，你可能会损失好几分钟的数据。
    每次在保存RDB的时候，Redis都要fork出一个子进程，并由子进程来进行实际的持久化工作，如果在数据集比较庞大时，fork可能会非常耗时，造成服务器在那么一瞬间会停止处理客户端；虽然AOF重写也需要进行fork，但AOF重写的执行时间间隔有多长，数据的耐久性都不会有任何损失。

分布式锁

存在的风险

• 如果存储锁对应key的那个节点挂了的话，就可能存在丢失锁的风险，导致出现多个客户端持有锁的情况，这样就不能实现资源的独享了。
• 客户端A从master获取到锁，在master将锁同步到slave之前，master宕掉了（Redis的主从同步通常是异步的）。主从切换，slave节点被晋级为master节点
  客户端B取得了同一个资源被客户端A已经获取到的另外一个锁。导致存在同一时刻存不止一个线程获取到锁的情况。

特点

• 互斥性

  • 在任意时刻，只有一个客户端能持有锁。

• 不能死锁

  • 客户端在持有锁的期间崩溃而没有主动解锁，也能保证后续其他客户端能加锁。

• 容错性

  • 只要大部分的Redis节点正常运行，客户端就可以加锁和解锁。

缓存雪崩/穿透

缓存雪崩

• 描述

  • 部分请求命中缓存，而绝大多数请求对数据库进行请求，从而造成数据库宕机

• 解决方案

  • 1、事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃
  • 2、事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL被打死
  • 3、事后：redis持久化，快速恢复缓存数据

缓存穿透

• 描述

  • 发送的请求无法在缓存中获取，直接到数据库中进行查询，数据库瞬间访问量过高造成宕机

• 解决方案

  • 查询不到的数据也放到缓存

批量命令Pipeline

区别

• 1、原生批量命令是原子的，Pipeline 是非原子的。
• 2、原生批量命令是一个命令对应多个 key，Pipeline 支持多个命令。
• 3、原生批量命令是 Redis 服务端支持实现的，而 Pipeline 需要服务端和客户端的共同实现

适用场景

• Peline是 Redis 的一个提高吞吐量的机制，适用于多 key 读写场景，比如同时读取多个key 的value，或者更新多个key的value，并且允许一定比例的写入失败、实时性也没那么高，那么这种场景就可以使用了。比如 10000 条一下进入 redis，可能失败了 2 条无所谓，后期有补偿机制就行了，像短信群发这种场景，这时候用 pipeline 最好了。

注意点

• Pipeline是非原子的，在上面原理解析那里已经说了就是 Redis 实际上还是一条一条的执行的，而执行命令是需要排队执行的，所以就会出现原子性问题。
• Pipeline中包含的命令不要包含过多。
• Pipeline每次只能作用在一个 Redis 节点上。
• Pipeline 不支持事务，因为命令是一条一条执行的。

数据类型

• 1：STRING，字符串，整数或者浮点数、
  对整个字符串或者字符串的其中一部分执行操作
  对整数和浮点数执行自增或者自减操作。
• 2：LIST，链表，从两端压入或者弹出元素读取单个或者多个元素进行修剪，只保留一个范围内的元素。
• 3：SET，无序集合，添加、获取、移除单个元素
  检查一个元素是否存在于集合中计算交集、并集、差集从集合里面随机获取元素。
• 4：HASH，包含键值对的无序散列表，添加、获取、移除单个键值对获取所有键值对检查某个键是否存在。
• 5：ZSET，有序集合，添加、获取、删除元素
  根据分值范围或者成员来获取元素计算一个键的排名。

发布订阅功能

发布者和订阅者。

Redis的发布与订阅功能由publish、subscribe、psubscribe等命令组成。通过执行publish命令可以发布消息；通过执行subscribe命令，客户端可以订阅一个或多个频道；通过执行psubscribe命令，客户端可以订阅一个或多个模式。

内存

内存

• 对象内存

  • 键值占用内存

  • 值value占用内存

    • String
    • List、Hash、Set、Stream
    • ZSet

• 缓冲区

  • AOF重写缓冲
  • 复制积压缓冲
  • 客户端输入缓冲
  • 客户端输出缓冲
  • 普通客户缓冲
  • 订阅客户缓冲
  • 主从复制缓冲

• 自身内存

内存管理

• 内存上线管理

  • 单机多实例部署的时候需要预留一定的内存空间，同时做好内存碎片与内存使用情况监控

• 内存回收策略

  • 过期KEY淘汰策略（Redis可以通过给键设置过期时间，当过期后，redis可以淘汰出键值对，具体是通过如下的2种方式淘汰。）
  • 1、惰性删除。当客户端访问的时候，如果键的过期了，就会将相应的键值对删除。但是这种方式删除，会造成大量未被访问的过期的键未被删除，为此redis提供了如下的定时删除的策略。同bigkey的删除操作可能会堵塞redis一样，惰性删除bigkey也一样，Redis 4.0 开始，如果删除的可以是bigkey，那么会使用异步删除策略。这也是我们需要避免使用bigkey的原因之一。
  • 2、定时删除。默认情况下，Redis 每 100 毫秒会删除一些过期 key

  -内存溢出内存回收策略

  • 1、LRU淘汰算法
    - 优先淘汰最近最少使用的数据
  • 2、 LFU淘汰算法
    - 最近访问频次淘汰数据

集群架构模式

单机版

• 问题

  • 1、内存容量有限。
  • 2、处理能力有限 。
  • 3、无法高可用

• 主从复制

  • 描述

    • Redis 的复制（replication）功能允许用户根据一个 Redis 服务器来创建任意多个该服务器的复制品，其中被复制的服务器为主服务器（master），而通过复制创建出来的服务器复制品则为从服务器（slave）

  • 特点

    • 1、master/slave 角色
    • 2、master/slave 数据相同
    • 3、降低 master 读压力在转交给从库

  • 问题

    • 1、无法保证高可用；
    • 2、没有解决 master 写的压力

哨兵

• 描述

  • 1、监控（Monitoring）： Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。
  • 2、提醒（Notification）： 当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。
  • 3、自动故障迁移（Automatic failover）： 当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作。

• 特点

  • 1、保证高可用
  • 2、监控各个节点
  • 3、自动故障迁移

• 缺点

  • 主从模式，切换需要时间丢数据
    没有解决 master 写的压力

集群（proxy型）

• 描述

  • Twemproxy 是一个 Twitter 开源的一个 redis 和 memcache 快速/轻量级代理服务器； Twemproxy 是一个快速的单线程代理程序，支持 Memcached ASCII 协议和 redis 协议。

• 特点

  • 1、多种 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins
  • 2、支持失败节点自动删除
  • 3、后端 Sharding 分片逻辑对业务透明，业务方的读写方式和操作单个 Redis 一致

• 缺点

  • 增加了新的 proxy，需要维护其高可用。
    failover 逻辑需要自己实现，其本身不能支持故障的自动转移可扩展性差，进行扩缩容都需要手动干预

集群（直连型）

• 描述

  • Redis-Cluster采用无中心结构，每个节点保存数据和整个集群状态,每个节点都和其他所有节点连接

• 特点

  • 1、无中心架构（不存在哪个节点影响性能瓶颈），少了 proxy 层。
  • 2、数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布。
  • 3、可扩展性，可线性扩展到 1000 个节点，节点可动态添加或删除。
  • 4、高可用性，部分节点不可用时，集群仍可用。通过增加 Slave 做备份数据副本
  • 5、实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave到 Master 的角色提升。

• 缺点

  • 1、资源隔离性较差，容易出现相互影响的情况。
  • 2、数据通过异步复制,不保证数据的强一致性

应用场景

-1、缓存
-2、消息对列
-3、分布式锁
-4、定时任务
-5、服务发现
-6、分布式全局唯一ID
-7、频率控制
-8、计数器
-9、排行榜