redis使用sysc超时_Redis配置解析、持久化与哨兵模式

一、redis基础配置

１、进入redis界面：redis-cli -h IP/HOSTNAME -p PORT -a PASSWORD

２、查看redis版本信息：进入客户端界面后，输入info

３、配置文件：

networking配置

(1)bind 0.0.0.0：监听地址，可以用空格隔开后多个监听ip

(2)protected-mode yes：保护模式

下图所示，保护模式打开时候，未设置监听地址或者未输入密码时候会有保护提升

关闭保护模式或者取消bind 0.0.0.0的注释，都可以正常使用redis

(3)port 6379：默认监听端口更改处

(4)tcp-backlog 511：三次握手时候server端收到client的ack确认号之后的队列值

(5)timeout 0：客户端和redis服务的连接超时时间，默认是0，表示永不超时；此处客户端不是redis的client，是使用redis数据的java程序；若设置了时长，超时后再连接java程序会与redis重新三次握手；为防止不回收长连接造成数据库卡，建议设置时长

(6)tcp-keepalived 300：tcp会话保持时间，300s

general配置

(7)daemonize　yes：是否在后台运行

(8)supervised no：UOS与CentOS7后都是用systemctl进行启动redis，此处就设置为no即可

(9)pidfile /var/run/redis/redis-server.pid：redis的pid文件位置更改处，一台服务器上redis多实例请务必标清各pid位置

(10)loglevel notice：log记录等级

(11)logfile /var/log/redis/redis-server.log：log日志记录位置，一台服务器上redis多实例请务必标清各log位置

(12)databases 16：设置redis数据库默认数量

(13)always-show-logo yes：logo显示

rdb快照配置：

(14)save ：表示key在多少秒内，至少发生了多少次变化后，重写rdb文件；多个save写到上下行，表示或的关系

(15)stop-writes-on-bgsave-error yes：快照出错时是否禁止redis写入操作，如果设置yes，当redis的服务器磁盘满，快照无法写入时redis会报错影响正常业务使用，若设置为no不理会该项错误，业务正常运行

(16)rdbcompression yes：是否开启压缩

(17)rdbchecksum yes：是否开启校验

(18)dbfilename dump.rdb：快照名称

(19)dir /var/lib/redis：快照存放地址

replication主从配置

(20)slaveof ：做哪台master的从机

(21)masterauth ：若主有密码，尖括号内填写密码，即可做redis的主从配置，并不用像关系型数据库的主从那样复杂

(22)replica-server-stable-data yes：当从库同主库失去连接或者复制正在进行时，从机有两种运行方式：

当此项为yes，从库会继续相应客户端的读请求，一般都用此项

当此项为no，除去指定的命令之外，任何请求都会返回一个错误”SYNC with master in progress”

(23)slave-read-only yes：设置从库只读，不允许写从库，避免主从数据不一致

(24)repl-diskless-sync no：是否使用socket方式复制数据

redis主从复制的两种方式：

第一种：基于硬盘，master创建一个新进程dump RDB，RDB完成之后由父进程传给slave。

第二种：基于socket，master创建一个新进程直接dump RDB到slave的socket，不经过主进程，也不经过硬盘。

基于硬盘的话，RDB文件创建后，一旦创建完毕可以同时服务更多的slave，但基于socket的话，新slave连接到master之后需要逐个同步数据。在磁盘IO较慢、网络较快时候可以用diskless，设置为yes，否则使用磁盘，此项设置为no

(25)repl-diskless-sync-delay 5：diskless(第24条设置为no)复制的延迟时间，设置0为关闭，单位为秒。在延迟时间内连接新的客户端，会一起通过disk方式同步数据。但是一旦开始复制并且还没有结束，master节点不会再接收新的slave复制请求，直到下一次同步开始

(26)repl-ping-salve-period 10：slave根据master指定的时间进行周期性的ping检测，是slave ping master

(27)repl-timeout　60：复制连接的超时时间，需要大于repl-ping-salve-period，否则会经常报超时

(28)repl-disable-tcp-nodelay no：在socket模式下是否在slave套接字发送SYNC之后禁用TCP_NODELAY，如果选择yes，redis将使用更少的tcp包和带宽来向slaves发送数据，但这将使数据传输到slave上有延迟；如果选择no，数据传输到slave的延迟将会减少但要使用更多的带宽

(29)repl-backlog-size 128M：复制缓冲区内存大小，只有在slave连接之后才分盘内存，结合具体情况设置，此大小独立于分配给redis的内存，给redis分的内存一般为系统总内存的一半

(30)repl-backlog-ttl 3600：多长时间master没有slave连接，就清空backlog缓冲区

(31)replica-priority 100：当master不可用，哨兵会根据slave的优先级选举一个master，最低优先级的slave当选master；此项若配置为0，将永远不会被选举

security配置

(32)requirepass 123456：设置密码

(33)*rename-command CONFIG ""：重命名命令，针对高危命令重命名，图例：

此处重命名flushall为b39a51，flushall已失效

clients配置

(34)maxclients 10000：最大连接数

