redis入门一篇就够了！(两万字总结) 下-一一网

文章大纲：

15. conf配置文件分析

熟悉基本配置

redis的配置文件的位置是/usr/local/redis/redis-6.06 redis.conf，但我们平时将它拷贝到/usr/local/bin/myredisconfig redis.conf 来进行操作和修改配置文件。确保初始文件的安全。

在redis中查看基本的配置

config get *:获取全部的配置，可以查看配置是否修改成功。
Units单位

配置大小单位，开头定义了一些基本的度量单位，只支持bytes,不支持bit

对大小写不敏感
includes包含

和spring配置文件相似，可以通过includes包含，redis.conf作为总文件，可以包含其他文件。(读一下前面的英文说明即知)
network网络配置

bind 0.0.0.0 ：绑定的主机地址

protected-mode no：保护模式，默认为yes, 默认是开启，开启后Redis只会本地进行访问，拒绝外部访问.需要设置为yes

port 6379 :默认端口
general通用

daemonize yes：默认情况下，redis不作为守护进程运行，需要开启的话，改为yes

supervised no:可以通过upstart和systemd管理redis守护进程。

pidfile /var/run/redis_6379.pid：以后台进程的方式运行redis，则需要指定pid文件。

loglevel notice：日志级别。可选项有：

debug:记录大量日志信息，适用于开发，测试阶段

verbose:较多日志信息

notice：适量日志信息，适用于生产环境

warning：仅有部分重要，关键信息才会被记录

logfile “”：日志文件的位置，当指定为空字符串时，为标准输出。

databases 16：设置数据库的数目，默认数据库时DB 0

always-show-logo yes：是否总是显示logo
snapshopting快照

save 900 1：900秒(15分钟)内至少一个key值改变(则进行数据库保存–持久化)
save 300 10：300秒(5分钟内)至少10个key值改变(则进行数据库保存–持久化
save 60 10000： 60秒（1分钟）内至少10000个key值改变（则进行数据库保存–持久化）

stop-writes-on-bgsave-error yes：持久化出现错误后是否依然进行工作

rdbcompression yes：使用压缩rdb文件 yes：压缩但是需要一些cpu 的消耗 no:不压缩，需要更多的磁盘空间。

rdbchecksum yes：是否校验rdb文件，更有利于文件的容错性，但是在保存rdb文件的时候，会有大概10%的性能损耗

dbfilename dump.rdb：dbfilenamerdb文件名称

dir ./： dir 数据目录，数据库的写入会在这个目录。rdb、aof文件也会写在这个目录
security安全

获得和设置密码：（需要先进入redis）

config get requirepass

config set requirepass "123456"

然后每次登录redis时，都要使用auth验证：

auth password

注意：如果服务器使用redis不设置密码，信息可能会收到攻击导致丢失。

在conf中设置密码，将requirepass 这个注释去掉，后面的字段改成对应的密码。
clients客户端

maxclients 10000：设置能连上redis的最大客户端连接数量
memory management 内存管理

maxmemory :redis配置的最大内存容量

maxmemory-policy noeviction：maxmemory-policy 内存达到上限的处理策略

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

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

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

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

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

noeviction：不移除任何key，只是返回一个写错误
append only mode 只追加模式

这部分内容的详细配置说明见redis的持久化

常见的配置介绍

redis默认不是以守护进程的方式进行，可以通过该配置项修改，使用yes启动守护进程。

daemonize no —> daemonize yes

当Redis以守护进程方式运行时，Redis默认会把pid写入/var/run/redis.pid文件，可以通过pidfile指定

pidfile /var/run/redis.pid

指定Redis监听端口，默认端口为6379，作者在自己的一篇博文中解释了为什么选用6379作为默认端口，因为6379在手机按键上MERZ对应的号码，而MERZ取自意大利歌女Alessia Merz的名字

port 6379

绑定的主机地址

bind 127.0.0.1

当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能

timeout 300

指定日志记录级别，Redis总共支持四个级别：debug、verbose、notice、warning，默认为 verbose

loglevel verbose

日志记录方式，默认为标准输出，如果配置Redis为守护进程方式运行，而这里又配置为日志记录方式为标准输出，则日志将会发送给/dev/null

logfile stdout

设置数据库的数量，默认数据库为0，可以使用SELECT 命令在连接上指定数据库id

databases 16

指定在多长时间内，有多少次更新操作，就将数据同步到数据文件，可以多个条件配合

save

Redis默认配置文件中提供了三个条件：

save 900 1

save 300 10

save 60 10000

分别表示900秒（15分钟）内有1个更改，300秒（5分钟）内有10个更改以及60秒内有10000个更改

指定存储至本地数据库时是否压缩数据，默认为yes，Redis采用LZF压缩，如果为了节省CPU时间，可以关闭该选项，但会导致数据库文件变的巨大

rdbcompression yes

指定本地数据库文件名，默认值为dump.rdb

dbfilename dump.rdb

dir ./

设置当本机为slav服务时，设置master服务的IP地址及端口，在Redis启动时，它会自动从master 进行数据同步

slaveof

当master服务设置了密码保护时，slav服务连接master的密码

masterauth

设置Redis连接密码，如果配置了连接密码，客户端在连接Redis时需要通过AUTH 命令提供密码，默认关闭

requirepass foobared

设置同一时间最大客户端连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数，如果设置 maxclients 0，表示不作限制。当客户端连接数到达限制时， Redis会关闭新的连接并向客户端返回max number of clients reached错误信息

maxclients 128

指定Redis最大内存限制，Redis在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis新的vm机制，会把Key存放内存，Value会存放在swap区

maxmemory

指定是否在每次更新操作后进行日志记录，Redis在默认情况下是异步的把数据写入磁盘，如果不开启，可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的，所以有的数据会在一段时间内只存在于内存中。默认为no

appendonly no

指定更新日志文件名，默认为appendonly.aof

appendfilename appendonly.aof

指定更新日志条件，共有3个可选值：

no：表示等操作系统进行数据缓存同步到磁盘（快）

always：表示每次更新操作后手动调用fsync()将数据写到磁盘（慢，安全）

everysec：表示每秒同步一次（折衷，默认值)

