redis基础

一. redis简介

Redis 是一个开源（BSD许可）的，基于内存的数据结构存储系统，它可以用作数据库、缓存和消息中间件. 它支持多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 集合（sets）， 有序集合（sorted sets）等

Redis的高效

即使是普通笔记本(4c8g)也可以轻松处理每秒几十万的请求。

高效的原因:

1. redis是基于内存的，内存的读写速度非常快；
2. redis是单线程的，省去了很多上下文切换线程的时间和资源竞争时的加锁；
3. redis使用多路复用技术，可以处理并发的连接。非阻塞IO内部实现采用epoll，采用了epoll+自己实现的简单的事件框架。epoll中的读、写、关闭、连接都转化成了事件，然后利用epoll的多路复用特性，绝不在io上浪费一点时间。

补充I/O多路复用,相当于在内核中存在一个队列,记录每个I/O事件.而单进程与内核之间的可以存在多个I/O事件.每个事件可以放入此队列中.当事件的数据流抵达内核中时,会唤醒这个I/O事件,然后通知进程提取数据.select、poll并不能准确的知道队列中是哪个I/O事件数据流抵达只会轮询一遍并不高效.
而最新的epoll可以准确的知道那个I/O事件流.该模型在linux2.6以后支持.

无法发挥多核CPU性能，不过可以通过在单机开多个Redis实例来完善,当然前提是要内存足够大.

Redis 和 Memcached 的区别

1. memcache需要事先分配一块内存池,redis不需要
2. redis的数据可以持久化存储在磁盘中,memcache数据无法持久化一旦断电数据全无;一旦事先分配的内存池用完,旧数据也会被覆盖.
3. redis支持的除K/V以外还有其他数据类型,而memcache只支持K/V
4. redis对于存储的数据除了读写,还能有其他操作如排序,自递增等.

如果需要缓存的数据只是key-value 这样简单的结构时，采用Memcache，足够稳定可靠。如果有持久化需求、存储、排序等一系列复制操作时，或者对数据结构和处理有高级要求的应用，选择Redis。

二. redis的部署

yum install gcc-c++ tcl -y
tar xvf redis-3.2.10.tar.gz
cd redis-3.2.10
mkdir -p /usr/local/redis/{conf,data,logs}
make PREFIX=/usr/local/redis
make PREFIX=/usr/local/redis install
cp redis.conf /usr/local/redis/conf/redis.conf

#简单的修改配置内容
[root@redis ~]# vim /usr/local/redis/redis.conf 
bind 127.0.0.1   #监听的ip地址
port 6379        #端口
daemonize yes    #开启后台运行模式
pidfile /usr/local/redis/log/redis_6379.pid   #pid路径
logfile "/usr/local/redis/log/redis.log"  #日志路径
dir /usr/local/redis/data/redis_data     #数据保存路径

##启动redis
cd /usr/local/redis
##默认配置下会占据linux前台
bin/redis-server conf/redis.conf 

redis常见操作

keys *    //取出所有key,当存在大量key会严重阻塞redis正常工作
keys my* //模糊匹配,当存在大量key会严重阻塞redis正常工作
set KEY_NAME VALUE // 为某个键设定值,不论键是否存在.
setnx KEY_NAME VALUE // 如果KEY_NAME不存在则创建新的键值对，存在则创建失败
exists name  //有name键 返回1 ，否则返回0；
del  key1 // 删除一个key,成功返回1 ，否则返回0；
expire key1 100  //设置key1 100s后过期
EXPIREAT key  1579339550	 //该命令的逻辑功能和EXPIRE完全相同，唯一的差别是该命令指定的超时时间是绝对时间，而不是相对时间。该时间参数是Unix timestamp格式的，即从1970年1月1日开始所流经的秒数。
ttl key // 查看键还有多长时间过期，单位是s,当 key不存在时，返回 -2。当key 存在但没有设置剩余生存时间时，返回 -1 。 否则，返回 key 的剩余生存时间。
select  0  //代表切换当前的数据库，默认进入0 数据库
move age 1  // 把age移动到1数据库
persist key1   //取消key1的过期时间
randomkey //随机返回一个key
rename oldname newname //重命名key
renamenx oldname newname //重命名key，newname如果存在则创建失败
type key1 //返回键的类型
dbsize  //返回当前数据库中key的数目 dbsize的时间复杂度是O(1),Redis每次的添加的key都在固定的表中将数量加1 ，从而只需要查询一次，效率高
info  //返回redis数据库状态信息,排错必用
flushdb  //清空当前数据库中所有的键 谨慎操作
flushall  //清空所有数据库中的所有的key 谨慎操作
bgsave //保存数据到 rdb文件中，在后台运行
save //作用同上，但是在前台运行,不建议使用.
config get * //获取所有配置参数
config get dir  //获取配置参数
config set dir  //更改配置参数

