Redis&持久化存储

Redis支持的数据类型：

string（字符串），hash（哈希），list（列表），set（集合）及zset(sorted set：有序集合)。

string类型是Redis最基本的数据类型，一个键最大能存储512MB。

hash 是一个键值对集合，特别适合用于存储对象。每个 hash 可以存储 2的32 - 1次方 键值对（40多亿）。

list 列表是简单的字符串列表，按照插入顺序进行排序，可以添加一个元素导列表的头部（左边）或者尾部（右边）。

set 集合是string类型的无需集合，通过哈希表实现，添加，删除，查找的复杂度都是O(1)。若插入相同元素时，第二次的插入将被忽略。

zset 有序集合，也是string类型元素的集合,且不允许重复的成员。

 

 

Redis的事务命令：

MULTI：标记一个事务块的开始。

EXEC：执行所有事务块内的命令。

DISCARD：取消事务，放弃执行事务块内的所有命令。

WATCH key[key ...]：监视一个或多个key，若事务在执行这个key之前被其他命令所改动，那么事务将被打断。

UNWATCH：取消 WATCH 命令对所有 key 的监视。

　　举个栗子：

redis 127.0.0.1:6379> MULTI
OK
 
redis 127.0.0.1:6379> SET book-name "Mastering C++ in 21 days"
QUEUED
 
redis 127.0.0.1:6379> GET book-name
QUEUED
 
redis 127.0.0.1:6379> SADD tag "C++" "Programming" "Mastering Series"
QUEUED
 
redis 127.0.0.1:6379> SMEMBERS tag
QUEUED
 
redis 127.0.0.1:6379> EXEC
1) OK
2) "Mastering C++ in 21 days"
3) (integer) 3
4) 1) "Mastering Series"
   2) "C++"
   3) "Programming"

Redis设置密码：

第一种方式（修改配置文件）
Sudo vim /etc/redis/redis.conf
命令模式搜索requirepass，把注释掉的那行打开
# requirepass footbared
requirepass 123456

第二种方式：直接在redis中设置，只对当前启动有效
设置密码：config set requirepass 123456
取消密码：config set requirepass “”

Redis的存储机制：

RDB （快照Snapshot）工作原理: 将databases中的key-value的二进制形式存储在了rdb文件中。先将数据存在内存，然后当数据累计达到某些设定的阀值的时候，就会触发一次DUMP操作，将变化的数据一次性写入数据文件（RDB文件）。

AOF 工作原理: 是将数据也是先存在内存，但是在存储的时候会使用调用fsync来完成对本次写操作的日志记录，这个日志揭露文件其实是一个基于Redis网络交互协议的文本文件。AOF调用fsync也不是说全部都是无阻塞的，在某些系统上可能出现fsync阻塞进程的情况，对于这种情况可以通过配置修改，但默认情况不要修改。AOF最关键的配置就是关于调用fsync追加日志文件的平率，有两种预设频率，always每次记录进来都添加，everysecond 每秒添加一次。两个配置各有所长后面分析。由于是采用日志追加的方式来持久话数据，所以引出了第二个日志的概念：rewrite. 后面介绍它的由来。

无论是那种机制,Redis都是将数据存储在内存中。

 

 

性能&安全比较：

性能：

RDB方式的性能明显高于AOF方式，RDB采用压缩的二进制方式存储数据，数据文件比较小，加载快速。存储的时候是按照配置项中的save策略来存储，每次都是聚合很多数据批量存储，写入的效率很好，而AOF则一般都是工作在实时存储或者准实时模式下。相对来说存储的频率高，效率却偏低。

数据安全：

AOF数据安全性高于RDB存储，Snapshot存储是基于累计批量的思想，也就是在允许的情况下，累计的数据越多那么写入效率也就越高，但数据的累计是靠时间的积累完成的，那么如果在长时间数据不写入RDB，但Redis又遇到了崩溃，那么没有写入的数据就无法恢复了，但是AOF方式偏偏相反，根据AOF配置的存储频率的策略可以做到最少的数据丢失和较高的数据恢复能力。

Redis特点