appendfsync everysec

指定是否启用虚拟内存机制，默认值为no，简单的介绍一下，VM机制将数据分页存放，由Redis将访问量较少的页即冷数据swap到磁盘上，访问多的页面由磁盘自动换出到内存中

vm-enabled no

虚拟内存文件路径，默认值为/tmp/redis.swap，不可多个Redis实例共享

vm-swap-file /tmp/redis.swap

将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有 value都存在于磁盘。默认值为0

vm-max-memory 0

Redis swap文件分成了很多的page，一个对象可以保存在多个page上面，但一个page上不能被多个对象共享，vm-page-size是要根据存储的数据大小来设定的，作者建议如果存储很多小对象，page 大小最好设置为32或者64bytes；如果存储很大大对象，则可以使用更大的page，如果不确定，就使用默认值

vm-page-size 32

设置swap文件中的page数量，由于页表（一种表示页面空闲或使用的bitmap）是在放在内存中的，，在磁盘上每8个pages将消耗1byte的内存

vm-pages 134217728

设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的，可能会造成比较长时间的延迟。默认值为4

vm-max-threads 4

设置在向客户端应答时，是否把较小的包合并为一个包发送，默认为开启

glueoutputbuf yes

指定在超过一定的数量或者最大的元素超过某一临界值时，采用一种特殊的哈希算法

hash-max-zipmap-entries 64

hash-max-zipmap-value 512

指定是否激活重置哈希，默认为开启

activerehashing yes

指定包含其它的配置文件，可以在同一主机上多个Redis实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

include /path/to/local.conf

16. redis的持久化

为什么要持久化