数据恢复： 首先定义或者确定dir目录和dbfilename，然后把备份的rdb文件放到dir目录下面，重启redis服务即可恢复数据

redis 的监控

redis常用监控脚本.主要利用info命令获取redis运行状态

三. redis持久化

redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

• RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；
• AOF，就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。
如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式.

redis持久化 – RDB

RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。

对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。

redis持久化 – AOF

AOF，英文是Append Only File，即只允许追加不允许改写的文件。

AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。

我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。

默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。

因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。

在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性，这点大家可以放心。

AOF方式的另一个好处，我们通过一个“场景再现”来说明。某同学在操作redis时，不小心执行了FLUSHALL，导致redis内存中的数据全部被清空了，这是很悲剧的事情。不过这也不是世界末日，只要redis配置了AOF持久化方式，且AOF文件还没有被重写（rewrite），我们就可以用最快的速度暂停redis并编辑AOF文件，将最后一行的FLUSHALL命令删除，然后重启redis，就可以恢复redis的所有数据到FLUSHALL之前的状态了。是不是很神奇，这就是AOF持久化方式的好处之一。但是如果AOF文件已经被重写了，那就无法通过这种方法来恢复数据了。

虽然优点多多，但AOF方式也同样存在缺陷，比如在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。

如果你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。

如果运气比较差，AOF文件出现了被写坏的情况，也不必过分担忧，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：
1.备份被写坏的AOF文件
2.运行redis-check-aof –fix进行修复
3.用diff -u来看下两个文件的差异，确认问题点
4.重启redis，加载修复后的AOF文件

AOF重写

AOF重写的内部运行原理，我们有必要了解一下。

在重写即将开始之际，redis会创建（fork）一个“重写子进程”，这个子进程会首先读取现有的AOF文件，并将其包含的指令进行分析压缩并写入到一个临时文件中。

与此同时，主工作进程会将新接收到的写指令一边累积到内存缓冲区中，一边继续写入到原有的AOF文件中，这样做是保证原有的AOF文件的可用性，避免在重写过程中出现意外。

当“重写子进程”完成重写工作后，它会给父进程发一个信号，父进程收到信号后就会将内存中缓存的写指令追加到新AOF文件中。

当追加结束后，redis就会用新AOF文件来代替旧AOF文件，之后再有新的写指令，就都会追加到新的AOF文件中了。

对于我们应该选择RDB还是AOF，官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。

四. redis集群

redis主从

redis是支持主从同步的，而且也支持一主多从以及多级从结构。
主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的SORT就可以由从服务器来承担。
redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。
主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。(当会发生主从切换时,不建议关闭主服务器的持久化)

在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。但是从服务器仍然可以接受CONFIG等指令，所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此，那可以考虑给重要指令进行重命名，来避免命令被外人误执行。

主从同步原理

	阶段1:主从建立连接
		从节点发送slaveof  ip  port给主节点
		主节点接收到指令 响应从节点
		从节点保存主节点的ip和port,并根据响应信息建立和主节点的socket连接,之后周期性的ping主节点
		主节点回应pong给从节点
		从节点完成认证后发送replconf listening-port
		主节点保存从节点的端口号,完成连接建立


	阶段2:主同步数据给从节点
		1,从节点发送psync2 ? -1给主节点
		2,主节点执行bgsave,启动新的进程生成快照
		3,主节点创建复制缓冲区用于存储生成快照期间主节点接收的命令,并更新主节点的offset
		4 快照生成完毕后,主节点发送快照给从节点,也发送主节点的runid 和offset
		5 从节点根据快照恢复数据,恢复前清理从节点自身的数据,保存主节点的runid和offset(全量同步)
		6 从节点发送psync2 runid offset给主节点
		7 主节点接收runid和offset进行判断,runid与主节点是否相同,offset是否不在复制缓冲区中
			如果runid和offset有一个不满足,则执行全量复制
			如果offset相同则说明数据一致不需要进行部分复制
			如果offset不同则发送复制缓冲区中offset和从节点offset的区间命令
		8 从节点依次执行命令缓冲区中的命令


	阶段3:命令传播阶段
		从节点发送命令replconf ack offset给主节点
		主节点接收offset进行判断,offset已丢失不在复制缓冲区中
			offset不满足,则执行全量复制
			如果offset相同则说明数据一致不需要进行部分复制
			如果offset不同则发送复制缓冲区中offset和从节点offset的区间命令
		8 从节点依次执行命令缓冲区中的命令


	主从节点的心跳机制
		在命令传播阶段,主从节点互相传授心跳信息以判定主从集群是否正常工作
		master 每repl-ping-slave-period秒发送PING包给从节点,判定从节点是否在线
		slave 每秒发送replconf ack offset给主节点,判定主节点是否在线,并汇报复制偏移量以获取新的命令

