直接翻译就完事了
意思就是可以包含多个配置文件
为了增加一些功能，你可以在这引入一些模块
绑定redis服务器网卡IP，默认为127.0.0.1,即本地回环地址。这样的话，访问redis服务只能通过本机的客户端连接，而无法通过远程连接。如果bind选项为空的话，那会接受所有来自于可用网络接口的连接。
指定redis运行的端口，默认是6379。由于Redis是单线程模型，因此单机开多个Redis进程的时候会修改端口。
设置客户端连接时的超时时间，单位为秒。当客户端在这段时间内没有发出任何指令，那么关闭该连接。默认值为0，表示不关闭。
单位是秒，表示将周期性的使用SO_KEEPALIVE检测客户端是否还处于健康状态，避免服务器一直阻塞，官方给出的建议值是300s，如果设置为0，则不会周期性的检测。
设置为yes表示指定Redis以守护进程的方式启动（后台启动）。默认值为 no
配置PID文件路径，当redis作为守护进程运行的时候，它会把 pid 默认写到 /var/redis/run/redis_6379.pid 文件里面
定义日志级别。默认值为notice，有如下4种取值：debug（记录大量日志信息，适用于开发、测试阶段）verbose（较多日志信息）notice（适量日志信息，使用于生产环境）warning（仅有部分重要、关键信息才会被记录）
配置log文件地址,默认打印在命令行终端的窗口上
设置数据库的数目。默认的数据库是DB 0 ，可以在每个连接上使用select 命令选择一个不同的数据库，dbid是一个介于0到databases - 1 之间的数值。默认值是 16，也就是说默认Redis有16个数据库。
这里是用来配置触发 Redis的持久化条件，也就是什么时候将内存中的数据保存到硬盘
save 900 1：表示900 秒内如果至少有 1 个 key 的值变化，则保存
save 300 10：表示300 秒内如果至少有 10 个 key 的值变化，则保存
save 60 10000：表示60 秒内如果至少有 10000 个 key 的值变化，则保存
当然如果你只是用Redis的缓存功能，不需要持久化，那么你可以注释掉所有的 save 行来停用保存功能。可以直接一个空字符串来实现停用：save “”
默认值为yes。当启用了RDB且最后一次后台保存数据失败，Redis是否停止接收数据。这会让用户意识到数据没有正确持久化到磁盘上，否则没有人会注意到灾难（disaster）发生了。如果Redis重启了，那么又可以重新开始接收数据了
默认值是yes。对于存储到磁盘中的快照，可以设置是否进行压缩存储。如果是的话，redis会采用LZF算法进行压缩。如果你不想消耗CPU来进行压缩的话，可以设置为关闭此功能，但是存储在磁盘上的快照会比较大。
默认值是yes。在存储快照后，我们还可以让redis使用CRC64算法来进行数据校验，但是这样做会增加大约10%的性能消耗，如果希望获取到最大的性能提升，可以关闭此功能。
设置快照的文件名，默认是 dump.rdb
设置快照文件的存放路径，这个配置项一定是个目录，而不能是文件名。使用上面的 dbfilename 作为保存的文件名
默认值为yes。当一个 slave 与 master 失去联系，或者复制正在进行的时候，slave 可能会有两种表现：
1) 如果为 yes ，slave 仍然会应答客户端请求，但返回的数据可能是过时，或者数据可能是空的在第一次同步的时候
2) 如果为 no ，在你执行除了 info he salveof 之外的其他命令时，slave 都将返回一个 “SYNC with master in progress” 的错误
slave-read-only：配置Redis的Slave实例是否接受写操作，即Slave是否为只读Redis。默认值为yes。
repl-diskless-sync：主从数据复制是否使用无硬盘复制功能。默认值为no。
当启用无硬盘备份，服务器等待一段时间后才会通过套接字向从站传送RDB文件，这个等待时间是可配置的。 这一点很重要，因为一旦传送开始，就不可能再为一个新到达的从站服务。从站则要排队等待下一次RDB传送。因此服务器等待一段 时间以期更多的从站到达。延迟时间以秒为单位，默认为5秒。要关掉这一功能，只需将它设置为0秒，传送会立即启动。默认值为5。
同步之后是否禁用从站上的TCP_NODELAY 如果你选择yes，redis会使用较少量的TCP包和带宽向从站发送数据。但这会导致在从站增加一点数据的延时。 Linux内核默认配置情况下最多40毫秒的延时。如果选择no，从站的数据延时不会那么多，但备份需要的带宽相对较多。默认情况下我们将潜在因素优化，但在高负载情况下或者在主从站都跳的情况下，把它切换为yes是个好主意。默认值为no。
rename-command：命令重命名，对于一些危险命令例如：
flushdb（清空数据库）
flushall（清空所有记录）
config（客户端连接后可配置服务器）
keys（客户端连接后可查看所有存在的键）
作为服务端redis-server，常常需要禁用以上命令来使得服务器更加安全，禁用的具体做法是：
也可以保留命令但是不能轻易使用，重命名这个命令即可：
这样，重启服务器后则需要使用新命令来执行操作，否则服务器会报错unknown command。
设置redis连接密码
设置客户端最大并发连接数，默认无限制，Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件。 描述符数-32（redis server自身会使用一些），如果设置 maxclients为0 。表示不作限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
设置Redis的最大内存，如果设置为0 。表示不作限制。通常是配合下面介绍的maxmemory-policy参数一起使用。
当内存使用达到maxmemory设置的最大值时，redis使用的内存清除策略。有以下几种可以选择：
1）volatile-lru 利用LRU算法移除设置过过期时间的key (LRU:最近使用 Least Recently Used )
2）allkeys-lru 利用LRU算法移除任何key
3）volatile-random 移除设置过过期时间的随机key
4）allkeys-random 移除随机ke
5）volatile-ttl 移除即将过期的key(minor TTL)
6）noeviction noeviction 不移除任何key，只是返回一个写错误 ，默认选项
LRU 和 minimal TTL 算法都不是精准的算法，但是相对精确的算法(为了节省内存)。随意你可以选择样本大小进行检，redis默认选择3个样本进行检测，你可以通过maxmemory-samples进行设置样本数。
默认redis使用的是rdb方式持久化，这种方式在许多应用中已经足够用了。但是redis如果中途宕机，会导致可能有几分钟的数据丢失，根据save来策略进行持久化，Append Only File是另一种持久化方式， 可以提供更好的持久化特性。Redis会把每次写入的数据在接收后都写入appendonly.aof文件，每次启动时Redis都会先把这个文件的数据读入内存里，先忽略RDB文件。默认值为no。
aof文件名，默认是"appendonly.aof"
aof持久化策略的配置；no表示不执行fsync，由操作系统保证数据同步到磁盘，速度最快；always表示每次写入都执行fsync，以保证数据同步到磁盘；everysec表示每秒执行一次fsync，可能会导致丢失这1s数据
在aof重写或者写入rdb文件的时候，会执行大量IO，此时对于everysec和always的aof模式来说，执行fsync会造成阻塞过长时间，no-appendfsync-on-rewrite字段设置为默认设置为no。如果对延迟要求很高的应用，这个字段可以设置为yes，否则还是设置为no，这样对持久化特性来说这是更安全的选择。 设置为yes表示rewrite期间对新写操作不fsync,暂时存在内存中,等rewrite完成后再写入，默认为no，建议yes。Linux的默认fsync策略是30秒。可能丢失30秒数据。默认值为no。
auto-aof-rewrite-percentage：默认值为100。aof自动重写配置，当目前aof文件大小超过上一次重写的aof文件大小的百分之多少进行重写，即当aof文件增长到一定大小的时候，Redis能够调用bgrewriteaof对日志文件进行重写。当前AOF文件大小是上次日志重写得到AOF文件大小的二倍（设置为100）时，自动启动新的日志重写过程。
auto-aof-rewrite-min-size：64mb。设置允许重写的最小aof文件大小，避免了达到约定百分比但尺寸仍然很小的情况还要重写。
aof文件可能在尾部是不完整的，当redis启动的时候，aof文件的数据被载入内存。重启可能发生在redis所在的主机操作系统宕机后，尤其在ext4文件系统没有加上data=ordered选项，出现这种现象 redis宕机或者异常终止不会造成尾部不完整现象，可以选择让redis退出，或者导入尽可能多的数据。如果选择的是yes，当截断的aof文件被导入的时候，会自动发布一个log给客户端然后load。如果是no，用户必须手动redis-check-aof修复AOF文件才可以。默认值为 yes。
个lua脚本执行的最大时间，单位为ms。默认值为5000.
集群开关，默认是不开启集群模式。
集群配置文件的名称，每个节点都有一个集群相关的配置文件，持久化保存集群的信息。 这个文件并不需要手动配置，这个配置文件有Redis生成并更新，每个Redis集群节点需要一个单独的配置文件。请确保与实例运行的系统中配置文件名称不冲突。默认配置为nodes-6379.conf。
可以配置值为15000。节点互连超时的阀值，集群节点超时毫秒数
可以配置值为10。在进行故障转移的时候，全部slave都会请求申请为master，但是有些slave可能与master断开连接一段时间了， 导致数据过于陈旧，这样的slave不应该被提升为master。该参数就是用来判断slave节点与master断线的时间是否过长。判断方法是：比较slave断开连接的时间和(node-timeout * slave-validity-factor) + repl-ping-slave-period 如果节点超时时间为三十秒, 并且slave-validity-factor为10,假设默认的repl-ping-slave-period是10秒，即如果超过310秒slave将不会尝试进行故障转移
以配置值为1。master的slave数量大于该值，slave才能迁移到其他孤立master上，如这个参数若被设为2，那么只有当一个主节点拥有2 个可工作的从节点时，它的一个从节点会尝试迁移。
默认情况下，集群全部的slot有节点负责，集群状态才为ok，才能提供服务。 设置为no，可以在slot没有全部分配的时候提供服务。不建议打开该配置，这样会造成分区的时候，小分区的master一直在接受写请求，而造成很长时间数据不一致。
具体问题具体对待，不要求全部记得，你环境弄多了你就熟了，但是你要知道有这方面的事
之前说了，我们的redis是内存数据库，但是不能一断电我的东西就丢了，所以即使是内存数据库也要有持久化的操作的！
在redis中持久化操作一般涉及到两个方面，一个是rdb还有一个是aof，所以人家问到你redis的持久化操作，上来就是aof和rdb
在指定的时间内，将内存中的数据集体写入磁盘当中，他恢复的时候将文件直接读取到内存当中，redis会单独的创建一个子进程来进行持久化，会先将一个数据写入到一个临时的文件中，带持久化结束了，在用这个临时文件替换上次持久化号的文件。整个过程中，主进程是不进行任何io操作的，这就确保了极高的性能，如果需要进行大规模的数据恢复，并且对于数据的完整性十分你的敏感的话，那么rdb方式要比aof方式更加的高效，rdb的缺点就是最后一次持久化的数据可能丢失。默认就是rdb的，我们不用修改相关配置。
一般保存的文件就是dump.rdb
这个设置就是在配置文件里的SNAPSHOTTING大项里面
就是把所有的操作命令全部都记下来，你想要恢复就是把所有的命令都执行一遍，以日志的形式来记录所有的操作，但是读的操作除外，只需追加文件不许修改文件，redis启动之初会读取改文件重新构建数据。
一般保存的文件是appendonly.aof
这个设置就是在配置文件里的APPEND ONLY MODE大项里面
默认不开启的。所以你要手动开启 就是 appendonly yes
如果文件出了问题
redis-check-aof --fix appendonly.aof
一般不会出错，出错基本也是认为的！有内鬼
| rdb | aof | |
|---|---|---|
| 优点 | 1). 一旦采用该方式，那么你的整个Redis数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，你可能打算每个小时归档一次最近24小时的数据，同时还要每天归档一次最近30天的数据。通过这样的备份策略，一旦系统出现灾难性故障，我们可以非常容易的进行恢复。2). 对于灾难恢复而言，RDB是非常不错的选择。因为我们可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。3). 性能最大化。对于Redis的服务进程而言，在开始持久化时，它唯一需要做的只是fork出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行IO操作了。4). 相比于AOF机制，如果数据集很大，RDB的启动效率会更高。 | 1). 该机制可以带来更高的数据安全性，即数据持久性。Redis中提供了3中同步策略，即每秒同步、每修改同步和不同步。事实上，每秒同步也是异步完成的，其效率也是非常高的，所差的是一旦系统出现宕机现象，那么这一秒钟之内修改的数据将会丢失。而每修改同步，我们可以将其视为同步持久化，即每次发生的数据变化都会被立即记录到磁盘中。可以预见，这种方式在效率上是最低的。至于无同步，无需多言，我想大家都能正确的理解它。2). 由于该机制对日志文件的写入操作采用的是append模式，因此在写入过程中即使出现宕机现象，也不会破坏日志文件中已经存在的内容。然而如果我们本次操作只是写入了一半数据就出现了系统崩溃问题，不用担心，在Redis下一次启动之前，我们可以通过redis-check-aof工具来帮助我们解决数据一致性的问题。3). 如果日志过大，Redis可以自动启用rewrite机制。即Redis以append模式不断的将修改数据写入到老的磁盘文件中，同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。4). AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上，我们也可以通过该文件完成数据的重建。 |
| 缺点 | 1). 如果你想保证数据的高可用性，即最大限度的避免数据丢失，那么RDB将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象，此前没有来得及写入磁盘的数据都将丢失。2). 由于RDB是通过fork子进程来协助完成数据持久化工作的，因此，如果当数据集较大时，可能会导致整个服务器停止服务几百毫秒，甚至是1秒钟。 | 1). 对于相同数量的数据集而言，AOF文件通常要大于RDB文件。RDB 在恢复大数据集时的速度比 AOF 的恢复速度要快。2). 根据同步策略的不同，AOF在运行效率上往往会慢于RDB。总之，每秒同步策略的效率是比较高的，同步禁用策略的效率和RDB一样高效。 |
二者选择的标准，就是看系统是愿意牺牲一些性能，换取更高的缓存一致性（aof），还是愿意写操作频繁的时候，不启用备份来换取更高的性能.
你开了aof。redis就从aof恢复数据，不开就从rdb恢复数据
集群概念
将一台redis服务器的数据，复制到其他的redis服务器，前者称为主节点（master），后者称之为从节点（slave），数据的复制是单向的，也就是说只有从节点复制主节点的东西，主节点从不复制其他节点的东西，主节点是负责写入，从节点负责读取（读写分离）
默认的情况下，每个redis服务都是主节点，除非你配置了
进入客户端后运行info replication命令 你能看到role是master
复制多个配置文件
cp redis.conf redis-6380.conf
cp redis.conf redis-6381.conf
编辑配置文件
主配置文件 daemonize yes
logfile “master.log”
dbfilename masterdump.rdb
从文件配置
port 6380
pidfile 最后改成6380.pid
logfile “6380.log”
dbfilename 6380dump.rdb
进入客户端 输入命令
slaveof 127.0.0.1 6379
info replication //观察信息
或者在配置文件配置
REPLICATION项中 replicaof 127.0.0.1 6379 有密码的话就在下面有个masterauth xxx
认完之后只有主机可以写，从机数不能写的，主机写的东西，从机是可以读的，从现在开始主机如果断了，剩下来的两个从机还是从机，后续主机又回来了，主机还是主机。但是如果从机断开了，就看他是不是配置文件设置的从机，如果是那么他就能继续是从机，如果不是那么他又是主机了，这个时候你就要继续认主了（这个其实是废话，但是因为概念有点绕，所以还是要跟初学者讲一下）这个时候要注意的是之前主节点写的数据还能不能读到呢？这里面就涉及到两个新的概念。就是全量复制和增量复制。
认主之后，从节点会发送一个同步命令，主节点接收到同步的命令之后，启动后台的存盘进程，同时收集所有的接收到的变动命令，在后台进程执行完毕之后，主节点将传送整个文件到从节点，并完成一次同步
全量复制：从节点服务在接受到数据库文件数据的时候，将其存盘并加载到内存当中
增量复制：master继续将所有收集到的变动命令一次传递给从节点，完成同步
只要重新连接master，就会全量复制。
服务器自己变成主机
slaveof no one
多讲一句：主从复制这种模式呢。针对于故障转移这一点，都是靠人肉运维
1. 连接建立阶段
该阶段的主要作用是在主从节点之间建立连接，为数据同步做好准备。
步骤1：保存主节点信息
从节点服务器内部维护了两个字段，即masterhost和masterport字段，用于存储主节点的ip和port信息。
需要注意的是，slaveof是异步命令，从节点完成主节点ip和port的保存后，向发送slaveof命令的客户端直接返回OK，实际的复制操作在这之后才开始进行。
这个过程中，可以看到从节点打印日志如下：
步骤2：建立socket连接
从节点每秒1次调用复制定时函数replicationCron()，如果发现了有主节点可以连接，便会根据主节点的ip和port，创建socket连接。如果连接成功，则：
从节点：为该socket建立一个专门处理复制工作的文件事件处理器，负责后续的复制工作，如接收RDB文件、接收命令传播等。
主节点：接收到从节点的socket连接后（即accept之后），为该socket创建相应的客户端状态，并将从节点看做是连接到主节点的一个客户端，后面的步骤会以从节点向主节点发送命令请求的形式来进行。
这个过程中，从节点打印日志如下：
步骤3：发送ping命令
从节点成为主节点的客户端之后，发送ping命令进行首次请求，目的是：检查socket连接是否可用，以及主节点当前是否能够处理请求。
从节点发送ping命令后，可能出现3种情况：
（1）返回pong：说明socket连接正常，且主节点当前可以处理请求，复制过程继续。
（2）超时：一定时间后从节点仍未收到主节点的回复，说明socket连接不可用，则从节点断开socket连接，并重连。
（3）返回pong以外的结果：如果主节点返回其他结果，如正在处理超时运行的脚本，说明主节点当前无法处理命令，则从节点断开socket连接，并重连。
在主节点返回pong情况下，从节点打印日志如下：
步骤4：身份验证
如果从节点中设置了masterauth选项，则从节点需要向主节点进行身份验证；没有设置该选项，则不需要验证。从节点进行身份验证是通过向主节点发送auth命令进行的，auth命令的参数即为配置文件中的masterauth的值。
如果主节点设置密码的状态，与从节点masterauth的状态一致（一致是指都存在，且密码相同，或者都不存在），则身份验证通过，复制过程继续；如果不一致，则从节点断开socket连接，并重连。
步骤5：发送从节点端口信息
身份验证之后，从节点会向主节点发送其监听的端口号（前述例子中为6380），主节点将该信息保存到该从节点对应的客户端的slave_listening_port字段中；该端口信息除了在主节点中执行info Replication时显示以外，没有其他作用。
2. 数据同步阶段
主从节点之间的连接建立以后，便可以开始进行数据同步，该阶段可以理解为从节点数据的初始化。具体执行的方式是：从节点向主节点发送psync命令（Redis2.8以前是sync命令），开始同步。
数据同步阶段是主从复制最核心的阶段，根据主从节点当前状态的不同，可以分为全量复制和部分复制，下面会有一章专门讲解这两种复制方式以及psync命令的执行过程，这里不再详述。
需要注意的是，在数据同步阶段之前，从节点是主节点的客户端，主节点不是从节点的客户端；而到了这一阶段及以后，主从节点互为客户端。原因在于：在此之前，主节点只需要响应从节点的请求即可，不需要主动发请求，而在数据同步阶段和后面的命令传播阶段，主节点需要主动向从节点发送请求（如推送缓冲区中的写命令），才能完成复制。
3. 命令传播阶段
数据同步阶段完成后，主从节点进入命令传播阶段；在这个阶段主节点将自己执行的写命令发送给从节点，从节点接收命令并执行，从而保证主从节点数据的一致性。
在命令传播阶段，除了发送写命令，主从节点还维持着心跳机制：PING和REPLCONF ACK。由于心跳机制的原理涉及部分复制，因此将在介绍了部分复制的相关内容后单独介绍该心跳机制。
延迟与不一致
需要注意的是，命令传播是异步的过程，即主节点发送写命令后并不会等待从节点的回复；因此实际上主从节点之间很难保持实时的一致性，延迟在所难免。数据不一致的程度，与主从节点之间的网络状况、主节点写命令的执行频率、以及主节点中的repl-disable-tcp-nodelay配置等有关。
repl-disable-tcp-nodelay no：该配置作用于命令传播阶段，控制主节点是否禁止与从节点的TCP_NODELAY；默认no，即不禁止TCP_NODELAY。当设置为yes时，TCP会对包进行合并从而减少带宽，但是发送的频率会降低，从节点数据延迟增加，一致性变差；具体发送频率与Linux内核的配置有关，默认配置为40ms。当设置为no时，TCP会立马将主节点的数据发送给从节点，带宽增加但延迟变小。
一般来说，只有当应用对Redis数据不一致的容忍度较高，且主从节点之间网络状况不好时，才会设置为yes；多数情况使用默认值no。
之前我们将的主从复制中，主节点断掉之后有问题，因为从节点此时还是从节点，也就意味当前只能读取不能写入了，也就是说，一旦主节点完蛋，那么我的功能就部分实现不了了，那么哨兵模式就解决了这个问题
哨兵没出来之前了，如果主节点断了，从节点可以输入命令slaveof no one让自己变成主机，然后给其他人认主，但是这种方式始终很笨重，类似于人肉运维，就太不智能了，所以后看来就来了哨兵模式（sentinel）。哨兵模式就是相当于开一个进程自动监控redis服务，并且发生问题的时候，自动认主
哨兵是一个独立的进程，通过发送命令，等待redis服务器响应，从而监控运行多个redis实例。但是又是有问题如果哨兵挂了，就不行了，所以我们哨兵也要有集群配置，让哨兵也互相监控。那么由此可能最小的reids集群配置起码要六台服务器三个哨兵三个redis。
假设主redis挂了，哨兵1先检测到这个结果，但是系统不会马上进行认主的，因为我们的系统认为只是这个哨兵主观认为这个服务器不能用，这个叫做主观下线，当后面的哨兵也检测到主的不能用，并且哨兵数量达到一定值的时候，哨兵之间就会进行一次内部投票，然后通过类似于发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程叫做客观下线（原来主机的客观下线）
1.哨兵配置文件
port 26380
protected-mode no
daemonize yes
pidfile "/var/run/redis-sentinel_26380.pid"
logfile "/var/log/redis/sentinel_26380.log"
dir "/tmp"
#避免脚本重置，默认值yes
sentinel deny-scripts-reconfig yes
#告诉sentinel去监听地址为ip:port的一个master，这里的master-name可以自定义，quorum是一个数字，指明当有多少个sentinel认为一个master失效时，master才算真正失效 ，要加外网地址
sentinel monitor mymaster 6379 1
#这个配置项指定了需要多少失效时间，一个master才会被这个sentinel主观地认为是不可用的。 单位是毫秒，默认为30秒
sentinel down-after-milliseconds mymaster 30000
#指定了在发生failover主备切换时最多可以有多少个slave同时对新的 master进行 同步.这个数字越小，完成failover所需的时间就越长，但是如果这个数字越大，就意味着越 多的slave因为replication而不可用.可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
sentinel parallel-syncs mymaster 1
#当进行failover故障转移时，配置所有slaves指向新的master所需的最大时间
sentinel failover-timeout mymaster 180000
#master-name的验证密码
sentinel auth-pass mymaster 123456
2.输入命令
redis-sentinel xxx/sentinel.conf
3.把主机断开等一会你会发现从机会自动变成主机
投票算法raft 你问到了这个，基本上也没得问了、
java代码演示
public static void testSentinel() throws Exception {
String masterName = "mymaster";
Set sentinels = new HashSet<>();
sentinels.add("192.168.92.128:26379");
sentinels.add("192.168.92.128:26380");
sentinels.add("192.168.92.128:26381");
JedisSentinelPool pool = new JedisSentinelPool(masterName, sentinels); //初始化过程做了很多工作
Jedis jedis = pool.getResource();
jedis.set("key1", "value1");
pool.close();
}
加依赖
org.apache.commons
commons-pool2
配置文件
spring:
redis:
pool:
# 连接池最大连接数(使用负值表示没有限制) 默认为8
max-active: 8
# 连接池中的最大空闲连接 默认为8
max-idle: 8
# 连接池最大阻塞等待时间(使用负值表示没有限制) 默认为-1
max-wait: -1ms
# 连接池中的最小空闲连接 默认为 0
min-idle: 0
sentinel:
# 主节点的别名
master: mymaster
# sentinel服务的ip和端口
nodes: 110.40.154.233:26379
server:
port: 8081
// Reconnected to 110.40.154.233:6381你能看到springboot日志打出来这种日志你就成功了，但是请你注意在你搭建主从复制的时候一定要info replication看一下主从的关系，确定好再去开哨兵
其他都一样
（1）定时任务：每个哨兵节点维护了3个定时任务。定时任务的功能分别如下：通过向主从节点发送info命令获取最新的主从结构；通过发布订阅功能获取其他哨兵节点的信息；通过向其他节点发送ping命令进行心跳检测，判断是否下线。
（2）主观下线：在心跳检测的定时任务中，如果其他节点超过一定时间没有回复，哨兵节点就会将其进行主观下线。顾名思义，主观下线的意思是一个哨兵节点“主观地”判断下线；与主观下线相对应的是客观下线。
（3）客观下线：哨兵节点在对主节点进行主观下线后，会通过sentinel is-master-down-by-addr命令询问其他哨兵节点该主节点的状态；如果判断主节点下线的哨兵数量达到一定数值，则对该主节点进行客观下线。
需要特别注意的是，客观下线是主节点才有的概念；如果从节点和哨兵节点发生故障，被哨兵主观下线后，不会再有后续的客观下线和故障转移操作。
（4）选举领导者哨兵节点：当主节点被判断客观下线以后，各个哨兵节点会进行协商，选举出一个领导者哨兵节点，并由该领导者节点对其进行故障转移操作。
监视该主节点的所有哨兵都有可能被选为领导者，选举使用的算法是Raft算法；Raft算法的基本思路是先到先得：即在一轮选举中，哨兵A向B发送成为领导者的申请，如果B没有同意过其他哨兵，则会同意A成为领导者。选举的具体过程这里不做详细描述，一般来说，哨兵选择的过程很快，谁先完成客观下线，一般就能成为领导者。
（5）故障转移：选举出的领导者哨兵，开始进行故障转移操作，该操作大体可以分为3个步骤：
在从节点中选择新的主节点：选择的原则是，首先过滤掉不健康的从节点；然后选择优先级最高的从节点(由slave-priority指定)；如果优先级无法区分，则选择复制偏移量最大的从节点；如果仍无法区分，则选择runid最小的从节点。
更新主从状态：通过slaveof no one命令，让选出来的从节点成为主节点；并通过slaveof命令让其他节点成为其从节点。
将已经下线的主节点(即6379)设置为新的主节点的从节点，当6379重新上线后，它会成为新的主节点的从节点。
概念
访问一个不存在的key，缓存不起作用，请求会穿透到DB，流量大时DB会挂掉。
解决方案
采用布隆过滤器，使用一个足够大的bitmap，用于存储可能访问的key，不存在的key直接被过滤；
访问key未在DB查询到值，也将空值写进缓存，但可以设置较短过期时间。
概念
一个存在的key，在缓存过期的一刻，同时有大量的请求，这些请求都会击穿到DB，造成瞬时DB请求量大、压力骤增。
解决方案
在访问key之前，采用SETNX（set if not exists）来设置另一个短期key来锁住当前key的访问，访问结束再删除该短期key。
概念
大量的key设置了相同的过期时间，导致在缓存在同一时刻全部失效，造成瞬时DB请求量大、压力骤增，引起雪崩。
解决方案
可以给缓存设置过期时间时加上一个随机值时间，使得每个key的过期时间分布开来，不会集中在同一时刻失效。