Redis本质上是一个Key-Value类型的内存数据库，很像memcached，整个数据库统统加载在内存当中进行操作，定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作，Redis的性能非常出色，每秒可以处理超过 10万次读写操作，是已知性能最快的Key-Value DB。
Redis的出色之处不仅仅是性能，Redis最大的魅力是支持保存多种数据结构，此外单个value的最大限制是1GB，不像 memcached只能保存1MB的数据，因此Redis可以用来实现很多有用的功能，比方说用他的List来做FIFO双向链表，实现一个轻量级的高性 能消息队列服务，用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间，因此也可以被当作一 个功能加强版的memcached来用。
Redis的主要缺点是数据库容量受到物理内存的限制，不能用作海量数据的高性能读写，因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。

Redis持久化方式：

• RDB 持久化(Redis DataBase)可以在指定的时间间隔内生成数据集的时间点快照（point-in-time snapshot）。
• AOF 持久化(Append-only file)记录服务器执行的所有写操作命令，并在服务器启动时，通过重新执行这些命令来还原数据集。 AOF 文件中的命令全部以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写（rewrite），使得 AOF 文件的体积不会超出保存数据集状态所需的实际大小。
• Redis 还可以同时使用 AOF 持久化和 RDB 持久化。 在这种情况下， 当 Redis 重启时， 它会优先使用 AOF 文件来还原数据集， 因为 AOF 文件保存的数据集通常比 RDB 文件所保存的数据集更完整。

RDB 快照

在默认情况下， Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。可以对 Redis 进行设置， 让它在“ N 秒内数据集至少有 M 个改动”这一条件被满足时, 自动保存一次数据集。

执行保存操作：调用 SAVE 或者 BGSAVE ，手动让 Redis 进行数据集保存操作。一个栗子，save 60 1000   会让 Redis 在满足“ 60 秒内有至少有 1000 个键被改动”这一条件时， 自动保存一次数据集。这种持久化方式被称为快照（snapshot）。

• SAVE：阻塞redis的服务器进程，直到RDB文件被创建完毕。
• BGSAVE：派生(fork)一个子进程来创建新的RDB文件，记录接收到BGSAVE当时的数据库状态，父进程继续处理接收到的命令，子进程完成文件的创建之后，会发送信号给父进程，而与此同时，父进程处理命令的同时，通过轮询来接收子进程的信号。

快照的运作方式

当Redis需要保存 dump.rdb 文件时，执行以下操作：

1. Redis 调用 fork() ，同时拥有父进程和子进程。
2. 子进程将数据集写入到一个临时 RDB 文件中。
3. 当子进程完成对新 RDB 文件的写入时，Redis 用新 RDB 文件替换原来的 RDB 文件，并删除旧的 RDB 文件。

这种工作方式使得 Redis 可以从写时复制（copy-on-write）机制中获益。

 

RDB 优点

• RDB 是一个非常紧凑（compact）的文件，它保存了 Redis 在某个时间点上的数据集。 这种文件非常适合用于进行备份： 比如说，你可以在最近的 24 小时内，每小时备份一次 RDB 文件，并且在每个月的每一天，也备份一个 RDB 文件。 这样的话，即使遇上问题，也可以随时将数据集还原到不同的版本。
• 生成的文件是一种压缩的二进制文件，方便于在网络中传输。
• RDB 非常适用于灾难恢复（disaster recovery）：它只有一个文件，并且内容都非常紧凑，可以（在加密后）将它传送到别的数据中心。
• RDB 可以最大化 Redis 的性能：父进程在保存 RDB 文件时唯一要做的就是 fork 出一个子进程，然后这个子进程就会处理接下来的所有保存工作，父进程无须执行任何磁盘 I/O 操作。
• RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。

RDB 缺点

• 如果想要避免在服务器故障时丢失数据，那么 RDB 不太适合。 RDB保存一次备份之后，到下一次保存之前，这段期间所产生的的新数据，如果还没有达到生成备份文件的条件，此时服务器宕机就会丢失这部分数据。虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是因为 RDB 文件需要保存整个数据集的状态，所以它是一个非常耗费系统资源的操作。 因此若是需要至少 5 分钟才保存一次 RDB 文件的情况下， 一旦发生故障停机，可能会丢失好几分钟的数据。
• 每次保存 RDB 的时候，Redis 都要 fork() 创建出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。创建子线程和生成rdb文件会占用大量 的系统资源和处理时间