另外，要说的一点是，即使有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，然后把持久化好的RDB文件发给多个下游。

补充无磁盘复制
通常来讲，一个完全重新同步需要在磁盘上创建一个RDB文件，然后加载这个文件以便为从服务器发送数据。如果使用比较低速的磁盘，这种操作会给主服务器带来较大的压力。Redis从2.8.18版本开始尝试支持无磁盘的复制。使用这种设置时，子进程直接将RDB通过网络发送给从服务器，不使用磁盘作为中间存储。

使用repl-diskless-sync配置参数来启动无磁盘复制

redis哨兵模式

Sentinel(哨兵)是用于监控redis集群中Master状态的工具，是Redis 的高可用性解决方案，sentinel哨兵模式已经被集成在redis2.4之后的版本中。sentinel是redis高可用的解决方案，sentinel系统可以监视一个或者多个redis master服务，以及这些master服务的所有从服务；当某个master服务下线时，自动将该master下的某个从服务升级为master服务替代已下线的master服务继续处理请求。一般建议sentinel采取奇数台，防止某一台sentinel无法连接到master导致误切换。其结构如下:

主观下线
sentinel会以每秒一次的频率向所有与其建立了命令连接的实例（master，从服务，其他sentinel）发ping命令，通过判断ping回复是有效回复，还是无效回复来判断实例是否在线（对该sentinel来说是“主观在线”）。

sentinel配置文件中的down-after-milliseconds设置了判断主观下线的时间长度，如果实例在down-after-milliseconds毫秒内，返回的都是无效回复，那么sentinel会认为该实例已（主观）下线，修改其flags状态为SRI_S_DOWN。如果多个sentinel监视一个服务，有可能存在多个sentinel的down-after-milliseconds配置不同，这个在实际生产中要注意。

客观下线
客观下线（Objectively Down， 简称 ODOWN）指的是多个（这个值可以配置） Sentinel 实例在对同一个服务器做出 SDOWN 判断， 并且通过 SENTINEL is-master-down-by-addr 命令互相交流之后， 得出的服务器下线判断，然后开启故障迁移（failover）。

sentinel（第一个发出主观下线的sentinel）通过发送 SENTINEL is-master-down-by-addr ip port current_epoch runid，（ip：主观下线的服务ip，port：主观下线的服务端口，current_epoch：sentinel的纪元，runid：*表示检测服务下线状态，如果是sentinel 运行id，表示用来选举领头sentinel）来询问其它sentinel是否同意服务下线。
一个sentinel接收另一个sentinel发来的is-master-down-by-addr后，提取参数，根据ip和端口，检测该master实例是否下线，并且回复is-master-down-by-addr，回复包含三个参数：down_state（1表示已下线，0表示未下线），leader_runid（领头sentinal id），leader_epoch（领头sentinel纪元）。
sentinel接收到回复后，根据设置的主观下线最小数量，如果达到这个值，既认为master服务客观下线。
客观下线条件只适用于主服务器： 只要一个 Sentinel 发现某个主服务器进入了客观下线状态， 这个 Sentinel 就可能会被其他 Sentinel 推选出， 并对失效的主服务器执行自动故障迁移操作。

Sentinel工作方式（每个Sentinel实例都执行的定时任务）
1）每个Sentinel以每秒钟一次的频率向它所知的Master，Slave以及其他 Sentinel 实例发送一个PING命令。
2）如果一个实例（instance）距离最后一次有效回复PING命令的时间超过 own-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的conf文件里有这么两个配置：
1）sentinel monitor

