Redis环境搭建及配置优化

概念

Redis是一个高性能key-value存储系统。Redis支持数据的持久化，可以将内存中的数据保持在磁盘中，重启的时候可以再次加载进行使用。Redis支持丰富的数据类型：Redis支持二进制案例的 Strings，Lists， Hashes，Sets 及 Ordered Sets 数据类型操作。Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。Redis还支持 publish/subscribe，通知，key 过期等等特性。Redis支持数据的备份，即master-slave模式的数据备份。

1.1. 简介

1.1.1 支持的数据类型

string ( 字符串 ) get, set …
list ( 链表 ) push, pop …
set ( 集合 ) sadd, srem …
sorted set ( 有序集合 ) zadd, zrem …
hash ( 哈希 ) hset, hget …
基于这些数据结构的操作基本都是原子性操作 ( 单线程处理命令 )。
为了保证效率，数据都是缓存在内存中。

1.1.2 消息的发布订阅

实现进程间通信，订阅者可以订阅一个或多个频道（channel），而发布者可以向指定的频道发送消息，所有订阅次频道的订阅者都会收到次消息。
PUBLISH
将信息 message 发送到指定的频道 channel。返回收到消息的客户端数量。
SUBSCRIBE
订阅给指定频道的信息。
一旦客户端进入订阅状态，客户端就只可接受订阅相关的命令 SUBSCRIBE、PSUBSCRIBE、UNSUBSCRIBE 和 PUNSUBSCRIBE 除了这些命令，其他命令一律失效。
UNSUBSCRIBE
取消订阅指定的频道，如果不指定，则取消订阅所有的频道。

1.1.3 持久化类型

RDB 全量模式：RDB是一个非常紧凑的文件,它保存了某个时间点得数据集,非常适用于数据集的备份。
AOF 增量模式：AOF 文件是一个只进行追加的日志文件，使用 AOF 会让你的 Redis 更加耐久，使用默认的每秒 fsync 策略，Redis 的性能依然很好( fsync 是由后台线程进行处理的,主线程会尽力处理客户端请求 )，一旦出现故障，你最多丢失1秒的数据。

1.1.4 部署应用方式

Single 单实例部署
Master-Slave 主从模式部署
Sentinel 哨兵模式部署 ( 一般搭配主从模式，主要用于主从的切换 )
Cluster 集群模式
Sharding 集群模式

1.1.5 官方参考网址

http://www.redis.cn/ 中文网站
https://redis.io/
建议 MAC 使用者，安装 Dash ，查看 Redis 相关文档会比较方便。

2.1 环境准备

Linux 版本：3.10.0-327.el7.x86_64 x86_64 GNU/Linux

2.1 创建用户组和用户

ROOT/ADMIN ( sudo ) 用户下操作

2.1.1 用户组

goupadd –g [gid] redis

2.1.2 用户

useradd –g redis redis –u [uid]
passwd redis

2.2 环境规划

REDIS_HOME=/u01/app/redis
INSTALL_PACKAGE=/u01/app/redis/package

2.2.1 使用方式规划

a) 从业务角度划分 REDIS 在项目中需要承担的角色
[ cache, inventory, queue, record, lock … ]；
（以下示例将从 cache，queue 两种角色阐述）
b) 从技术角度分析 REDIS 需要使用的模式 [ Single, Sentinel, Cluster ]；
c) 从安全和容灾的角度考虑 REDIS 实例的持久化和物理划分；

2.3 文件准备

2.3.1 创建文件目录结构

2.3.2 目录结构介绍

config : REDIS 配置文件 ( redis-[port].conf, sentinel-[port].conf ) 等
data : REDIS 持久化文件 ( AOF, RDB )
logs : REDIS 日志文件 ( redis-[port].log, sentinel-[port].log )
run : REDIS 运行 PID ( redis-[port].pid )
为了区别业务划分一些不同角色的 Redis 实例，在对应运行的文件目录里建立不同角色的文件夹以作区分，如：
config/cache, config/queue
data/cache, data/queue
logs/cache, logs/queue
run/cache, run/queue

2.3.3 权限控制