redis是内存数据库，数据存储在内存中，这样便会存在一个问题：易丢失。当服务器关机或者redis服务器守护进程退出时，内存中的数据就会丢失。
如果redis用作缓存，则数据丢失问题不大，重新从数据源加载进来就行。如果redis用作数据库，则丢失数据会造成很大的危害。
因此为了保存redis中的数据，就要使用持久化技术来将数据持久化保存到硬盘上。
持久化技术有两种：RDB 和 AOF

RDB

什么是RDB

RDB是一种快照存储持久化技术。具体就是将redis数据库指定时刻 的内存数据保存到硬盘的文件中，默认保存的文件名是dump.rdb，而在redis服务器启动时，可以通过加载dump.rdb文件来将内存数据恢复到redis中。

开启RDB持久化的方式(默认开启)

有三种方式，save命令，bigsave命令，服务器配置自动触发。
save命令：

是同步操作。当客户端向服务器发送save命令持久化时，服务器会阻塞save命令后其他客户端的请求，直到数据同步完成。

这便会产生一个问题：如果数据量大，同步时间长，会影响服务器执行其他请求。所以不建议使用这个命令。
```
# 在redis命令行执行save即可完成持久化
127.0.0.1:6379> save
OK
复制代码
```
bgsave:

是异步操作。当客户端向服务器发送bgsave命令时，redis服务器主进程会forks一个子进程来解决数据持久化，主进程仍然可以接收其他请求。在子进程将数据保存到rdb文件之后，子进程便会退出。
```
# 异步保存数据到磁盘
127.0.0.1:6379> bgsave
Background saving started
复制代码
```
服务器配置自动触发：

除了通过客户端发送命令外，还有一种方式，就是在redis.conf配置文件中SNAPSHOTTING下的save来指定触发持久化的条件。

  # 900s内至少达到一条写命令
  save 900 1
  # 300s内至少达至10条写命令
  save 300 10
  # 60s内至少达到10000条写命令
  save 60 10000  
复制代码

修改之后重新加载配置文件。

这种方式与bgsave命令类似，达到触发条件时，会fork一个子进程来进行数据同步。

对redis.conf配置文件中SNAPSHOTTING部分的说明

# rdb的触发条件，满足条件就会执行rdb
# 如果要禁用rdb的持久化，则将下面的save注释或者设置一个空字符串
save 900 1 # 900s内修改一次
save 300 10 # 300s内修改10次
save 60 10000 # 60s内修改10000次

#如果配置为no，表示你不在乎数据不一致或者有其他的手段发现和控制，默认为yes。
stop-writes-on-bgsave-error yes

#对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩，如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能
rdbcompression yes

# 在存储快照后，还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。默认为yes。
rdbchecksum yes

# 文件的名字
dbfilename dump.rdb

# 持久化后文件的位置
dir /www/server/redis/

复制代码

RDB方式的数据恢复

获取备份文件的位置

127.0.0.1:6379> config get dir
1) "dir"
2) "/www/server/redis"
127.0.0.1:6379> 
复制代码

将备份文件移动到redis的/usr/local/bin目录下
启动redis服务即可

RDB的优缺点

优点：

与AOF方式相比，通过rdb文件恢复数据比较快。
rdb文件非常紧凑，适合于数据备份。
通过RDB进行数据备，由于使用子进程生成，所以对Redis服务器性能影响较小。

缺点：

如果服务器宕机的话，采用RDB的方式会造成某个时段内数据的丢失，比如我们设置10分钟同步一次或5分钟达到1000次写入就同步一次，那么如果还没达到触发条件服务器就死机了，那么这个时间段的数据会丢失。
使用save命令会造成服务器阻塞，直接数据同步完成才能接收后续请求。
使用bgsave命令在forks子进程时，如果数据量太大，forks的过程也会发生阻塞，另外，forks子进程会耗费内存。

AOF

什么是AOF

redis每执行一条写操作命令，就将该命令以追加的方式写入到一个日志文件里，然后重启的时候先读取这个文件里的命令，然后执行它。这种保存写操作命令到日志的持久化方式，就叫AOF。
注意只有写操作命令，读操作命令不会进入日志，因为对恢复数据没帮助。