四个参数含义：
masterName这个是对某个master+slave组合的一个区分标识（一套sentinel是可以监听多套master+slave这样的组合的）。
ip 和 port 就是master节点的 ip 和 端口号。
quorum这个参数是进行客观下线的一个依据，意思是至少有 quorum 个sentinel主观的认为这个master有故障，才会对这个master进行下线以及故障转移。因为有的时候，某个sentinel节点可能因为自身网络原因，导致无法连接master，而此时master并没有出现故障，所以这就需要多个sentinel都一致认为该master有问题，才可以进行下一步操作，这就保证了公平性和高可用。

2）sentinel down-after-milliseconds
这个配置其实就是进行主观下线的一个依据，masterName这个参数不用说了，timeout是一个毫秒值，表示：如果这台sentinel超过timeout这个时间都无法连通master包括slave（slave不需要客观下线，因为不需要故障转移）的话，就会主观认为该master已经下线（实际下线需要客观下线的判断通过才会下线）

那么，多个sentinel之间是如何达到共识的呢？
这就是依赖于前面说的第二个定时任务，某个sentinel先将master节点进行一个主观下线，然后会将这个判定通过sentinel is-master-down-by-addr这个命令问对应的哨兵节点是否也同样认为该addr的master节点要做客观下线。最后当达成这一共识的sentinel个数达到前面说的quorum设置的这个值时，就会对该master节点下线进行故障转移。quorum的值一般设置为sentinel个数的二分之一加1，例如3个sentinel就设置2。

redis cluster

五. redis的性能分析和优化

通过查看redis运行状况来进行优化,使用如下命令

redis-cli -h hostip -p 6379 info 

命令输出结果有几大类
server,clients,memory,persistence,stats,replication,cpu,commandstats,cluster,keyspace

内存

used_memory:327494024  #由redis分配器分配的内存总量，以字节为单位
used_memory_human:312.32M  #以人类可读的格式返回redis分配的内存总量
used_memory_rss:587247616  #从操作系统的角度，redis已分配到的内存总量(俗称常驻集大小)。这个值和top命令的输出一致
used_memory_peak:1866541112    #redis的内存消耗峰值(以字节为单位) 
used_memory_peak_human:1.74G #以人类可读的格式返回redis的内存消耗峰值
used_memory_lua:35840  #lua引擎所使用的内存大小(以字节为单位)
mem_fragmentation_ratio:1.79   #used_memory_rss和used_memory之间的比率，小于1表示使用了swap，大于1表示碎片比较多
mem_allocator:jemalloc-3.6.0   #在编译时指定的redis所使用的内存分配器。可以是libc、jemalloc或者tcmalloc

问题一:redis中的数据量过大,使用了swap,会严重影响redis的性能.

1. 设置key的过期时间。若可以确定key大概的存活时间,就为key设置相应的过期时间,这样Redis会在key过期时自动删除key。到达限制Redis使用的最大内存。
2. 限制使用最大内容。在Redis配置文件中，通过设置“maxmemory”属性的值可以限制Redis最大使用的内存，修改后重启实例生效。 也可以使用客户端命令config set maxmemory 去修改值，这个命令是立即生效的，但会在重启后会失效，需要使用config rewrite命令去刷新配置文件。 若是启用了Redis快照功能，应该设置“maxmemory”值为系统可使用内存的45%，因为快照时需要一倍的内存来复制整个数据集，在快照期间会变成95%(45%+45%+5%)，其中5%是预留给其他的开销。 如果没开启快照功能，maxmemory最高能设置为系统可用内存的95%。

补充知识
当内存使用达到设置的最大阀值时，需要选择一种key的回收策略，可在Redis.conf配置文件中修改“maxmemory-policy”属性值。 若是Redis数据集中的key都设置了过期时间，那么“volatile-ttl”策略是比较好的选择。但如果key在达到最大内存限制时没能够迅速过期，或者根本没有设置过期时间。那么设置为“allkeys-lru”值比较合适，它允许Redis从整个数据集中挑选最近最少使用的key进行删除(LRU淘汰算法)。Redis还提供了一些其他淘汰策略，如下：

volatile-lru：使用LRU算法从已设置过期时间的数据集合中淘汰数据。
volatile-ttl：从已设置过期时间的数据集合中挑选即将过期的数据淘汰。
volatile-random：从已设置过期时间的数据集合中随机挑选数据淘汰。
allkeys-lru：使用LRU算法从所有数据集合中淘汰数据。
allkeys-random：从数据集合中任意选择数据淘汰
no-enviction：禁止淘汰数据。

Stats(一般统计信息)

