Redis 常用知识

Redis 介绍

• Redis 一个开源的使用ANSI C语言编写、遵守BSD协议，内存中的数据结构存储系统，它可以用作Key-Value数据库、缓存和消息中间件，并提供多种语API。
  支持多种数据结构，如 字符串（strings），散列（hashes），列表（lists），集合（sets），有序集合（sorted sets）与范围查询，bitmaps，hyperloglogs 和 地理空间（geospatial）索引半径查询。Redis内置了复制（replication），LUA脚本（Lua scripting），LRU驱动事件（LRU eviction），事务（transactions）和不同级别的 磁盘持久（persistence），并通过Redis哨兵（Sentinel）和自动分区（Cluster）提供高可用性（high availability）。

1. Strings：字符串类型是Redis中最为基础的数据存储类型，它在Redis中是二进制安全的，这便意味着该类型可以接受任何格式的数据，如JPEG图像数据或Json对象描述信息等。在Redis中字符串类型的Value最多可以容纳的数据长度是512M。
2. Hashes：是一个String类型的field和value的映射表。添加、删除操作复杂度平均为O(1)，为什么是平均呢？因为Hash的内部结构包含zipmap和hash两种。hash特别适合用于存储对象。相对于将对象序列化存储为String类型，将一个对象存储在hash类型中会占用更少的内存，并且可以方便的操作对象。为什么省内存，因为对象刚开始使用zipmap存储的。
3. Lists：双链表，是按照插入顺序排序的字符串链表。和数据结构中的普通链表一样，我们可以在其头部(left)和尾部(right)添加新的元素。在插入时，如果该键并不存在，Redis将为该键创建一个新的链表。与此相反，如果链表中所有的元素均被移除，那么该键也将会被从数据库中删除。List中可以包含的最大元素数量是4294967295。
4. Sets：是没有排序的字符集合，和List类型一样，可以在该类型的数据值上执行添加、删除或判断某一元素是否存在等操作。需要说明的是，这些操作的时间复杂度为O(1)，即常量时间内完成次操作。Set可包含的最大元素数量是4294967295。和List类型不同的是，Set集合中不允许出现重复的元素。换句话说，如果多次添加相同元素，Set中将仅保留该元素的一份拷贝。和List类型相比，Set类型在功能上还存在着一个非常重要的特性，即在服务器端完成多个Sets之间的聚合计算操作，如unions、intersections和differences。由于这些操作均在服务端完成，因此效率极高，而且也节省了大量的网络IO开销。
5. Sorted Sets：和Sets类型极为相似，它们都是字符串的集合，都不允许重复的成员出现在一个Set中。它们之间的主要差别是Sorted-Sets中的每一个成员都会有一个分数(score)与之关联，Redis正是通过分数来为集合中的成员进行的排序。尽管Sorted-Sets中的成员必须是唯一的，但是分数(score)却是可以重复的。在Sorted-Set中添加、删除或更新一个成员都是非常快速的操作，其时间复杂度为集合中成员数量的对数。由于Sorted-Sets中的成员在集合中的位置是有序的，因此，即便是访问位于集合中部的成员也仍然是非常高效的。

NOSQL对比

• MongoDB、Hbase、Redis等NoSQL优劣势和应用场景

RDB&AOF持久化

全量模式持久化（RDB）

• 当发生写操作时，Redis会有状态的切换，将Redis的数据持久化到硬盘中，形成快照。Redis重启时，加载最近的一份快照数据，将Redis恢复到最近一次的持久化状态上。
• 写入流程包含save和bgsave两种方式

1. save可以由客户端显示触发的，也可以在redis shutdown 时触发。Save本身是单线程串行化的方式执行的，因此当数据量大时，有肯能会发生Redis Server的长时间卡顿。但是其备份期间不会有其他命令执行，因此备份在这一时刻是一致性的。
2. bgsave也可以由客户端显示触发、可以通过配置定时任务触发也可以在master-slave的分布式结构下由slave节点触发。bgsave命令在执行的时候，会fork一个子进程。子进程提交完成之后，会立即给客户端返回响应，备份操作在后台异步执行，在此期间不会影响Redis的正常响应。

   

• save和bgsave的区别