开启AOF的方式(默认关闭)

# redis.conf
############################## APPEND ONLY MODE ###############################
appendonly no # 默认为No,如果要开启持久化改为yes 

appendfilename "appendonly.aof"  # AOF持久化文件的名字
复制代码

当开启后在命令行输入：

127.0.0.1:6379> set name coderchen
OK
复制代码

会发现在/www/server/redis/下面的appendonly.aof文件里多了几行日志：

*3  # 表示当前命令有三个部分，每部分以$+数字开启
$3 # 表示这部分有三个字节
set
$4  # 表示这部分有四个字节
name
$9  # 表示这部分有九个字节
coderchen
复制代码

AOF的数据恢复

正常恢复：

启动：设置Yes，修改默认的appendonly no，改为yes 
将有数据的aof文件复制一份保存到对应目录（config get dir）
恢复：重启redis然后重新加载
复制代码

异常恢复：

 启动：设置Yes 
 故意破坏 appendonly.aof 文件！ 
 修复： redis-check-aof --fix appendonly.aof 进行修复 
 恢复：重启 redis 然后重新加
复制代码

appendonly.aof中配置的说明

############################## APPEND ONLY MODE ###############################
appendonly no # 开启AOF机制

appendfilename "appendonly.aof" #AOF的文件名

# appendfsync always
appendfsync everysec # 写入策略，可以是always,everysec,no。
# appendfsync no

no-appendfsync-on-rewrite no # 默认不重写aof文件

auto-aof-rewrite-percentage 100 # 设置重写的基准值
auto-aof-rewrite-min-size 64mb # 设置重写的基准值

aof-load-truncated yes # 当AOF文件末尾截断时，加载文件还是报错退出。yes:被截断的aof文件被加载，并打印日志通知用户。 no:服务器报错并拒绝启动。

aof-use-rdb-preamble yes #开启混合持久化，更快的AOF重写和启动时数据恢复

dir /www/server/redis/ # aof文件的位置，这里要注意rdb和aof存放的位置一样，所以在APPEND ONLY MODE下面找不到dir,在SANPSHOTTING里
复制代码

三种写入策略

在上面的配置文件中，我们可以通过appendfsync选项指定写入策略，有三个选项。

# appendfsync always
appendfsync everysec # 写入策略，可以是always,everysec,no。
# appendfsync no
复制代码

always:

客户端的每一个写操作都保存到aof文件中，这种策略很安全，但是每个写请求都要io操作，所以很慢。

everysec:

appendfsync的默认写入策略，每秒写入一次aof文件，因此，最多可能会丢失1s数据。

no:

redis服务器不负责写入aof，而是交由操作系统来处理什么时候写入aof文件。更快，但是也最不安全。

三种方式优缺点总结：

AOF重写机制

AOF将客户端的所有写操作都追加到aof文件的末尾，但是如果进行对一个key的不断修改时，往往最后一个修改值才是有效的，但aof文件记录了每一次修改，最后恢复的时候按顺序恢复，这样不仅aof文件变得太大，而且恢复数据时速度变慢。
因此引入了aof重写机制，通过重写aof可以生成恢复当前数据的最少命令集。

开启重写的方法：

no-appendfsync-on-rewrite no # 默认不重写aof文件 改为yes
复制代码

好处：

压缩aof文件，减少磁盘占用量。
将aof的命令压缩为最小命令集，加快了数据恢复的速度。

AOF和RDB的比较

17 redis 发布订阅

是什么

redis发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息。redis客户端可以订阅任意数量的频道。

下图展示了频道channel1，以及订阅这个频道的三个客户端—-client2,client5和client1之间的关系。

当有新消息通过publish命令发送给频道channel1时，这个消息就会被发送给订阅它的三个用户端。

基本命令

这些命令被广泛用于构建即时通信应用，比如网络聊天室和实时广播，实时提醒。