RDB 配置文件

# dbfilename：配置RDB文件的名称，默认叫 dump.rdb
dbfilename dump.rdb

# dir：配置的RDB文件存储在本地的路径，如果是在 /redis/redis-3.0.6/src 下启动的redis-cli，则数据会存储在当前src目录下
dir ./

# snapshot触发时机的配置：save <seconds> <changes> ， 可通过 save “” 关闭snapshot功能  
# changes：对于此值设置需谨慎，要评估系统的变更操作密集程度 
save 900 1        # 更改了1个key的时候，间隔900秒后，至少有一个变更操作，进行持久化存储snapshot   
save 300 10      # 更改了10个key的时候，间隔300s进行持久化存储
save 60 10000   # 更改10000个key的时候，间隔360s进行存储。

# 当生成 RDB 文件出错无法继续时，是否则色客户端的“变更操作”，是否继续处理 Redis 写命令，默认为不处理。“错误”可能因为磁盘已满/磁盘故障/OS级别异常等  
stop-writes-on-bgsave-error yes  

# 是否对rdb文件进行压缩，默认为“yes”，压缩往往意味着“额外的cpu消耗”，同时也意味这较小的文件尺寸以及较短的　　
rdbcompression yes      

# 是否对 RDB 文件进行校验和校验
rdbchecksum

#####

RDB 命令演示

Redis shutdown模拟服务器宕机
mv dump.rdb dump.rdb.bak
停止redis服务器service redis stop
启动redis-server /etc/redis/redis.conf
redis-cli
查询keys *
cp dump.rdb.bak dump.rdb
ps aux | grep redis
Kill -9 xxxx 停止redis服务器service redis stop 重启redis-server 重启redis-cli 查询keys *

 

AOF：只进行追加操作的文件（append-only file）

快照功能并不是非常耐久（durable）： 如果 Redis 因为某些原因而造成故障停机， 那么服务器将丢失最近写入、且仍未保存到快照中的那些数据。如果对于数据追求完全耐久能力（full durability）的要求，快照功能就不太适用。从 1.1 版本开始， Redis 增加了一种完全耐久的持久化方式： AOF 持久化。

通过修改配置文件来打开 AOF 功能：appendonly yes

每当 Redis 执行一个改变数据集的命令时（比如 SET key value [EX seconds] [PX milliseconds] [NX|XX]）， 这个命令就会被追加到 AOF 文件的末尾（对数据的每一条修改命令追加到aof文件）。这样的话，当 Redis 重新启时， 程序就可以通过重新执行 AOF 文件中的命令来达到重建数据集的目的。RDB持久化相当于备份数据库状态，而AOF持久化是备份数据库接收到的命令。

AOF文件生成的过程：命令追加、文件写入、文件同步

AOF 重写（Rewrite）

因为 AOF 的运作方式是不断地将命令追加到文件的末尾，按照记录日志的方式去工作的，所以随着写入命令的不断增加，成千上万的数据插入必然导致日志文件的扩大，AOF 文件的体积也会变得越来越大。举个栗子如果你对一个计数器调用了 100 次 INCR key ， 那么仅仅是为了保存这个计数器的当前值， AOF 文件就需要使用 100 条记录（entry）。然而实际上，只使用一条 SET key value [EX seconds] [PX milliseconds] [NX|XX] 命令已经足以保存计数器的当前值了， 其余 99 条记录实际上都是多余的。

为了处理这种情况， Redis 支持另一种特性：可以在不打断服务客户端的情况下，对 AOF 文件进行重建（rebuild）：执行 BGREWRITEAOF 命令， Redis 将生成一个新的 AOF 文件， 这个文件包含重建当前数据集所需的最少命令。Redis 2.2 需要自己手动执行 BGREWRITEAOF 命令； Redis 2.4 则可以自动触发 AOF 重写。

 

Redis的功能：