1. 对于bgsave来说，当父进程Fork完子进程之后，异步任务会将当前的内存状态作为一个版本进行复制。在复制过程中产生的变更，不会反映在这次备份当中。在Redis的默认配置当中，当满足下面任一条件时，会自动触发bgsave 的执行。
2. bgsave相对于save来说，其优势是异步执行，不影响后续的命令执行。但是Fork子进程时，涉及父进程的内存复制，此时会增加服务器的内存开销。当内存开销高到使用虚拟内存时，bgsave的Fork子进程会阻塞运行，可能会造成秒级的不可用。因此使用bgsave需要保证服务器空闲内存足够。

• 恢复数据：当Redis重新启动时，会从本地磁盘加载之前持久化的文件。当恢复完成之后，再受理后续的请求操作。

增量模式持久化（AOF）

• 与RDB记录状态不同，AOF（append-only-file）则是每条写命令的记录，通过记录所有写命令的执行，最后恢复出最终的数据状态。
• 写入流程

1. always：每一次的刷新缓冲区，都会同步触发同步操作。因为每次的写操作都会触发同步，所以该策略会降低Redis的吞吐量，但是这种模式会拥有最高的容错能力。
2. every second：每秒异步的触发同步操作，这种是Redis的默认配置。
3. no：由操作系统决定何时同步，这种方式Redis无法决定何时落地，因此不可控。

   

• AOF模式优化

1. 随着Redis 持续的运行，会有大量的增量数据append 到AOF 文件中。为了减小硬盘存储和加快恢复速度，Redis 通过rewrite 机制合并历史AOF 记录。流程如下：

   1.1 历史AOF：以快照的方式保存。

   1.2 快照写入期间的增量：待快照写入完成之后append 到快照文件中。

   1.3 后续的增量：写入新的AOF。

• 恢复数据：AOF的恢复时机也是在机器启动时，一旦存在AOF，Redis会选择增量恢复。因为增量的持久化持续的写入磁盘，相比全量持久化，数据更加完整。恢复的过程就是将AOF中存放的命令，重新执行一遍。完成之后再继续接受客户端的新命令。

Redis Master&Slave(主从复制)

• Master&Slave，即主机数据更新后根据配置和策略，自动同步到备机。用于读写分离和容灾备份等。常用模式如下：

  

  1. 一主二仆，一个Master，两个Slave，Slave只能读不能写；当Slave与Master断开后需要重新slave of连接才可建立之前的主从关系；Master挂掉后，Master关系依然存在，Master重启即可恢复。
  2. 薪火相传，上一个Slave可以是下一个Slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个slave的Master，如此可以有效减轻Master的写压力。如果slave中途变更转向，会清除之前的数据，重新建立最新的。
  3. 反客为主，当Master挂掉后，Slave可键入命令 slaveof no one使当前redis停止与其他Master redis数据同步，转成Master redis。
• 主从复制原理

1. Slave启动成功连接到master后会发送一个sync命令；
2. Master接到命令启动后的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步；
3. 全量复制：而slave服务在数据库文件数据后，将其存盘并加载到内存中；
4. 增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步；
5. 但是只要是重新连接master，一次完全同步（全量复制）将被自动执行。

• 主从复制缺点：延时，由于所有的写操作都是在Master上操作，然后同步更新到Slave上，所以从Master同步到Slave机器有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，Slave机器数量的增加也会使得这个问题更加严重。

Redis Sentinel(哨兵模式)

• Redis-Sentinel(哨兵模式)是Redis官方推荐的高可用性(HA)解决方案，当用Redis做Master-slave的高可用方案时，假如master宕机了，Redis本身(包括它的很多客户端)都没有实现自动进行主备切换，而Redis-sentinel本身也是一个独立运行的进程，它能监控多个master-slave集群，发现master宕机后能进行自懂切换。它的主要功能有以下几点：

1. 监控(Monitoring)：哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常;
2. 提醒(Notification)：当被监控的某个 Redis出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知；
3. 自动故障迁移(Automatic failover)：当一个Master不能正常工作时，哨兵(sentinel) 会开始一次自动故障迁移操作,它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master; 当客户端试图连接失效的Master时,集群也会向客户端返回新Master的地址,使得集群可以使用Master代替失效Master。