2.3.4 依赖库的准备

系统版本：CentOS Linux release 7.2.1511 (Core) x64
gcc, tcl 相关依赖

1. 通过 RPM 安装 （rpm –ivh [*.rpm]）
   下载 rpm 安装包 参考网址 http://www.rpmfind.net/
2. 通过 YUM 安装
   yum install -y gcc-c++
   yum install -y tcl

2.3.5 REDIS安装包准备

注：一般取 redis 最新的稳定版

3 安装与配置

Redis 以最新发布的 4.0 稳定版本作为示例。

3.1 安装流程

3.1.1 官网查看版本

https://redis.io/download
在此网址中，查看 Stable 版本，并关注 ，确认此版本发布升级的紧迫性和修复的一些 bugs：

3.1.2 官网下载和安装

Linux 以 redis 用户操作：
cd /u01/app/redis/
wget http://download.redis.io/releases/redis-4.0.0.tar.gz
tar xzf redis-4.0.0.tar.gz
cd redis-4.0.0
make
make test

安装和测试过程中无任何异常时，即安装成功。

( 安装异常遗留问题，可用 make distclean 命令清理后再 make )
###########################################################

如果直接make可以通过，就不用加MALLOC参数，尽量不要加此选项，否则内存分配策略则会设置为libc

make MALLOC=libc

采用tcmalloc时碎片率是最低的，为1.01，jemalloc为1.02，而libc的分配器碎片率为1.31，我们一般采用默认jemalloc。

##########################################################

原始文件路径：
REDIS_BIN=$REDIS_HOME/redis-4.0.0
redis.conf : $REDIS_BIN/redis.conf sentinel.conf : $REDIS_BIN/sentinel.conf REDIS_SRC=$REDIS_HOME/redis-4.0.0/src/

3.1.3 配置环境变量

Linux 以 redis 用户操作：

vi ~/.bash_profile

添加内容
REDIS_SRC=/u01/app/redis/redis-4.0.0/src/
PATH= $PATH:$REDIS_SRC

source ~/.bash_profile

生效后，即可直接使用 redis-cli, redis-server, redis-sentinel, redis-benchmark 等命令。如(示例)：
redis-cli –p 5230 –a passwrodtest info

3.1.4 将Redis注册为Linux服务

redis_init_script.sh 脚本

// An highlighted block
#!/bin/sh
#chkconfig: 2345 55 25
#
# Simple Redis init.d script conceived to work on Linux systems
# as it does use of the /proc filesystem.
REDISDIR=/home/redisdev/app/redis
EXEC=${REDISDIR}/redis-3.2.8/src/redis-server
CLIEXEC=${REDISDIR}/redis-3.2.8/src/redis-cli

REDISPORT=$1
REDISROLE=$2
REDISAUTH=$3
PIDFILE=${REDISDIR}/run/${REDISROLE}/redis_${REDISPORT}.pid
CONF=${REDISDIR}/config/${REDISROLE}/redis_${REDISPORT}.conf

case "$4" in
   start)
       if [ -f $PIDFILE ]
       then
               echo "$PIDFILE exists, process is already running or crashed"
       else
               echo "Starting Redis server..."
               $EXEC $CONF &
       fi
       ;;
   stop)
       if [ ! -f $PIDFILE ]
       then
               echo "$PIDFILE does not exist, process is not running"
       else
               PID=$(cat $PIDFILE)
               echo "Stopping ..."
               $CLIEXEC -p $REDISPORT -a $REDISAUTH shutdown
               while [ -x /proc/${PID} ]
               do
                   echo "Waiting for Redis to shutdown ..."
                   sleep 1
               done
               echo "Redis stopped"
       fi
       ;;
   status)
       if  [ ! -n "$5" ]
       then
               $CLIEXEC -p $REDISPORT -a $REDISAUTH info default
       else
               $CLIEXEC -p $REDISPORT -a $REDISAUTH info $5
       fi
       ;;
    *)
       echo "Please use start, stop, status as fourth argument!"
       ;;
esac

$5 命令 (info command)：server，clients，memory，persistence，stats，replication，cpu，commandstats，cluster，keyspace，all(详细信息)
Linux 以 root 用户操作：

