redis参数与持久化原理

[root@JR hx]# redis-cli info
# Server
redis_version:2.8.19
redis_git_sha1:00000000
redis_git_dirty:0
redis_build_id:3f46a0c12d2b66a6
redis_mode:standalone 模式：是否做主从同步了
os:Linux 2.6.32-431.23.3.el6.x86_64 x86_64 #linux 版本
arch_bits:64 # 架构
multiplexing_api:epoll
gcc_version:4.4.7
process_id:20848
run_id:c77b9becd5a017913d778ac23ad7ea2032741b2d
tcp_port:6379
uptime_in_seconds:18308503 自 Redis 服务器启动以来，经过的秒数
uptime_in_days:211 自 Redis 服务器启动以来，经过的天数
hz:10
lru_clock:3570345 以分钟为单位进行自增的时钟，用于 LRU 管理
config_file:
 
# Clients
connected_clients:47 已连接客户端的数量（不包括通过从属服务器连接的客户端）
client_longest_output_list:0 当前连接的客户端当中，最长的输出列表
client_biggest_input_buf:0 当前连接的客户端当中，最大输入缓存
blocked_clients:1 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量
 
# Memory
used_memory:92306016 由 Redis 分配器分配的内存总量，以字节（byte）为单位
used_memory_human:88.03M 以人类可读的格式返回 Redis 分配的内存总量
used_memory_rss:103796736 从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致。
 
used_memory_peak:106823960  Redis 的内存消耗峰值（以字节byte为单位）
used_memory_peak_human:101.88M 以人类可读的格式返回 Redis 的内存消耗峰值
used_memory_lua:35840 引擎所使用的内存大小（以字节为单位）
mem_fragmentation_ratio:1.12 used_memory_rss 和 used_memory 之间的比率
mem_allocator:jemalloc-3.6.0 在编译时指定的， Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。

　

在理想情况下， used_memory_rss 的值应该只比 used_memory 稍微高一点儿。

当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。

内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。值越大内存碎片越多

当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。

当 Redis 释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。

如果 Redis 释放了内存，却没有将内存返还给操作系统，那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。查看 used_memory_peak 的值可以验证这种情况是否发生。

 

 

 

 

 

# Persistence    RDB 和 AOF 的相关信息
loading:0                 一个标志值，记录了服务器是否正在载入持久化文件
rdb_changes_since_last_save:296  #距离最后一次成功创建持久化文件之后，改变了多少个键值单位秒
rdb_bgsave_in_progress:0                  一个标志值，记录服务器是否正在创建RDB文件
rdb_last_save_time:1479965088        最近一次成功创建RDB文件的UNIX时间戳
rdb_last_bgsave_status:ok                 一个标志值，记录了最后一次创建RDB文件的结果是成功还是失败
rdb_last_bgsave_time_sec:2           记录最后一次创建RDB文件耗费的秒数
rdb_current_bgsave_time_sec:-1     如果服务器正在创建RDB文件，那么这个值记录的就是当前的创建RDB操作已经耗费了多长时间（单位为秒）
aof_enabled:0      一个标志值，记录了AOF是否处于打开状态
aof_rewrite_in_progress:0    一个标志值，记录了服务器是否正在创建AOF文件
aof_rewrite_scheduled:0     一个标志值，记录了RDB文件创建完之后，是否需要执行预约的AOF重写操作
aof_last_rewrite_time_sec:-1        #记录了最后一次AOF重写操作的耗时
aof_current_rewrite_time_sec:-1    #如果服务器正在进行AOF重写操作，那么这个值记录的就是当前重写操作已经耗费的时间（单位是秒）
aof_last_bgrewrite_status:ok    一个标志值，记录了最后一次重写AOF文件的结果是成功还是失败
 
aof_last_write_status:ok

# Stats     一般统计信息
total_connections_received:225390        #服务器已经接受的连接请求数量
total_commands_processed:573807059            #服务器已经执行的命令数量
instantaneous_ops_per_sec:34                    #服务器每秒中执行的命令数量
total_net_input_bytes:30507043380           服务器输入的字节总数
total_net_output_bytes:36664408875         服务器输出的字节总数
instantaneous_input_kbps:1.41
instantaneous_output_kbps:0.93
rejected_connections:0                      #因为最大客户端数量限制而被拒绝的连接请求数量
sync_full:0
sync_partial_ok:0
sync_partial_err:0
expired_keys:363726               #因为过期而被自动删除的数据库键数量
 