• 哨兵(sentinel) 是一个分布式系统,你可以在一个架构中运行多个哨兵(sentinel) 进程,这些进程使用gossip协议(gossipprotocols)来接收关于Master是否下线的信息,并使用投票协议(agreement protocols)来决定是否执行自动故障迁移,以及选择哪个Slave作为新的Master。每个哨兵(sentinel) 会向其它哨兵(sentinel)、master、slave定时发送消息,以确认对方是否”活”着,如果发现对方在指定时间(可配置)内未回应,则暂时认为对方已挂(所谓的”主观认为宕机” Subjective Down,简称sdown)。若“哨兵群”中的多数sentinel,都报告某一master没响应,系统才认为该master"彻底死亡"(即:客观上的真正down机,Objective Down,简称odown),通过一定的vote算法,从剩下的slave节点中,选一台提升为master,然后自动修改相关配置。

• Redis-Sentinel 工作方式

1. 每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个 PING 命令。
2. 如果一个实例（instance）距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值， 则这个实例会被 Sentinel 标记为主观下线。
3. 如果一个Master被标记为主观下线，则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master的确进入了主观下线状态。
4. 当有足够数量的 Sentinel（大于等于配置文件指定的值）在指定的时间范围内确认Master的确进入了主观下线状态， 则Master会被标记为客观下线 。
5. 在一般情况下， 每个 Sentinel 会以每 10 秒一次的频率向它已知的所有Master，Slave发送 INFO 命令 。
6. 当Master被 Sentinel 标记为客观下线时，Sentinel 向下线的 Master 的所有 Slave 发送 INFO 命令的频率会从 10 秒一次改为每秒一次 。
7. 若没有足够数量的 Sentinel 同意 Master 已经下线， Master 的客观下线状态就会被移除；若 Master 重新向 Sentinel 的 PING 命令返回有效回复， Master 的主观下线状态就会被移除。

• Redis-Sentinel集群：redis Sentinel 集群模式可以增强整个Redis集群的稳定性与可靠性，但是当某个节点的master节点挂了要重新选举出新的master节点时，Redis Sentinel的集群模式选举的复杂度显然高于单点的Redis Sentinel 模式。

  当一个master被sentinel集群监控时，需要为它指定一个参数，这个参数指定了当需要判决master为不可用，并且进行failover时，所需要的sentinel数量，本文中我们暂时称这个参数为票数,不过，当failover主备切换真正被触发后，failover并不会马上进行，还需要sentinel中的大多数sentinel授权后才可以进行failover。当ODOWN时，failover被触发。failover一旦被触发，尝试去进行failover的sentinel会去获得“大多数”sentinel的授权（如果票数比大多数还要大的时候，则询问更多的sentinel)这个区别看起来很微妙，但是很容易理解和使用。例如，集群中有5个sentinel，票数被设置为2，当2个sentinel认为一个master已经不可用了以后，将会触发failover，但是，进行failover的那个sentinel必须先获得至少3个sentinel的授权才可以实行failover。如果票数被设置为5，要达到ODOWN状态，必须所有5个sentinel都主观认为master为不可用，要进行failover，那么得获得所有5个sentinel的授权。

• Redis-Sentinel集群好处：Sentinel 可以管理master-slave节点，看似Redis的稳定性得到一个比较好的保障。但是如果Sentinel是单节点的话，如果Sentinel宕机了，master-slave这种模式就不能发挥其作用了。幸好Sentinel也支持集群模式，Sentinel的集群模式主要有以下几个好处：

1. 即使有一些sentinel进程宕掉了，依然可以进行redis集群的主备切换；
2. 如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）;
3. 如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。

• Redis-Sentinel 缺点：水平扩容（增加机器节点）时，牵涉到数据的迁移，迁移过程一方面要保证自己的业务是可用的，另一方面要保证尽量不丢失数据，所以数据能不迁移就尽量不迁移。

Redis Cluster(集群部署)

• Redis Cluster是Redis的分布式解决方案，在Redis 3.0版本正式推出的，有效解决了Redis分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构达到负载均衡的目的。分布式集群首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。Redis Cluster采用哈希分区规则中的虚拟槽分区。虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。Redis Cluster槽的范围是0 ～ 16383。槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，每个节点负责一定数量的槽。Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0 ～ 16383，计算公式：slot = CRC16(key)&16383。每一个实节点负责维护一部分槽以及槽所映射的键值数据。
  Redis Cluster详解