cp /u01/app/redis/redis_init_script.sh /etc/rc.d/init.d/redis
chkconfig --add redis

Linux 以 redis 用户检验：

service redis [port] [role] [auth] [start/stop/status] [info command]

3.1.5 redis.conf 文件安置

将 redis.conf 文件按照端口号和角色分别放置到不同的 config/[role]/ 目录下，并按照 redis_[port].conf。

cp /u01/app/redis/redis-4.0.0/redis.conf /u01/app/redis/config/cache/redis_5230.conf
cp /u01/app/redis/redis-4.0.0/redis.conf /u01/app/redis/config/queue/redis_5240.conf

3.2 配置启动

3.2.1 redis.conf 主要配置

redis.conf 配置主要属性简介：
 单位，当为某个配置项指定内存大小的时候, 必须要带上单位, 通常的格式就是 1k 5gb 4m 等；单位是不区分大小写的, 如: 1GB 1Gb 1gB 都是相同的含义。
1k => 1000 bytes
1kb => 1024 bytes
1m => 1000000 bytes
1mb => 10241024 bytes
1g => 1000000000 bytes
1gb => 10241024*1024 bytes
include，有一个可用于所有的redis的标准配置模板, 但针对某些redis又需要一些个性化的设置, 此时可以使用include来包含一些其他的配置文件. 可以引入多个redis的配置，注意: include的配置文件是不能被config rewrite命令改写的！
即通常使用用法: 个性化的配置文件在文件的最开始地方引入标准的配置文件。
include /path/to/local.conf
include /path/to/other.conf
bind，绑定的网络接口(网卡)，安全设置，默认绑定本地，即仅本地可访问REDIS Server，可加上绑定hostname，保证在同一内网下其他机器能访问 REDIS Server。
bind 127.0.0.1 ::1
bind 192.168.1.100 10.0.0.1
protected-mode，保护模式，默认开启，安全设置，一般在未设置 bind 或者 password 时，需要开启此设置，否则关掉。（常用是关掉，设置密码）
protected-mode no
port，端口号，启动 REDIS Server 实例的端口定义
daemonize，REDIS 是否作为守护进程运行，与 pidfile 配置属性结合使用，一般情况下为 yes
daemonize yes
pidfile /u01/app/redis/run/cache/redis_6379.pid
loglevel，日志等级，默认 notice，不调整。
debug (a lot of information, useful for development/testing)
verbose (many rarely useful info, but not a mess like the debug level)
notice (moderately verbose, what you want in production probably)
warning (only very important / critical messages are logged)
loglevel notice
logfile，日志文件路径。
logfile “/u01/app/redis/logs/cache/redis_6379.log”
dbfilename， RDB 持久化文件名
dbfilename cache_dump_6379.rdb
dir，REDIS 持久化文件存放目录
dir “/u01/app/redis/data/cache/”
slave-read-only，REDIS 从实例只读模式，默认 yes
slave-read-only yes
slave-priority，设置 REDIS 从实例的优先级，一般是供 sentinel 使用，即在主节点宕机时，选举优先级最高的从实例作为主节点。一般数字越小，优先级越高。
there are three slaves with priority 10, 100, 25 Sentinel will pick the one with priority 10, that is the lowest. By default, the priority is 100.
slave-priority 100
min-slaves-to-write，主从数据同步配置，保证至少有[n]个slave工作良好情况下才允许写入，默认是3，一般配置为1，即保证至少有一个从实例是正常的允许主实例进行写操作。
min-slaves-to-write 1
 min-slaves-max-lag，主从数据同步配置，延迟小于 min-slaves-max-lag 秒的slave 才认为是健康的slave，配合 min-slaves-max-lag 配置使用，若配置：