AOF的存储是，Redis会根据配置项，合理的触发Rewrite操作，就是将日志文件中的所有数据都重新写到另外一个新的日志文件中，但是不同的是，对于老日志文件中对于Key的多次操作，只保留最终的值的那次操作记录到日志文件中，从而缩小日志文件的大小。这里有两个配置需要注意：
auto-aof-rewrite-percentage 100 （当前写入日志文件的大小占到初始日志文件大小的某个百分比时触发Rewrite）
auto-aof-rewrite-min-size 64mb （本次Rewrite最小的写入数据良）
两个条件需要同时满足。

AOF 的运作方式

AOF 重写和 RDB 创建快照一样，都巧妙地利用了写时复制机制。

以下是 AOF 重写的执行步骤：

1. Redis 执行 fork() ，现在同时拥有父进程和子进程。
2. 子进程开始将新 AOF 文件的内容写入到临时文件。
3. 对于所有新执行的写入命令，父进程一边将它们累积到一个内存缓存中，一边将这些改动追加到现有 AOF 文件的末尾：这样即使在重写的中途发生停机，现有的 AOF 文件也还是安全的。
4. 当子进程完成重写工作时，它给父进程发送一个信号，父进程在接收到信号之后，将内存缓存中的所有数据追加到新 AOF 文件的末尾。
5. 搞定！现在 Redis 原子地用新文件替换旧文件，之后所有命令都会直接追加到新 AOF 文件的末尾。

AOF的优点

• 提供了多种同步命令方式，默认1s同步（fsync）一次写命令，就算发生故障停机，最多丢失1s的数据。（ fsync 会在后台线程执行，所以主线程可以继续努力地处理命令请求）。
• AOF 文件是一个只进行追加操作的日志文件（append only log）， 因此对 AOF 文件的写入不需要进行查找(seek)， 即使日志因为某些原因而包含了未写入完整的命令（比如写入时磁盘已满，写入中途停机等）， redis-check-aof 工具也可以轻易地修复这种问题。
• Redis 可以在 AOF 文件体积变得过大时，自动地在后台对 AOF 进行重写： 重写后的新 AOF 文件包含了恢复当前数据集所需的最小命令集合。 整个重写操作是绝对安全的，因为 Redis 在创建新 AOF 文件的过程中，会继续将命令追加到现有的 AOF 文件里面，即使重写过程中发生停机，现有的 AOF 文件也不会丢失。 而一旦新 AOF 文件创建完毕，Redis 就会从旧 AOF 文件切换到新 AOF 文件，并开始对新 AOF 文件进行追加操作。
• AOF 文件有序地保存了对数据库执行的所有写入操作，如果你不小心执行了 FLUSHALL 命令，只要 AOF 文件未被重写，那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令，并重启 Redis，就可以将数据集恢复到 FLUSHALL 执行之前的状态。

AOF 的缺点

• 对于相同的数据集来说，AOF 文件的体积通常要大于 RDB 文件的体积。当Redis负载较高时，RDB比AOF性能更好。
• 根据所使用的 fsync 策略，AOF 的速度可能会慢于 RDB 。 在一般情况下， 每秒 fsync 的性能依然非常高， 而关闭 fsync 可以让 AOF 的速度和 RDB 一样快， 即使在高负荷之下也是如此。 不过在处理巨大的写入载入时，RDB 可以提供更有保证的最大延迟时间（latency）。
• AOF 曾经发生过的 bug ：因为个别命令的原因，导致 AOF 文件在重新载入时，无法将数据集恢复成保存时的原样。（举个栗子，阻塞命令 BRPOPLPUSH source destination timeout 就曾引起过这样的 bug）它们会自动生成随机、复杂的数据集，并通过重新载入这些数据来确保一切正常。虽然这种 bug 在 AOF 文件中并不常见，但是对比来说，RDB 几乎是不可能出现这种 bug 的。

 

AOF 配置文件

# 是否打开 AOF 持久化功能，默认为“no”，可通过“yes”来开启AOF功能  
appendonly yes      # 只有在“yes”下，aof重写/文件同步等特性才会生效  


# 指定AOF文件的名称  
appendfilename appendonly.aof  