memory management配置

(35)maxmemory ：最大内存分配，单位是字节，0为不限制内存，分配最好是总内存的一半

APPEND ONLY MODE：AOF模式，模式打开必须打开(36)

(36)appendoly no：是否开启AOF记录日志，默认redis使用rdb方式持久化，这种方式在许多应用中已经足够用了，但redis如果中途宕机，可能会导致数据丢失，丢失量取决于dump数据的间隔时间。AOF，是一种持久化方式，redis会把每次写入的数据在接收后都写入appendonly.aof文件，每次启动时都会把这个文件的数据读入内存里，忽略了rdb文件

(37)appendfilename “appendonly.aof”：AOF文件名

(38)appendfsync everysec：aof持久化策略的配置，no表示不执行fsync，由操作系统保证数据同步到磁盘；此项改为always，表示每次写入都会执行fsync，以保证数据同步到磁盘，会消耗磁盘IO；此项改为everysec，表示每秒执行一次fsync，特殊情况下，譬如某个不到1秒的时刻断电了，rsync没有来得及写，便可能会导致丢失1s的数据，不过通常情况下选该项比较好

fsync：打开AOF模式产生的aof文件，可以看到里面写好的１列信息，将redis数据按照这1列信息的格式，同步到磁盘的方式叫文件同步策略

(39)auto-aof-rewrite-percentage 100：aof日志到达多少百分比可以重写，设置0表示不自动重写，重写是为了使aof体积保持最小，同时还可以保存最完整的数据

(40)auto-aof-rewrite-min-size 64mb：触发aof日志重写最小文件大小

注：(39)和(40)两条一起看，计算时候是相乘的，(39)是百分比，数据量比较大时候可作为选项

(41)no-appendfsync-on-rewrite no：在aof重写期间，是否对aof的append新记录暂缓使用文件同步策略，主要考虑磁盘IO开支和请求阻塞时间。默认为no，表示不暂缓，新的aof记录仍然会被同步；由于linux默认的fsync策略是30秒，如果是yes，可能丢失30秒数据，但是yes性能较好而且会避免出现阻塞，所以推荐这个

(42)aof-use-rdb-preamble yes：是否加载由于其他原因导致的末尾异常的AOF文件(主进程被kill/断电等)

(43)aof-ues-rdb-preamble no：4.0新增功能，新增了rdb-aof混合持久化格式，aof重写产生的文件同时包含rdb格式的内容和aof格式的内容，其中rdb格式的内容用于记录已有的数据，而aof格式的内存用于记录最近发生了变化的数据，这样redis就同时拥有rdb持久化和aof持久化的优点：既能快速生成重写文件，也能够在出现问题时快速载入数据，还可以记录下来发生变化的数据，正是因为新增功能，目前推荐no

cluster模式

该模式下master有16384个槽位，由所有的master分摊这些槽位，只有Master才拥有槽的所有权，如果是某个Master的slave，这个slave只负责槽的使用，但是没有所有权

(44)cluster-enabled yes：开启集群模式，默认此行注释，不开启

(45)cluster-config-file nodes-6379.conf：集群配置文件名称

(46)cluster-node-timeout 15000：node节点多久没连接上就算超时，单位毫秒

(47)cluster-replica-validity-factor 10：故障转移时有些节点与master断开一段时间数据比较旧，这些节点就不适用于选举为master，超过这个时间就不会被进行故障转移，单位秒

(48)cluster-migration-barrier 1：集群迁移屏障，一个主节点至少拥有多少个正常工作的从节点，也就是说如果某个master节点的slave故障后，会将多余的从节点分配给这个master，作为它的新slave

(49)cluster-require-full-coverage no：在集群中，如果一个没有slave的主库宕机了，该库负责的槽位会丢失，此项选yes为不再对外提供服务；此项选no，可以继续使用但由于数据有丢失，会出现查询数据查不到的情况

slow log配置

slow log是redis用来记录查询执行时间的日志系统，slow log保存在内存里面，读写速度非常快，因此可以放心使用它，不必担心因为开启slow log而损害redis的速度

(50)slowlog-log-slower-than 10000：以微秒为单位的慢日志记录，为负数会禁用日志，为0会记录每个命令操作，10000微秒为10毫秒

(51)slowlog-max-len 128：记录多少条慢日志保存在队列，超出后会删除最早的，以此滚动删除

二、redis持久化-RDB模式

1、RDB模式：基于时间的快照，默认只保留当前最新的一次快照，特点是执行速度快，缺点是可能会丢失上次快照到当前时间点之间未做快照的数据，通俗而言，该模式下直接将rdb文件往内存中还原。

2、实现过程：redis从主进程fork出一个子进程，使用写时复制机制，子进程将内存的数据保存为一个临时文件(bgsave，对redis主进程不影响)，当数据保存完成之后再将上一次保存的RDB文件替换掉，然后关闭子进程。

3、优缺点

优点：

(1)保存了某个时间点的数据，可以通过脚本执行bgsave(非阻塞)或者save(阻塞)命令自定义时间点备份，可以保留多个备份，当出现问题可以恢复到不同时间点的版本