min-slaves-to-write 3
min-slaves-max-lag 10
代表含义：假如有大于等于3个从实例的连接延迟大于10秒，那么主实例就不再接受外部的写请求。
上述两个配置中有一个被置为0，则这个特性将被关闭。
slaveof，命令也是配置，一般情况下，主节点默认不配置此属性，但是从节点需要配置此属性，确保从实例监听主实例，从主实例能够请求数据同步。
（从实例）slaveof 192.168.1.100 6379
masterauth，如果master设置了requirepass，那么slave要连上master，需要有master的密码才行。masterauth就是用来配置master的密码，这样可以在连上master后进行认证。
masterauth xxxxxxxxx
requirepass，用户使用AUTH命令来认证密码，才能使用其他命令。使用requirepass的时候需要注意，因为redis太快了，每秒可以认证15w次密码，简单的密码很容易被攻破，所以最好使用一个更复杂的密码。
requirepass xxxxxxxxx
maxclients，设置能连上redis的最大客户端连接数量。默认是10000个客户端连接。由于redis不区分连接是客户端连接还是内部打开文件或者和slave连接等，所以maxclients最小建议设置到32。如果超过了maxclients，redis会给新的连接发送’max number of clients reached’，并关闭连接。
maxclients 4096 （与Linux系统配置-打开文件数有关系）
maxmemory-policy，内存容量超过maxmemory后的处理策略：

volatile-lru：利用LRU算法移除设置过过期时间的key。

volatile-random：随机移除设置过过期时间的key。

volatile-ttl：移除即将过期的key，根据最近过期时间来删除（辅以TTL）

allkeys-lru：利用LRU算法移除任何key。

allkeys-random：随机移除任何key。

noeviction：不移除任何key，只是返回一个写错误。

一般用默认的 noeviction 。上面的这些驱逐策略，如果redis没有合适的key驱逐，对于写命令，还是会返回错误。redis将不再接收写请求，只接收get请求。写命令包括：set setnx setex append incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby getset mset msetnx exec sort。
maxmemory，redis配置的最大内存容量。当内存满了，需要配合maxmemory-policy策略进行处理。注意slave的输出缓冲区是不计算在maxmemory内的。所以为了防止主机内存使用完，建议设置的maxmemory需要更小一些。
appendfilename，AOF 持久化文件名称
appendfilename “cache-aof-6379.aof”

3.2.2 sentinel.conf 主要配置

port，端口号，启动 Sentinel Server 实例的端口定义
port 26379
protected-mode 请见 redis.conf 配置
bind 请见 redis.conf 配置
dir 请见 redis.conf 配置
logfile 请见 redis.conf 配置
sentinel monitor
quorum是一个数字，指明当有< quorum >个sentinel认为当前监控master失效时，此master才算真正失效。master-name只能包含英文字母，数字，和“.-_”这三个字符；master-ip 要写真实的ip地址而不要用回环地址(127.0.0.1)。
sentinel monitor test-server 192.168.1.100 6379 2
sentinel auth-pass 设置连接master和slave时的密码，注意的是sentinel不能分别为master和slave设置不同的密码，因此master和slave的密码应该设置相同。
sentinel auth-pass cache-server xxxxxxxxx
sentinel down-after-milliseconds 指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒
sentinel down-after-milliseconds cache-server 30000
sentinel parallel-syncs 指定了在发生failover主备切换时最多可以有个slave同时对新的master进行同步，这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越多的slave因为replication而不可用。可以通过将这个值设为1来保证每次只有一个slave 处于不能处理命令请求的状态。
sentinel parallel-syncs cache-server 1
sentinel failover-timeout 可以用在以下这些方面：

1. 同一个sentinel对同一个master两次failover之间的间隔时间。

2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠 正为向正确的master那里同步数据时。

3. 当想要取消一个正在进行的failover所需要的时间。

4. 当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了。

sentinel failover-timeout cache-server 180000

3.2.3 INFO 命令及属性说明