# 同步频率：指定AOF操作时，文件的同步策略，有三个合法值：always everysec no,默认为everysec  会影响到服务器间隔多久完成一次命令的记录。
# always：每一条aof记录都立即同步到文件，这是最安全的方式，但大量磁盘操作和阻塞延迟造成IO开支大，速度最慢不推荐。
# everysec：将缓存区的内容每隔一秒写入AOF文件中，性能和安全都比较中庸，是Redis官方推荐的方式。
# no ：写入AOF文件中的操作由操作系统决定，Redis不直接调用。一般而言为了提高效率，操作系统会等待缓存区被填满，才会开始同步数据到磁盘。在物理服务器故障时，数据丢失量会因OS配置有关
appendfsync everysec  


# 在aof-rewrite期间，appendfsync是否暂缓文件同步，"no"表示“不暂缓”，“yes”表示“暂缓”，默认为“no”  
no-appendfsync-on-rewrite no  


# aof文件rewrite触发的最小文件尺寸(mb,gb),只有大于此aof文件大于此尺寸是才会触发rewrite，默认“64mb”，建议“512mb”  
auto-aof-rewrite-min-size 64mb  


# 相对于“上一次”rewrite，本次rewrite触发时aof文件应该增长的百分比。  
# 每一次rewrite之后，redis都会记录下此时“新aof”文件的大小(例如A)，那么当aof文件增长到A*(1 + p)之后，触发下一次rewrite，每一次aof记录的添加都会检测当前aof文件的尺寸。  
auto-aof-rewrite-percentage 100

# 当前AOF文件启动新的日志重写过程的最小值，避免刚刚启动Reids时由于文件尺寸较小导致频繁的重写。
auto-aof-rewrite-min-size 64mb

RDB和AOF如何选择

- AOF更加安全，可以将数据更加及时的同步到文件中，但是AOF需要较多的磁盘IO开支，AOF文件尺寸较大，文件内容恢复数度相对较慢 
- RDB（snapshot），安全性较差，它是“正常时期”数据备份以及 master-slave 数据同步的最佳手段，文件尺寸较小，恢复数度较快。 
（1）不要仅仅使用RDB，因为那样会导致你丢失很多数据 
（2）也不要仅仅使用AOF，因为那样有两个问题，第一，通过AOF做冷备的操作，没有RDB做冷备来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug 。
（3）综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复。

怎么从 RDB 持久化切换到 AOF 持久化

在 Redis 2.2 或以上版本，可以在不重启的情况下，从 RDB 切换到 AOF ：

1. 为最新的 dump.rdb 文件创建一个备份。
2. 将备份放到一个安全的地方。
3. 执行以下两条命令：

redis-cli> CONFIG SET appendonly yes redis-cli> CONFIG SET save "" 

4. 确保命令执行之后，数据库的键的数量没有改变。
5. 确保写命令会被正确地追加到 AOF 文件的末尾。

步骤 3 执行的第一条命令开启了 AOF 功能： Redis 会阻塞直到初始 AOF 文件创建完成为止， 之后 Redis 会继续处理命令请求， 并开始将写入命令追加到 AOF 文件末尾。

步骤 3 执行的第二条命令用于关闭 RDB 功能。 这一步是可选的， 如果你愿意的话， 也可以同时使用 RDB 和 AOF 这两种持久化功能。

别忘了在 redis.conf 中打开 AOF 功能！ 否则服务器重启之后， 之前通过 CONFIG SET 设置的配置就会被遗忘， 程序会按原来的配置来启动服务器。

对比

• AOF更安全，可将数据及时同步到文件中，但需要较多的磁盘IO，AOF文件尺寸较大，文件内容恢复相对较慢， 也更完整。
• RDB持久化，安全性较差，它是正常时期数据备份及 master-slave数据同步的最佳手段，文件尺寸较小，恢复数度较快。

备份 Redis 数据

官方建议：

• 创建一个定期任务（cron job）， 每小时将一个 RDB 文件备份到一个文件夹， 并且每天将一个 RDB 文件备份到另一个文件夹。
• 确保快照的备份都带有相应的日期和时间信息， 每次执行定期任务脚本时， 使用 find 命令来删除过期的快照： 比如可以保留最近 48 小时内的每小时快照， 还可以保留最近一两个月的每日快照。
• 至少每天一次， 将 RDB 备份到你的数据中心之外， 或者至少是备份到你运行 Redis 服务器的物理机器之外。