Redis基础复习
由于做的是企业级的开发，有很多之前学过的内容，差不多都好忘光了，趁过年休假，好好整理一下，温故知新。这里只是我复习之后记录的大纲和关键内容，很多操作需要自己去实践。如果想系统学习一下redis，个人认为不需要去买书去看，只需要看看在线文档和博客，基本就可以满足我们的开发要求了，这个力推一个在线文档 Redis在线文档 。希望对大家有所帮助。
Redis简介
Redis是一款开源的、高性能的键-值存储（key-value store）。它常被称作是一款数据结构服务器（data structure server）。
Redis的键值可以包括字符串（strings）类型，同时它还包括哈希（hashes）、列表（lists）、集合（sets）和 有序集合（sorted sets）等数据类型。 对于这些数据类型，你可以执行原子操作。例如：对字符串进行附加操作（append）；递增哈希中的值；向列表中增加元素；计算集合的交集、并集与差集等。
为了获得优异的性能，Redis采用了内存中（in-memory）数据集（dataset）的方式。同时，Redis支持数据的持久化，你可以每隔一段时间将数据集转存到磁盘上（snapshot），或者在日志尾部追加每一条操作命令（append only file,aof）。
Redis同样支持主从复制（master-slave replication），并且具有非常快速的非阻塞首次同步（ non-blocking first synchronization）、网络断开自动重连等功能。同时Redis还具有其它一些特性，其中包括简单的事物支持、发布订阅 （ pub/sub）、管道（pipeline）和虚拟内存（vm）等 。
Redis具有丰富的客户端，支持现阶段流行的大多数编程语言。
Redis 采用单线程结构，包括主IO处理，IO相关的业务处理，集群协调等，对于redis的所有请求都是串行处理的，我们可以启用多个redis实例来发挥CPU多核的特性。
Redis使用多路I/O复用模型，非阻塞IO，其实这个模型就相当于React 模型，举个简单的例子，就相当于咱们去肯德基麦当劳点餐，而吧台只有一个点餐员（即一个线程）,当很多个顾客去点餐时，点餐员给你点完餐后就会给下一个人点餐，不会发生阻塞，当你的餐准备好时，通知你取走。
常用的数据类型
| 类型 | 简介 | 特性 | 场景 | 具体命令 |
|---|---|---|---|---|
| String(字符串) | 二进制安全 | 可以包含任何数据,比如jpg图片或者序列化的对象,一个键最大能存储512M | --- | set/get |
| Hash(字典) | 键值对集合,即编程语言中的Map类型 | 适合存储对象,并且可以像数据库中update一个属性一样只修改某一项属性值(Memcached中需要取出整个字符串反序列化成对象修改完再序列化存回去) | 存储、读取、修改用户属性 | hset/hget |
| List(列表) | 链表(双向链表) | 增删快,提供了操作某一段元素的API | 1,最新消息排行等功能(比如朋友圈的时间线) 2,消息队列 | lpush/rpop |
| Set(集合) | 哈希表实现,元素不重复 | 1、添加、删除,查找的复杂度都是O(1) 2、为集合提供了求交集、并集、差集等操作 | 1、共同好友 2、利用唯一性,统计访问网站的所有独立ip 3、好友推荐时,根据tag求交集,大于某个阈值就可以推荐 | sadd/sinter |
| Sorted Set(有序集合) | 将Set中的元素增加一个权重参数score,元素按score有序排列 | 数据插入集合时,已经进行天然排序 | 1、排行榜 2、带权重的消息队列 | zadd/zrangebyscore |
查询出某一固定前缀的key
少量数据中可以使用
KEYS pattern命令 ，举例 找出k1打头的所有keykeys k1*-
如果为海量的key,则可以使用 scan cursor [MATCH pattern] [COUNT count]，举例 找出k1打头的所有key
scan match k1* count 10
p1.png
基于游标的迭代器，需要基于上一次的游标延续之前的迭代过程。
以0作为游标开始一次新的迭代，直到命令返回游标0完成一次遍历。
不保证每次执行都返回某个给定数量的元素，支持模糊查询。
一次返回的数量不可控，只能是大概率符合的count参数。
其他游标迭代命令
- SCAN 命令用于迭代当前数据库中的数据库键。
- SSCAN 命令用于迭代集合键中的元素。
- HSCAN 命令用于迭代哈希键中的键值对。
- ZSCAN 命令用于迭代有序集合中的元素（包括元素成员和元素分值）。
Redis持久化
Redis 提供了多种不同级别的持久化方式
- RDB 持久化可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
- AOF 持久化记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾（增量）。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
- Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。
RDB方式持久化
配置
首先需要打开 redis.conf 文件，查找到相关RDB的配置。
以上配置完成，redis默认使用的就是 bgsave指令，fork一个子进程来创建RDB文件。
运作方式
当 Redis 需要保存 dump.rdb 文件时， 服务器执行以下操作：
- Redis 调用
fork()，同时拥有父进程和子进程。 - 子进程将数据集写入到一个临时 RDB 文件中。
- 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。
这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。
自动触发RDB
- 根据配置文件中的配置条件触发
- 主从复制时，主节点自动触发
- 执行Debug Reload
- 执行shutdown并且没有开启AOF持久化
优缺点
- 优点
- RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
- RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
- RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是
fork出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。 - RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。
- 缺点
- 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。
- 每次保存 RDB 的时候，Redis 都要
fork()出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时，fork()可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行fork()，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。
AOF方式持久化
配置
首先需要打开 redis.conf 文件，查找到相关RDB的配置。
以上配置完成，redis默认使用的就是 BGREWRITEAOF指令，fork一个子进程来创建RDB文件。
运作方式
AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。
以下是 AOF 重写的执行步骤：
- Redis 执行
fork()，现在同时拥有父进程和子进程。 - 子进程开始将新 AOF 文件的内容写入到临时文件。
- 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾： 这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
- 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
- 搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。
在AOF和RDB共存情况下数据的恢复流程
- 重新启动redis。
- 检查AOF是否存在如果存在，直接加载AOF文件忽略掉RDB文件。
- 如果不存在AOF，则加载RDB文件。
优缺点
- 优点
- 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的
fsync策略，比如无fsync，每秒钟一次fsync，或者每次执行写入命令时fsync。 AOF 的默认策略为每秒钟fsync一次，在这种配置下，Redis 仍然可以保持良好的性能，并且就算发生故障停机，也最多只会丢失一秒钟的数据（fsync会在后台线程执行，所以主线程可以继续努力地处理命令请求）。 - AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行
seek， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机，等等），redis-check-aof工具也可以轻易地修复这种问题。 - Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
- AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 因此 AOF 文件的内容非常容易被人读懂， 对文件进行分析（parse）也很轻松。 导出（export） AOF 文件也非常简单： 举个例子， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
- 使用 AOF 持久化会让 Redis 变得非常耐久（much more durable）：你可以设置不同的
- 缺点
- 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。
- 根据所使用的
fsync策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒fsync的性能依然非常高， 而关闭fsync可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。 - AOF 在过去曾经发生过这样的 bug ： 因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。 （举个例子，阻塞命令 BRPOPLPUSH 就曾经引起过这样的 bug 。） 测试套件里为这种情况添加了测试： 它们会自动生成随机的、复杂的数据集， 并通过重新载入这些数据来确保一切正常。 虽然这种 bug 在 AOF 文件中并不常见， 但是对比来说， RDB 几乎是不可能出现这种 bug 的。
RDB和AOF混合方式
这种持久化能够通过 AOF 重写操作创建出一个同时包含 RDB 数据和 AOF 数据的 AOF 文件， 其中 RDB 数据位于 AOF 文件的开头， 它们储存了服务器开始执行重写操作时的数据库状态： 至于那些在重写操作执行之后执行的 Redis 命令， 则会继续以 AOF 格式追加到 AOF 文件的末尾， 也即是 RDB 数据之后。
配置
首先需要打开 redis.conf 文件
1，开启AOF持久化
appendonly yes
2.开启混合方式
aof-use-rdb-preamble yes
3.执行命令 BGREWRITEAOF
主从复制
全量复制
Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。具体步骤如下：
- 从服务器连接主服务器，发送SYNC命令；
- 主服务器接收到SYNC命名后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
- 主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
- 从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
- 主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
- 从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；
增量复制
Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。
Redis集群
redis集群的原理就是 一致性哈希算法进行分片。这里我就不做总结了，推荐一个大神的博文 一致性Hash算法(Consistent Hash)