参考链接：http://redisdoc.com/server/info.html
info 命令 以一种易于解释（parse）且易于阅读的格式，返回关于 Redis 服务器的各种信息和统计数值。
通过给定可选的参数 [section] ，可以让命令只返回某一部分的信息：
 [server] 部分记录了 Redis 服务器的信息，它包含以下域：
 redis_version : Redis 服务器版本
 redis_git_sha1 : Git SHA1
 redis_git_dirty : Git dirty flag
 os : Redis 服务器的宿主操作系统
 arch_bits : 架构（32 或 64 位）
 multiplexing_api : Redis 所使用的事件处理机制
 gcc_version : 编译 Redis 时所使用的 GCC 版本
 process_id : 服务器进程的 PID
 run_id : Redis 服务器的随机标识符（用于 Sentinel 和集群）
 tcp_port : TCP/IP 监听端口
 uptime_in_seconds : 自 Redis 服务器启动以来，经过的秒数
 uptime_in_days : 自 Redis 服务器启动以来，经过的天数
 lru_clock : 以分钟为单位进行自增的时钟，用于 LRU 管理
 [clients] 部分记录了已连接客户端的信息，它包含以下域：
 connected_clients : 已连接客户端的数量（不包括通过从属服务器连接的客户端）
 client_longest_output_list : 当前连接的客户端当中，最长的输出列表
 client_longest_input_buf : 当前连接的客户端当中，最大输入缓存
 blocked_clients : 正在等待阻塞命令（BLPOP、BRPOP、BRPOPLPUSH）的客户端的数量
 [memory] 部分记录了服务器的内存信息，它包含以下域：
 used_memory : 由 Redis 分配器分配的内存总量，以字节（byte）为单位
 used_memory_human : 以人类可读的格式返回 Redis 分配的内存总量
 used_memory_rss : 从操作系统的角度，返回 Redis 已分配的内存总量（俗称常驻集大小）。这个值和 top 、 ps 等命令的输出一致。
 used_memory_peak : Redis 的内存消耗峰值（以字节为单位）
 used_memory_peak_human : 以人类可读的格式返回 Redis 的内存消耗峰值
 used_memory_lua : Lua 引擎所使用的内存大小（以字节为单位）
 mem_fragmentation_ratio : used_memory_rss 和 used_memory 之间的比率
 mem_allocator : 在编译时指定的， Redis 所使用的内存分配器。可以是 libc 、 jemalloc 或者 tcmalloc 。
在理想情况下， used_memory_rss 的值应该只比 used_memory 稍微高一点儿。
当 rss > used ，且两者的值相差较大时，表示存在（内部或外部的）内存碎片。内存碎片的比率可以通过 mem_fragmentation_ratio 的值看出。
当 used > rss 时，表示 Redis 的部分内存被操作系统换出到交换空间了，在这种情况下，操作可能会产生明显的延迟。
Because Redis does not have control over how its allocations are mapped to memory pages, high used_memory_rss is often the result of a spike in memory usage.
当 Redis 释放内存时，分配器可能会，也可能不会，将内存返还给操作系统。
如果 Redis 释放了内存，却没有将内存返还给操作系统，那么 used_memory 的值可能和操作系统显示的 Redis 内存占用并不一致。
查看 used_memory_peak 的值可以验证这种情况是否发生。
 [persistence] 部分记录了跟 RDB 持久化和 AOF 持久化有关的信息，它包含以下域：
 loading : 一个标志值，记录了服务器是否正在载入持久化文件。
 rdb_changes_since_last_save : 距离最近一次成功创建持久化文件之后，经过了多少秒。
 rdb_bgsave_in_progress : 一个标志值，记录了服务器是否正在创建 RDB 文件。
 rdb_last_save_time : 最近一次成功创建 RDB 文件的 UNIX 时间戳。
 rdb_last_bgsave_status : 一个标志值，记录了最近一次创建 RDB 文件的结果是成功还是失败。
 rdb_last_bgsave_time_sec : 记录了最近一次创建 RDB 文件耗费的秒数。
 rdb_current_bgsave_time_sec : 如果服务器正在创建 RDB 文件，那么这个域记录的就是当前的创建操作已经耗费的秒数。
 aof_enabled : 一个标志值，记录了 AOF 是否处于打开状态。
 aof_rewrite_in_progress : 一个标志值，记录了服务器是否正在创建 AOF 文件。
 aof_rewrite_scheduled : 一个标志值，记录了在 RDB 文件创建完毕之后，是否需要执行预约的 AOF 重写操作。
 aof_last_rewrite_time_sec : 最近一次创建 AOF 文件耗费的时长。
 aof_current_rewrite_time_sec : 如果服务器正在创建 AOF 文件，那么这个域记录的就是当前的创建操作已经耗费的秒数。
 aof_last_bgrewrite_status : 一个标志值，记录了最近一次创建 AOF 文件的结果是成功还是失败。
