一、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 <seconds> <changes>：表示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 <masterip> <masterport>：做哪台master的从机
（21）masterauth <master-password>：若主有密码，尖括号内填写密码，即可做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 <bytes>：最大内存分配，单位是字节，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和端口
来源：oschina
链接：https://my.oschina.net/u/4262150/blog/4757578