测试

Redis 中提供了一组命令，可以用于发布消息，订阅频道，取消订阅以及按照模式订阅。

窗口1

127.0.0.1:6379> publish redischat "hello,redis"  #在redischat频道发布消息hello,redis
(integer) 0 #0表示当前订阅者为0个，1表示为1个
127.0.0.1:6379> publish redischat "hello,coderchen"
(integer) 1
127.0.0.1:6379> publish redischat "hello,redis"
(integer) 1
127.0.0.1:6379> 

复制代码

窗口2

127.0.0.1:6379> subscribe redischat # 订阅频道redischat,可以接收redischat频道的消息
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "redischat"
3) (integer) 1
1) "message"
2) "redischat"
3) "hello,coderchen"
1) "message"
2) "redischat"
3) "hello,redis"
复制代码

原理

redis是使用c实现的，通过分析redis源码里的pubsub.c文件，了解发布和订阅机制的底层实现，籍此加深对redis的理解。
Redis 通过 PUBLISH 、SUBSCRIBE 和 PSUBSCRIBE 等命令实现发布和订阅功能
通过 SUBSCRIBE 命令订阅某频道后，redis-server 里维护了一个字典，字典的键就是一个个 channel ，而字典的值则是一个链表，链表中保存了所有订阅这个 channel 的客户端。SUBSCRIBE 命令的关键，就是将客户端添加到给定 channel 的订阅链表中。
通过 PUBLISH 命令向订阅者发送消息，redis-server 会使用给定的频道作为键，在它所维护的 channel 字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发布给所有订阅者。
Pub/Sub 从字面上理解就是发布（Publish）与订阅（Subscribe），在Redis中，你可以设定对某一个 key值进行消息发布及消息订阅，当一个key值上进行了消息发布后，所有订阅它的客户端都会收到相应的消息。这一功能最明显的用法就是用作实时消息系统，比如普通的即时聊天，群聊等功能。
使用场景： Pub/Sub构建实时消息系统 Redis的Pub/Sub系统可以构建实时的消息系统比如很多用Pub/Sub构建的实时聊天系统的例子。
一篇很好的文章：Redis 发布订阅，小功能大用处，真没那么废材！ www.cnblogs.com/goodAndyxub…

18 redis主从复制

概念

主从复制是指将一台redis服务器的数据复制到其他的redis服务器。前者称为主节点(master/leader),后者称为从节点(slave/follower)。
数据的复制是单向的，只能由主节点到从节点。master以写为主，slave以读为主。
默认情况下每台redis服务器都是主节点，且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主节点。

主从复制的主要作用包括：

1.数据冗余： 主从复制实现了数据的热备份，是持久化之外的一种数据冗余方式。

2.故障恢复： 当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复，实际上是一种服务的冗余。

3.负载均衡： 在主从复制的基础上，配合读写分离可以由主节点提供写服务，由从节点提供读服务(即写redis数据时应用连接主节点，读redis数据时应用连接从节点)，分担服务器负载。尤其是在写少读多的场景下，通过多个从节分担读负载，可以大大提高redis服务器的并发量。

4.高可用基石： 除了上述作用以外，主从复制还是哨兵和集群能够实现的基础，因此说主从复制是redis高可用的基础。
复制代码

一般来说，要将redis运用于工程项目中，只使用一台redis是万万不能的，原因如下：

1.从结构上：单个redis服务器会发生单点故障，并且一台服务器需要处理所有的请求负载。压力较大。
2.从容量上，单个redis服务器内存容量有限，就算一台redis服务器内存容量为256g，也不能将所有内存用作redis存储内存，一般来说，单台redis最大使用内存不应该超过20G.
复制代码

电商网站上的商品，一般都是一次上传，无数次浏览的，也就是“多读少写”。对于这种场景，可以使用如下架构：

环境配置(伪集群)

这部分参考狂神的pdf，不写了。

19 哨兵模式

概述