total_connections_received:20956110 #新创建连接个数,如果新创建连接过多，过度地创建和销毁连接对性能有影响，说明短连接严重或连接池使用有问题，需调研代码的连接设置
total_commands_processed:222012347  #redis处理的命令数
instantaneous_ops_per_sec:279       #redis当前的qps，redis内部较实时的每秒执行的命令数
total_net_input_bytes:11851567878 #redis网络入口流量字节数
total_net_output_bytes:23636165127 #redis网络出口流量字节数
instantaneous_input_kbps:13.56    #redis网络入口kps
instantaneous_output_kbps:31.33   #redis网络出口kps
rejected_connections:0                                   #拒绝的连接个数，redis连接个数达到maxclients限制，拒绝新连接的个数
sync_full:1   #主从完全同步成功次数
sync_partial_ok:0 #主从部分同步成功次数
sync_partial_err:0     #主从部分同步失败次数
expired_keys:15598177   #运行以来过期的key的数量
evicted_keys:0   #运行以来剔除(超过了maxmemory后)的key的数量
keyspace_hits:1122202228     #命中次数
keyspace_misses:577781396    #没命中次数
pubsub_channels:0      #当前使用中的频道数量
pubsub_patterns:0   #当前使用的模式的数量
latest_fork_usec:15679 #最近一次fork操作阻塞redis进程的耗时数，单位微秒
migrate_cached_sockets:0  #

比如可以写个脚本，定期记录total_commands_processed的值。当客户端明显发现响应时间过慢时，可以通过记录的total_commands_processed历史数据值来判断单位时间内命令处理总数是上升趋势还是下降趋势，以便排查问题。

减少命令总数的方法

• 使用多参数的命令,即一个命令可以处理多个key,比如mset mget hmset hmget等
• 管道命令：把几个命令合并一起执行，从而减少因网络开销引起的延迟问题。因为10个命令单独发送到服务端会引起10次网络延迟开销，使用管道会一次性把执行结果返回，仅需要一次网络延迟开销。Redis本身支持管道命令，大多数客户端也支持，倘若当前实例延迟很明显，那么使用管道去降低延迟是非常有效的。

# Server(服务器信息)
redis_version:3.0.0                              #redis服务器版本
redis_git_sha1:00000000                  #Git SHA1
redis_git_dirty:0                                    #Git dirty flag
redis_build_id:6c2c390b97607ff0    #redis build id
redis_mode:cluster                              #运行模式，单机或者集群
os:Linux 2.6.32-358.2.1.el6.x86_64 x86_64 #redis服务器的宿主操作系统
arch_bits:64                                         #架构(32或64位)
multiplexing_api:epoll                        #redis所使用的事件处理机制
gcc_version:4.4.7                                #编译redis时所使用的gcc版本
process_id:12099                               #redis服务器进程的pid
run_id:63bcd0e57adb695ff0bf873cf42d403ddbac1565  #redis服务器的随机标识符(用于sentinel和集群)
tcp_port:9021                                #redis服务器监听端口
uptime_in_seconds:26157730   #redis服务器启动总时间，单位是秒
uptime_in_days:302                    #redis服务器启动总时间，单位是天
hz:10                                #redis内部调度（进行关闭timeout的客户端，删除过期key等等）频率，程序规定serverCron每秒运行10次。
lru_clock:14359959      #自增的时钟，用于LRU管理,该时钟100ms(hz=10,因此每1000ms/10=100ms执行一次定时任务)更新一次。
config_file:/redis_cluster/etc/9021.conf  #配置文件路径