(2)可以最大化IO的性能，redis从主进程复制出一个子进程，然后操作都会由这个子进程操作，父进程无需任何的操作

(3)RDB在大量数据下，恢复的速度比AOF快

缺点：

(1)不能时刻保存数据，会丢失上一次执行RDB备份到当前的内存数据

(2)数据量非常大的时候，从父进程fork的时候需要时间，根据磁盘IO性能可能很快也可能几分钟

4、执行命令：

(1)SAVE： 手动输入save后立即执行，直接调用 rdbSave ，阻塞 Redis 主进程，直到保存完成为止。在主进程阻塞期间，服务器不能处理客户端的任何请求。

(2)BGSAVE：手动启动后后台保存操作，但不是立即执行。父进程fork 出一个子进程，子进程负责调用 rdbSave ，并在保存完成之后向主进程发送信号，通知保存已完成。 Redis 服务器在BGSAVE 执行期间仍然可以继续处理客户端的请求。

三、redis持久化-AOF模式

1、AOF：按照操作顺序依次将操作添加到指定的日志文件中，特点是数据安全性相对性较高，缺点是有些重复的操作也会全部记录。

2、AOF写数据过程：当客户端输入一条指令，服务器接收后redis并没有马上记录，而是放到了一个临时的区域，这个区域也就是AOF写命令的缓存区，到了一定阶段后，将这些命令同步到.aof文件中

3、实现过程：AOF使用了写时复制机制，AOF默认每秒fsync一次，即将执行的命令保存到AOF文件当中，这样即便redis服务器发生故障的话，顶多丢失1秒钟内的数据；或者可以设置fsync策略，fsync会在后台执行线程，而主线程可以继续处理用户的正常请求而不收到AOF的IO影响

4、aof持久化三种策略

(1)no，表示不执行fsync，由操作系统保证数据同步到磁盘；

(2)always，表示每次写入都会同步到AOF文件中，数据零误差，性能低；

(3)everysec，表示每秒将缓存区中的指令同步到AOF文件中，数据准确性较高，性能较高；系统突然宕机情况下可能会导致丢失1s的数据，不过通常情况下选该项比较好

四、哨兵模式

1、哨兵简介：哨兵sentinel是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master

2、哨兵作用：

(1)监控

不断检查master和slave是否正常运行

master存活检测、master与slave运行情况检测

(2)通知(提醒)

当被监控的服务器出现问题时，向其他哨兵或者客户端发送通知

(3)自动转移故障

断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址

(4)哨兵也是一台redis服务器，只是不提供数据服务；通常配置数量为单数，最少3台哨兵

3、哨兵搭建

(1)配置一拖二的主从结构

(2)配置哨兵

查看sentinel.conf

(3)启动哨兵

redis-sentinel sentinel-PORT.conf，不加配置文件按照默认配置文件启动

(4)配置文件：/etc/redis/sentinel.conf

<1>port：配置哨兵端口

<2>dir /tmp：哨兵信息存储位置

<3>sentinel monitor mymaster 127.0.0.1 6379 2：哨兵监控主机，主机名称为mymaster，ip和端口为127.0.0.1:6379，当有2个哨兵连接不到主机，则认定主机宕机，重写选举slave为master

<4>sentinel down-after-milliseconds mymaster 30000：哨兵连接名为mymaster的master超时时长，超过后认定master宕机，单位为毫秒

<5>sentinel parallel-syncs mymaster 1：新master上任后，最多有多少个slave同时对新的master进行同步，数字越小，完成故障转移后的同步时间就越长，但数字越大，越多的slave因为主从复制而暂不可用。设置为1即可。

<6>sentinel failover-timeout mymaster 180000：故障转移后的同步超时时间，超时后无效，单位为毫秒

4、哨兵工作原理：

(1)阶段一：监控阶段

同步各个节点的状态信息

获取各个sentinel的状态是否在线

获取master的状态：

master的属性

runid

role：master

各个slave的详细信息

获取所有slave的状态

slave属性

runid

role

master_host、master_port

(2)阶段二：通知阶段

维护长期信息对等的一个阶段，会有随机一台sentinel向redis集群master发送打招呼信息，看是否可以收到回应，如果收到回应，代表正常，在sentinel内网中向各sentinel发送正常信息，其他sentinel将会表示收到

当有1台sentinel检测到master宕机时，会将标记master为SRI_S_DOWN状态(主观下线)，随后该sentinel通知哨兵内网，其它sentinel也会去向master发送招呼信息，当有半数以上的sentinel均检测到master宕机，会将master标记为SRI_O_DOWN(客观下线)

(3)阶段三：故障转移阶段

master宕机后，各sentinel之间会进行投票选举，选出一个sentinel去处理以下事情：

<1>服务器列表中挑选备选master：在线的、响应快、与原master连接时间最短的、其他优先原则：优先级、offset、runid

<2>向新的master发送指令，取消之前它slave的ip和端口

向其他slave发送新的master ip和端口