主从切换技术的方法是：当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费时费力，还会造成一段时间内服务不可用。这不是一种推荐的方式，更多时候，我们优先考虑哨兵模式。redis从2.8开始正式提供了Sentinel(哨兵)架构来解决这个问题。
它能够自动后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。
哨兵模式是一种特殊的模式，首先redis提供了哨兵的命令，哨兵是一个独立的进程，它会独立运行。其原理是哨兵通过发送命令，等待redis服务器响应，从而监控多个redis实例。

哨兵的作用：

通过发送命令，让redis服务器返回监控其运行状态，包括主服务器和从服务器。
当哨兵检测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让他们切换主机。

多哨兵模式

一个哨兵进程对redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。

假设主服务器宕机，哨兵1会检测到这个结果，系统并不会马上进行failover 过程，仅仅是哨兵 1主观的认为主服务器不可用，这个现象称为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值是，那么哨兵之间会进行一次投票，投票的结果由一个哨兵发起，进行failover(故障转移)操作，切换成功后,会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。

哨兵模式的优缺点：

优点：

哨兵集群模式是基于主从模式的，所有主从的优点，哨兵模式同样具有。
主从可以切换，故障可以转移，系统可用性更好。
哨兵模式是主从模式的升级，系统更加健壮，可用性更高。

缺点：

redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。
实现哨兵模式的配置也不简单，甚至可以说有些繁琐。

哨兵配置说明：

在/www/server/redis下有一个配置文件sentinel.conf。

port 26379 #哨兵sentinel实例运行的端口 默认26379
daemonize no

pidfile /var/run/redis-sentinel.pid

logfile ""

dir /tmp #哨兵模式工作目录

------------------------------------------------------------------
# 哨兵sentinel监控的redis主节点的 ip port
# sentinel monitor <master-name> <ip> <redis-port> <quorum>
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
sentinel monitor mymaster 127.0.0.1 6379 2
----------------------------------------------------------------
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
----------------------------------------------------------------
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000

acllog-max-len 128

# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步这个数字越小，完成failover所需的时间就越长，
#但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
#可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
--------------------------------------------------------------------
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000


sentinel deny-scripts-reconfig yes
SENTINEL resolve-hostnames no
SENTINEL announce-hostnames no
复制代码

20 缓存雪崩，击穿和穿透

我们使用的传统的数据库如mysql，它的数据存储在硬盘上，读写起来速度比较慢，不支持大量的请求访问。而redis是内存数据库，数据在内存上，读写速度是硬盘的好多倍，因此我们引入了redis做缓存，来减少对mysql的直接访问，提高系统性能。
引入缓存后便会有缓存异常的三个问题：缓存雪崩，缓存击穿，缓存穿透。

缓存雪崩

缓存雪崩是指redis中的大量缓存过期或者redis故障，导致大量的用户请求无法在redis中处理，全部请求直接访问数据库，从而导致数据库压力骤增，严重会造成数据库宕机，从而导致一系列连锁反应，造成整个系统崩溃。

大量缓存过期的处理策略：

均匀设置过期时间，避免同一时间过期
互斥锁，保证同一时间只有一个应用在构建缓存。
双Key策略，主key设置过期内容，备key永久，主Key过期时，返回备key的内容。
后台更新缓存，定时更新，消息对列通知更新。

redis故障的处理策略：

服务熔断或者请求限流机制
构建redis缓存高可靠集群

缓存击穿

缓存中频繁被访问的数据称为热点数据。
如果缓存中某个热点数据过期了，这时大量的请求访问该热点数据，就无法从缓存中读取，只能直接访问数据库，数据库很容易就被高并发的请求冲垮。

注意：缓存击穿和缓存雪崩很相似，都是在redis缓存中获取不到数据，进而只能访问数据库。可以认为缓存击穿是缓存雪崩的一个子集。

处理策略：

互斥锁
不给热点数据设置过期时间，由后台更新缓存。

缓存穿透