# Clients(已连接客户端信息)
connected_clients:1081       #已连接客户端的数量(不包括通过slave连接的客户端)
client_longest_output_list:0 #当前连接的客户端当中，最长的输出列表，用client list命令观察omem字段最大值
client_biggest_input_buf:0   #当前连接的客户端当中，最大输入缓存，用client list命令观察qbuf和qbuf-free两个字段最大值
blocked_clients:0                   #正在等待阻塞命令(BLPOP、BRPOP、BRPOPLPUSH)的客户端的数量
# Persistence(rdb和aof的持久化相关信息)
loading:0                                                    #服务器是否正在载入持久化文件
rdb_changes_since_last_save:28900855 #离最近一次成功生成rdb文件，写入命令的个数，即有多少个写入命令没有持久化
rdb_bgsave_in_progress:0                  #服务器是否正在创建rdb文件
rdb_last_save_time:1482358115        #离最近一次成功创建rdb文件的时间戳。当前时间戳 - rdb_last_save_time=多少秒未成功生成rdb文件
rdb_last_bgsave_status:ok                   #最近一次rdb持久化是否成功
rdb_last_bgsave_time_sec:2                #最近一次成功生成rdb文件耗时秒数
rdb_current_bgsave_time_sec:-1        #如果服务器正在创建rdb文件，那么这个域记录的就是当前的创建操作已经耗费的秒数
aof_enabled:1                                          #是否开启了aof
aof_rewrite_in_progress:0                     #标识aof的rewrite操作是否在进行中
aof_rewrite_scheduled:0              
#rewrite任务计划，当客户端发送bgrewriteaof指令，如果当前rewrite子进程正在执行，那么将客户端请求的bgrewriteaof变为计划任务，待aof子进程结束后执行rewrite 
aof_last_rewrite_time_sec:-1            #最近一次aof rewrite耗费的时长
aof_current_rewrite_time_sec:-1      #如果rewrite操作正在进行，则记录所使用的时间，单位秒
aof_last_bgrewrite_status:ok             #上次bgrewriteaof操作的状态
aof_last_write_status:ok                     #上次aof写入状态
aof_current_size:4201740                 #aof当前尺寸
aof_base_size:4201687                    #服务器启动时或者aof重写最近一次执行之后aof文件的大小
aof_pending_rewrite:0                       #是否有aof重写操作在等待rdb文件创建完毕之后执行?
aof_buffer_length:0                             #aof buffer的大小
aof_rewrite_buffer_length:0              #aof rewrite buffer的大小
aof_pending_bio_fsync:0                  #后台I/O队列里面，等待执行的fsync调用数量
aof_delayed_fsync:0                          #被延迟的fsync调用数量
# Replication(主从信息，master上显示的信息)
role:master                               #实例的角色，是master or slave
connected_slaves:1              #连接的slave实例个数
slave0:ip=192.168.64.104,port=9021,state=online,offset=6713173004,lag=0 #lag从库多少秒未向主库发送REPLCONF命令
master_repl_offset:6713173145  #主从同步偏移量,此值如果和上面的offset相同说明主从一致没延迟
repl_backlog_active:1                   #复制积压缓冲区是否开启
repl_backlog_size:134217728    #复制积压缓冲大小
repl_backlog_first_byte_offset:6578955418  #复制缓冲区里偏移量的大小
repl_backlog_histlen:134217728   #此值等于 master_repl_offset - repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小

# Replication(主从信息，slave上显示的信息)
role:slave                                        #实例的角色，是master or slave
master_host:192.168.64.102       #此节点对应的master的ip
master_port:9021                          #此节点对应的master的port
master_link_status:up                   #slave端可查看它与master之间同步状态,当复制断开后表示down
master_last_io_seconds_ago:0  #主库多少秒未发送数据到从库?
master_sync_in_progress:0        #从服务器是否在与主服务器进行同步
slave_repl_offset:6713173818   #slave复制偏移量
slave_priority:100                          #slave优先级
slave_read_only:1                         #从库是否设置只读
connected_slaves:0                      #连接的slave实例个数
master_repl_offset:0         
repl_backlog_active:0                  #复制积压缓冲区是否开启
repl_backlog_size:134217728   #复制积压缓冲大小
repl_backlog_first_byte_offset:0 #复制缓冲区里偏移量的大小
repl_backlog_histlen:0           #此值等于 master_repl_offset - repl_backlog_first_byte_offset,该值不会超过repl_backlog_size的大小

# CPU(CPU计算量统计信息)
used_cpu_sys:96894.66             #将所有redis主进程在核心态所占用的CPU时求和累计起来
used_cpu_user:87397.39           #将所有redis主进程在用户态所占用的CPU时求和累计起来
used_cpu_sys_children:6.37     #将后台进程在核心态所占用的CPU时求和累计起来
used_cpu_user_children:52.83 #将后台进程在用户态所占用的CPU时求和累计起来

# Commandstats(各种不同类型的命令的执行统计信息)
cmdstat_get:calls=1664657469,usec=8266063320,usec_per_call=4.97  

#call每个命令执行次数,usec总共消耗的CPU时长(单位微秒),平均每次消耗的CPU时长(单位微秒)

# Cluster(集群相关信息)
cluster_enabled:1   #实例是否启用集群模式

# Keyspace(数据库相关的统计信息)
db0:keys=194690,expires=191702,avg_ttl=3607772262 #db0的key的数量,以及带有生存期的key的数,平均存活时间