如果 AOF 持久化功能处于开启状态，那么这个部分还会加上以下域：
 aof_current_size : AOF 文件目前的大小。
 aof_base_size : 服务器启动时或者 AOF 重写最近一次执行之后，AOF 文件的大小。
 aof_pending_rewrite : 一个标志值，记录了是否有 AOF 重写操作在等待 RDB 文件创建完毕之后执行。
 aof_buffer_length : AOF 缓冲区的大小。
 aof_rewrite_buffer_length : AOF 重写缓冲区的大小。
 aof_pending_bio_fsync : 后台 I/O 队列里面，等待执行的 fsync 调用数量。
 aof_delayed_fsync : 被延迟的 fsync 调用数量。
 [stats] 部分记录了一般统计信息，它包含以下域：
 total_connections_received : 服务器已接受的连接请求数量。
 total_commands_processed : 服务器已执行的命令数量。
 instantaneous_ops_per_sec : 服务器每秒钟执行的命令数量。
 rejected_connections : 因为最大客户端数量限制而被拒绝的连接请求数量。
 expired_keys : 因为过期而被自动删除的数据库键数量。
 evicted_keys : 因为最大内存容量限制而被驱逐（evict）的键数量。
 keyspace_hits : 查找数据库键成功的次数。
 keyspace_misses : 查找数据库键失败的次数。
 pubsub_channels : 目前被订阅的频道数量。
 pubsub_patterns : 目前被订阅的模式数量。
 latest_fork_usec : 最近一次 fork() 操作耗费的毫秒数。
 [replication] 主/从复制信息
 role : 如果当前服务器没有在复制任何其他服务器，那么这个域的值就是 master ；否则的话，这个域的值就是 slave 。注意，在创建复制链的时候，一个从服务器也可能是另一个服务器的主服务器。
如果当前服务器是一个从服务器的话，那么这个部分还会加上以下域：
 master_host : 主服务器的 IP 地址。
 master_port : 主服务器的 TCP 监听端口号。
 master_link_status : 复制连接当前的状态， up 表示连接正常， down 表示连接断开。
 master_last_io_seconds_ago : 距离最近一次与主服务器进行通信已经过去了多少秒钟。
 master_sync_in_progress : 一个标志值，记录了主服务器是否正在与这个从服务器进行同步。
如果同步操作正在进行，那么这个部分还会加上以下域：
 master_sync_left_bytes : 距离同步完成还缺少多少字节数据。
 master_sync_last_io_seconds_ago : 距离最近一次因为 SYNC 操作而进行 I/O 已经过去了多少秒。
如果主从服务器之间的连接处于断线状态，那么这个部分还会加上以下域：
 master_link_down_since_seconds : 主从服务器连接断开了多少秒。
以下是一些总会出现的域：
 connected_slaves : 已连接的从服务器数量。
对于每个从服务器，都会添加以下一行信息：
 slaveXXX : ID、IP 地址、端口号、连接状态
 [cpu] 部分记录了 CPU 的计算量统计信息，它包含以下域：
 used_cpu_sys : Redis 服务器耗费的系统 CPU 。
 used_cpu_user : Redis 服务器耗费的用户 CPU 。
 used_cpu_sys_children : 后台进程耗费的系统 CPU 。
 used_cpu_user_children : 后台进程耗费的用户 CPU 。
 [commandstats] 部分记录了各种不同类型的命令的执行统计信息，比如命令执行的次数、命令耗费的 CPU 时间、执行每个命令耗费的平均 CPU 时间等等。对于每种类型的命令，这个部分都会添加一行以下格式的信息：
 cmdstat_XXX:calls=XXX,usec=XXX,usecpercall=XXX
 [cluster] 部分记录了和集群有关的信息，它包含以下域：
 cluster_enabled : 一个标志值，记录集群功能是否已经开启。
 [keyspace] 部分记录了数据库相关的统计信息，比如数据库的键数量、数据库已经被删除的过期键数量等。对于每个数据库，这个部分都会添加一行以下格式的信息：
 dbXXX:keys=XXX,expires=XXX