缓存穿透是指用户请求的数据，既不在缓存中，也不在数据库中。导致请求在访问缓存时，发现缓存缺失，再去访问数据库时，发现数据库也没有要访问的数据，没办法来构建缓存来服务后续的请求。那么有大量这样的请求时，会给数据库造成很大的压力。

处理策略：

非法请求的限制：判断请求是否合理，如果不合理就直接返回错误。
缓存空值或者默认值：针对一些请求在缓存中设置默认值或者空值，使其不在访问数据库。
使用布隆过滤器快速判断数据是否存在，避免通过查询数据库来判断数据是否存在。

布隆过滤器：

简单的说就是在redis或者数据库前设置一道过滤程序，来拦截所有要访问redis或者数据库的请求，先判断请求的数据在redis或者数据库中是否存在，如果存在就放行。这样可以避免对数据库的大量访问。

参考的大佬的文章：

小林coding的 《再也不怕，缓存雪崩、击穿、穿透！》(写的很详细！)

mp.weixin.qq.com/s/_StOUX9Nu…

21. NoSQL概述

为什么要用NoSQL

随着数据量，访问量的增大，传统mysql数据库出现性能问题，这时引入缓存技术来缓解数据库的压力，优化数据库结构和索引。但随着数据量访问量进一步增大，mysql主从读写分离，mysql集群等都无法满足要求。mysql数据库扩展性达到瓶颈。
这时传统的关系型数据库难以应付高并发，暴露出很多问题，而非关系型数据库是为了解决当前高并发问题和大规模数据等问题而诞生的。因此非关系型数据库非常适用当前的环境。

什么是NoSQL

NoSQL

NoSQL=Not Only SQL 意思是不仅仅是SQL

NoSQL的特点

易扩展
大数据量高性能

有非常高的读写性能。特别是在大数据量下。
复制代码

多样灵活的数据模型

NoSQL无需事先为要存储的数据建立字段，随时可以存储自定义的数据格式。而在关系数据库里，增删字段是一件非常麻烦的事。
复制代码

传统的RDBMS和NoSQL的比较

传统的关系型数据库 RDBMS
- 高度组织化结构化数据
- 结构化查询语言（SQL）
- 数据和关系都存储在单独的表中
- 数据操纵语言，数据定义语言
- 严格的一致性
- 基础事务
NoSQL
- 代表着不仅仅是SQL
- 没有声明性查询语言
- 没有预定义的模式
- 键值对存储，列存储，文档存储，图形数据库
- 最终一致性，而非ACID属性
- 非结构化和不可预知的数据
- CAP定理
- 高性能，高可用性 和 可伸缩性
复制代码

NoSQL的四大分类

kv键值型数据库：redis，memcache
文档型数据库：MongoDB,CouchDB
列存储数据库： Hbase，Cassandra,分布式文件系统
图关系型数据库：Neo4J,InfoGrid

四者对比：

CAP+BASE

传统的关系型数据库遵循ACID原则。A:原子性 C:一致性 I:隔离性 D:持久性
分布式存储系统中遵循CAP理论。但只能是实现CAP三个理论中的两个。

CAP理论：
	C:consisiency 强一致性
	A:availability 可用性
	P:partition tolerance 分区容错性
其中由于当前网络硬件下肯定会出现延迟丢包，所以分区容错性必须实现。
所以只能在一致性和可用性之间权衡，没有NOSQL可以同时保证这三点。
复制代码

CAP理论的核心是一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三大类：

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。
CP - 满足一致性，分区容忍必的系统，通常性能不是特别高。
AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。
复制代码

BASE理论

BASE理论是对CAP中一致性和可用性权衡的结果。其核心思想是即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性

BASE理论：

基本可用(Basically Available)： 基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

软状态(Soft State)： 软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。MySQL Replication 的异步复制也是一种体现。

最终一致性(Eventual Consistency)： 最终一致性是指系统中的所有数据副本经过一定时间后，最
终能够达到一致的状态。弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。

复制代码