evicted_keys:0                         因为最大内存容量限制而被驱逐（evict）的键数量
keyspace_hits:125806840          #查找数据库键成功的次数
keyspace_misses:3943604      查找数据库键失败的次数
pubsub_channels:1                  #目前被订阅的频道数量
pubsub_patterns:0                 #目前被订阅的模式数量
latest_fork_usec:3755             #最近一次fork()操作耗费的时间(毫秒)

　　

# Replication   主/从复制信息
role:master
connected_slaves:0                #有一个slave连接上来
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
l   master_port:主服务器监听的端口号
l   master_link_status:复制连接当前的状态，up表示连接正常，down表示连接断开
l   master_last_io_seconds_ago:距离最近一次与主服务器进行通信已经过去了多少秒
l   master_sync_in_progress:一个标志值，记录了主服务器是否正在与这个从服务器进行同步
l   master_sync_left_bytes：距离同步完成还缺多少字节的数据
l   master_sync_last_io_seconds_ago: 距离最近一次与主服务器进行通信已经过去了多少秒
master_link_down_since_seconds: 主从服务器连接断开了多少秒

　　

　　

# CPU   PU 计算量统计信息
used_cpu_sys:24531.54        #Redis服务器耗费的系统CPU
used_cpu_user:21360.46     #Redis服务器耗费的用户CPU
used_cpu_sys_children:2118.70                  #Redis后台进程耗费的系统CPU
used_cpu_user_children:18899.77               #Redis后台进程耗费的用户CPU
 
# Keyspace
db0:keys=69505,expires=8999,avg_ttl=402930491778154  数据库相关的统计信息
  #402930491778154  号数据库有69505 个键、  已经被删除的过期键数量为8999,个

　　

---

redis 持久化

 

RDB & AOF

 

rdb持久化是指在指定时间间隔内将内存中的数据集快照写入磁盘，也就是默认的持久化方式，这种方式就是将内存那种数据以快照的方式写到二进制文件中。默认的文件名为dump.rdb

save90019001save3001030010save6010000

 

• 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copy on write)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数 据是fork时刻整个数据库的一个快照。
• 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。

 

client 也可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求。所以不推荐使用。

 

另一点需要注意的是，每次快照持久化都是将内存数据完整写入到磁盘一次，并不 是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。

 

优势

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

 

劣势

• 如果你需要尽量避免在服务器故障时丢失数据，那么 RDB 不适合你。 虽然 Redis 允许你设置不同的保存点（save point）来控制保存 RDB 文件的频率， 但是， 因为RDB 文件需要保存整个数据集的状态， 所以它并不是一个轻松的操作。 因此你可能会至少 5 分钟才保存一次 RDB 文件。 在这种情况下， 一旦发生故障停机， 你就可能会丢失好几分钟的数据。

 

• 每次保存 RDB 的时候，Redis 都要 fork() 出一个子进程，并由子进程来进行实际的持久化工作。 在数据集比较庞大时， fork() 可能会非常耗时，造成服务器在某某毫秒内停止处理客户端； 如果数据集非常巨大，并且 CPU 时间非常紧张的话，那么这种停止时间甚至可能会长达整整一秒。 虽然 AOF 重写也需要进行 fork() ，但无论 AOF 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

 

 

AOF文件保存过程

redis会将每一个收到的写命令都通过write函数追加到文件中(默认是 appendonly.aof)。

当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存 write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要 通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）

//启用aof持久化方式//每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用//每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐//完全依赖os，性能最好,持久化没保证

 

优势

性能和数据安全兼备

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

抉择

一般来说， 如果想达到足以媲美 PostgreSQL 的数据安全性， 你应该同时使用两种持久化功能。

如果你非常关心你的数据， 但仍然可以承受数分钟以内的数据丢失， 那么你可以只使用 RDB 持久化。

其余情况我个人喜好选择AOF