除上面给出的这些值以外， section 参数的值还可以是下面这两个：
[all] : 返回所有信息
[default] : 返回默认选择的信息
当不带参数直接调用 info 命令时，使用 default 作为默认参数。

Note
不同版本的 Redis 可能对返回的一些域进行了增加或删减。
因此，一个健壮的客户端程序在对 INFO 命令的输出进行分析时，应该能够跳过不认识的域，并且妥善地处理丢失不见的域。

3.2.4 MEMORY 命令（Redis 4.0 支持）

 MEMORY USAGE [SAMPLES ] - Estimate memory usage of key
估算储存给定键所需的内存
 MEMORY STATS - Show memory usage details
查看 Redis 当前的内存使用情况
 MEMORY PURGE - Ask the allocator to release memory
要求分配器释放更多内存
 MEMORY MALLOC-STATS - Show allocator internal stats
展示分配器内部状态

3.2.5 sentinel 启动

sentinel 建议使用使用守护进程启动，启动方式：

1. 使用nohub来启动sentinel，使得进程在后台启动以及在指定目录记录日志信息：
   nohup /u01/app/redis/redis-4.0.0/bin/redis-sentinel /u01/app/redis/config/cache/sentinel_cache.conf >> /u01/app/redis/logs/cache/sentinel_26379.log 2>&1 &
2. 在sentinel的配置文件中添加以下内容：

daemonize yes
logfile "/u01/app/redis/logs/cache/sentinel_26379.log"

redis-sentinel /u01/app/redis/config/cache/sentinel_cache.conf 或者
redis-server /u01/app/redis/config/cache/sentinel_cache.conf --sentinel
一般建议第一种方式，并附脚本：(也可跟 redis 一致，注册成 linux 服务)

#!/bin/sh
#chkconfig: 2345 55 25
#
# Simple Redis init.d script conceived to work on Linux systems
# as it does use of the /proc filesystem.

REDISDIR=/u01/app/redis
EXEC=${REDISDIR}/redis-4.0.0/src/redis-sentinel

REDISPORT=$1
REDISROLE=$2
PIDFILE=${REDISDIR}/run/${REDISROLE}/sentinel_${REDISPORT}.pid
CONF=${REDISDIR}/config/${REDISROLE}/sentinel_${REDISPORT}.conf
LOGFILE=${REDISDIR}/logs/${REDISROLE}/sentinel_${REDISPORT}.log

case "$3" in
   start)
       if [ -f $PIDFILE ]
       then
               echo "$PIDFILE exists, process is already running or crashed"
       else
               echo "Starting Redis Sentinel server..."
               nohup $EXEC $CONF >> $LOGFILE &
               echo $! > ${PIDFILE}
               echo PID:$!
       fi
       ;;
   stop)
       # Source function library.
       . /etc/rc.d/init.d/functions
       # Source networking configuration.
       . /etc/sysconfig/network

       if [ ! -f $PIDFILE ]
       then
               echo "$PIDFILE does not exist, process is not running";failure;echo
               exit 1
       else
               read PID < ${PIDFILE}
       fi
       if checkpid ${PID};
       then
               kill -9 ${PID}
               echo -n "Redis Sentinel Stopping ..."
               while checkpid ${PID}; do
                    echo -n "."
                    sleep 1;
               done
      	       success;echo;rm -f ${PIDFILE}
       else
              failure;echo
       fi
       ;;
   *)
       echo "Please use start or stop as third argument"
       ;;
esac

3.3 持久化说明

3.3.1 RDB 持久化

在指定的时间间隔内将内存中的数据集快照写入磁盘，也是默认的持久化方式。
client 可以使用save或者bgsave命令通知redis做一次快照持久化。save操作是在主线程中保存快照的，由于redis是用一个主线程来处理所有 client的请求，这种方式会阻塞所有client请求。所以不推荐使用。
注意：每次快照持久化都是将内存数据完整写入到磁盘一次，并不是增量的只同步脏数据。如果数据量大的话，而且写操作比较多，必然会引起大量的磁盘io操作，可能会严重影响性能。
配置：

注释掉“save”这一行配置项就可以让保存数据库功能失效

设置redis进行数据库镜像的频率。

900秒（15分钟）内至少1个key值改变（则进行数据库保存–持久化）

300秒（5分钟）内至少10个key值改变（则进行数据库保存–持久化）

60秒（1分钟）内至少10000个key值改变（则进行数据库保存–持久化）：

save 900 1
save 300 10
save 60 10000
运作方式，当 Redis 需要保存 *.rdb 文件时， 服务器执行以下操作：
a) redis调用fork,现在有了子进程和父进程。
b) 父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制 (copy on write) 父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。
c) 当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。
优点：
 整个Redis数据库将只包含一个文件，可以很容易的将一个一个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 重写的执行间隔有多长，数据的耐久性都不会有任何损失。

3.3.2 AOF 持久化

将每一个收到的写命令都通过write函数追加到文件中，文件名见配置（redis.conf appendfilename）
当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上，这样aof方式的持久化也还是有可能会丢失部分修改。不过可以通过配置文件告诉redis，我们想要通过fsync函数强制os写入到磁盘的时机。
fsync 函数在 redis.conf 配置有三种方式如下（默认是：每秒 fsync一次）:
 appendonly yes //启用aof持久化方式
 # appendfsync always //每次收到写命令就立即强制写入磁盘，最慢的，但是保证完全的持久化，不推荐使用
 appendfsync everysec //每秒钟强制写入磁盘一次，在性能和持久化方面做了很好的折中，推荐
 # appendfsync no //完全依赖os，性能最好,持久化没保证
AOF 的方式也同时带来了另一个问题。持久化文件会变的越来越大。例如我们调用incr test命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条set test 100就够了。
所以对于AOF持久化来说，有重写AOF文件的机制。（命令：bgrewriteaof）具体流程如下：
a) redis调用fork ，现在有父子两个进程
b) 子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令
c) 父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。
d) 当子进程把快照内容写入已命令方式写到临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。
e) 现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。
需要注意到是重写aof文件的操作，并没有读取旧的aof文件，而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
自动重写的配置：
 auto-aof-rewrite-percentage，aof自动重写配置。当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
 auto-aof-rewrite-min-size，设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。
基于性能的考虑，正常情况下会将自动重写AOF关掉，通过Linux CronTab做执行计划定期执行aof重写命令。
auto-aof-rewrite-percentage 0
auto-aof-rewrite-min-size 0
优点：
 使用 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 的。
注意：在重写AOF过程中，要保证剩余内存空间足够大(>=当前重写Redis使用内存)，否则会报错！

3.3.3 RDB-AOF 混合持久化（Redis 4.0 支持）

Redis 4.0 新增了 RDB-AOF 混合持久化格式， 这是一个可选的功能， 在开启了这个功能之后， AOF 重写产生的文件将同时包含 RDB 格式的内容和 AOF 格式的内容， 其中 RDB 格式的内容用于记录已有的数据， 而 AOF 格式的内存则用于记录最近发生了变化的数据， 这样 Redis 就可以同时兼有 RDB 持久化和 AOF 持久化的优点 —— 既能够快速地生成重写文件， 也能够在出现问题时， 快速地载入数据。
这个功能可以通过 aof-use-rdb-preamble 选项进行开启， redis.conf 文件中记录了这个选项的使用方法：

# When rewriting the AOF file, Redis is able to use an RDB preamble in the
# AOF file for faster rewrites and recoveries. When this option is turned
# on the rewritten AOF file is composed of two different stanzas:
#
#   [RDB file][AOF tail]
#
# When loading Redis recognizes that the AOF file starts with the "REDIS"
# string and loads the prefixed RDB file, and continues loading the AOF
# tail.
#
# This is currently turned off by default in order to avoid the surprise
# of a format change, but will at some point be used as the default.

aof-use-rdb-preamble no