本文共 8606 字，大约阅读时间需要 28 分钟。

redis的基础配置，

redis的两种持久化机制SNAPSHOTTING，APPEND ONLY FILE

**redis的主从复制，类似其他存储一样，单台存储的能力和IO能力时有限的，之所以KV存储，只要是考虑到非常高的TPS,的能力，即便如此，当系统过于庞大时，redis的节点所能够提高的承载能力，依然时比较有限的，于是redis主机也需要做扩展，扩展方式无非跟mysql存储逻辑时一样的，所有存储的扩展方式都很相似，

要么是在节点级别加以扩展，（一般就是做主从） 要么就是在数据块级别进行扩展，把数据切割成更小的单元进行扩展，基于横向逻辑来实现（可以实现集群，或者分布式的逻辑，，其实多个节点做主从也算是做分布式，然后主节点能写能读，从节点是只读的，如果要基于块级别做分布式，好处在于，每一个节点上都有主块，也都可能存在副本块，因此每一个节点都有可能要承载一部分写操作，所以使得我们的写操作压力也是分散至或者分发至多个节点的，读操作一样也可以分发至多个节点） 所以redis在此方面就提供了两种支持两种方式的解决方案 ** 主从复制的工作逻辑，所不同的是，redis是没有二进制日志的，那么是如何实现复制的，

redis有两种持久化机制

SNAPSHOTTING,

AOF：效率并不是特别的高，因此它的复制逻辑可以想象成为，是在主节点上，刚开始复制时，即便你的redis服务器跑了很久，也一样不需要再上面进行备份到各从节点上进行恢复，而从0 开始复制的

更重要的是，对redis主节点来讲，会基于内存生成一个快照，把这个快照通过网络发送给从节点，有从节点拿到这个快照后，

在本地恢复到内存中，就可以得到与主节点一模一样的数据了，随后主节点在快照之后发生的修改，再按照AOF的机制不停的将操作发给从节点，让从节点在本地进行重放，从而完成复制的功能，这是基于快照来实现的

但是基于快照来实现，就有两个不同的逻辑，如果我们有多个从节点，每一个从节点在主节点都要快照一次，发给它，如果网络IO很慢的话，这个方式不是很理想

对于redis而言，还支持另外一种快照同步方式，主节点首先将数据快照以后将快照存储在磁盘上，然后基于磁盘慢慢发送，而不基于内存中慢慢发送，所以一个文件可以同时发送第一个节点，也可以第二个节点，类似于此种方式，来实现这种功能。

这是redis主从复制的第一种

但是redis主从复制和mysql面临同样的局面，主节点读写都可以，但从节点只读，所以就存在，主节点宕机以后写操作服务不可用，所以需要提升一个从节点为新的主节点，提升工作完成的机制，需要一个第三方服务，这个服务依然是由redis自行提供，它需要自己工作一个服务（守护进程）监听在某个套接字或端口上，这个服务称为Sentry哨兵

在这样的结构中，虽然主节点的可用性得到提升，但解决不了写操作负载分散的问题， redis3.0之后才正式可用的解决方案，叫redis cluster

可以将多各redis节点，构建成一个集群，这个集群还是无中心节点的集群，任何一个节点都存有整个集群的源数据，并知道哪个数据块在哪个节点上存放，所以客户端可以随意找一个节点，但是一个节点宕机了，客户端得自行通过某种逻辑来知道在其他哪些节点上还依然可用

这个时候就要求客户端本身支持redis-cluste能完成服务发现的功能

这里不借助ZK或者ETCD来实现，而redis协议自身和它的客户端，就拥有服务发现的功能，当然只用于发现redis-cluster的 节点的，但是对客户端来讲，毕竟要求一个smart-client（智能客户端），要求自己能发现服务的工作逻辑，所以这种应用使得它的限制，还是有一定 的局限性的

3.0时代的redis还不是特别的稳定，发展到现在它的cluster已经足够稳定了，把整个redis要存储的数据，有多少片数据用一个固定大小的数值来定义

比如允许整个redis集群存在10000个分片，于是在各个节点之上，给平均设定指定数量的槽位slot，一个插槽就能放一个分片，所以事先分配好slot，并设定一共有10000个slot，其中第一个节点承载从1到2500的槽位，第二个节点承载2501到5000，当我们需要去存储一个数据的时候

（我们的槽式从0-9999），可用把一个要存储数据的key对10000取模，得到的结果是0-9999其中的一个数字，得到的是哪个数字就存如哪个槽，这个槽在哪个节点，就在哪个节点上存，

所以用户访问任何一个key的时候，任何一个节点都能帮你计算存在哪个槽，于是可用让客户端找到这个主机，访问数据

对每个槽上的数据可能都要存副本，确保冗余功能

**

**

这里的槽非常类似于一致性哈希中的虚拟节点，这个数量足够多的是，一旦一个节点发生变化，影响的槽式有限的，影响的范围是有限的，但这个范围其实还有个问题，其实是一个连续的空间，因此一个节点宕了，会影响后面的节点

比如第二个节点宕了，

影响的是从2500到4999的槽位，但好坏的是key本身并不连续 先说第一种解决方案

主从复制该如何配置 redis也是一主多从，支持列式复制，多级复制，主节点以非阻塞方式同步至slave主机，配置指令很简单

slaveof

复制：

特点：

一个Master可以有多个slave主机，支持链式复制；

Master以非阻塞方式同步数据至slave主机；

配置slave节点：

redis-cli> SLAVEOF <MASTER_IP> <MASTER_PORT> 指明谁是主的 ip端口是什么 如果主节点做了认证功能，还需要额外 config set设定masterauth 认证密码，就是主节点的密码是什么 redis-cli> CONFIG SET masterauth

**配置参数：

*slaveof *masterauth **

slave-serve-stale-data yes		slave-read-only yes		*repl-diskless-sync no			no, Disk-backed, Diskless

为了演示效果，先把节点1当作主节点，node2，node3当做分别两个从节点

一旦启动认证功能，就永久保存下来 为了让redis对外通信，监听端口需要改成对外端口 验证6379是否启动

第三个节点安装redis

启动服务

使用redis-cli连入本机客户端

如何配置为从节点，现在还无法复制数据，因为认证没有通过，

还需要指明主节点认证的密码 config set masterauth 现在在主节点上可以使用INFO

lag=1有1秒简单的延迟 查看从节点上是否有数据

smembers 集合 节点3 也可以用同样的方式实现，不过也可以直接修改配置文件 重启服务 主节点上再次INFO查看信息 现在节点3上应该已经能得到数据了 无论你的主节点运行了多少时间，都不需要备份恢复以后再同步

其实除了*slaveof

masterauth 两个核心配置参数

还有一些其他的

slave-serve-stale-data yes

如果主节点宕了，（主节点宕了，不知道自己的数据是否已经过期）从节点能否使用自己的数据，来给用户提供服务

slave-read-only yes（只有成为从节点这个值才有效）

从节点是不是设定为只读

repl-diskless-sync no 复制同步策略

no, Disk-backed, Diskless

** repl-diskless-sync no ，无磁盘复制是yes还是no

no, 不基于磁盘复制

Disk-backed 基于磁盘来做复制

redis的主节点要创建一个新的子进程，它负责把RDB文件先写到磁盘上，随后写完了这个文件才会由父进程传输给slave，而且是incrementally 增量传输

Diskless 不基于磁盘，基于文件来做复制

如果是无磁盘的复制逻辑，指的是redis的主节点，直接创建一个新的子进程，然后这个进程把我们内存中的数据生成快照以后，这个快照文件没存下来而是直接发给从服务器，所以从服务器拿它来直接构建于内存中即可

在主节点上不会把这个数据写到磁盘上，是直接基于内存进行同步 磁盘很慢网络很快，建议使用无磁盘的复制

如果要是启用了无磁盘复制，（一般来讲在主节点上要延迟几秒钟再开始启动复制，因为等待越多的从节点过来，集中发送数据的可能性越大）

延迟多长时间，无磁盘复制才有效，基于磁盘复制，这项指令是无效的

repl-diskless-sync-delay 5 *对复制而言，主节点会不停的探测从节点是否健康，每隔多长时间探测一次

repl-ping-slave-period 10 每隔10秒探测一次

如果探测不在线，再探测还不在线，多少时间超时

repl-timeout 60 一分钟超时

repl-disable-tcp-nodelay no 要不要禁止tcp-disable-delay这个选项，no表示不禁止，表示启用

启用repl-disable-tcp-nodelay 表示数据再小，也要立即传输而不要集合好几个数据再进行传输，

**repl-backlog-size 1mb复制的后援队列的长度 repl-backlog-ttl 后院队列的超时时长，0表示超时 slave-priority 100 如果有多个从节点，从节点的优先级，这里的优先级只有一个作用，一旦主节点宕机了，可以提升一个从作为新的主，数子越小越高级 复制集群中，主节点故障时，sentinel应用场景中的主节点选举时使用的优先级； 数字越小优先级越高，但0表示不参与选举； ** 如果redis主从复制的集群规模很大，一主5从，那么至少几个从节点在线才允许向主节点写入数据，

所以

min-slaves-to-write 3：主节点仅允许其能够通信的从节点数量大于等于此处的值时接受写操作；

（最起码需要有三个从节点在线，才允许你的主节点能接收写操作）

min-slaves-max-lag 10：从节点延迟时长超出此处指定的时长时，主节点会拒绝写入操作；

（这三个从节点还不能落后主节点超过10s，如果超过时，就不计数，不算我们的从节点，所以这两个条件需要同时满足，至少满足三个每一个延时都不能超过10s） 自己链接主节点时，有可能当前slave节点有很多ip，在同一解接口上，会随机使用一个ip链接主节点，如果想要固定的像主节点通过声称自己是来自某特定 ip地址的

announce 这些就是主从复制的配置几个参数

复制：	特点：		一个Master可以有多个slave主机，支持链式复制；		Master以非阻塞方式同步数据至slave主机；			配置slave节点：		redis-cli> SLAVEOF 
    
    
     		redis-cli> CONFIG SET masterauth 
     
      			配置参数：		*slaveof		*masterauth 				slave-serve-stale-data yes 设置了yes就是主节点宕机了，从节点也无法读了		slave-read-only yes		*repl-diskless-sync no			no, Disk-backed, Diskless						新的从节点或某较长时间未能与主节点进行同步的从节点重新与主节点通信，			需要做“full synchronization"，此时其同步方式有两种style：				Disk-backend：主节点新创建快照文件于磁盘中，而后将其发送给从节点；				Diskless：主节占新创建快照后直接通过网络套接字文件发送给从节点；				为了实现并行复制，通常需要在复制启动前延迟一个时间段；				repl-diskless-sync-delay 5		repl-ping-slave-period 10				*repl-timeout 60				repl-disable-tcp-nodelay no		repl-backlog-size 1mb				*slave-priority 100			复制集群中，主节点故障时，sentinel应用场景中的主节点选举时使用的优先级；			数字越小优先级越高，但0表示不参与选举； 				min-slaves-to-write 3：主节点仅允许其能够通信的从节点数量大于等于此处的值时接受写操作；		min-slaves-max-lag 10：从节点延迟时长超出此处指定的时长时，主节点会拒绝写入操作；
     
    
   

因为是基于snapshotting的，可以试着启用snapshotting的持久性，即便不启用，使用AOF也没关系，snapshotting照样是用来做复制的，而不是基于AOF

前面配置了几个参数对于主节点而言，面向不同的客户端，提供的内存缓冲区有多大，硬限，软限，软限超时时间，如果我们从节点够多的话，而网络带宽不够高，这个时候把此缓冲区配置的大一点，内存足够的话，会使得复制过程对于主节点来讲影响尽可能降低，对主节点主进程的影响降低

redis配置主从的两种方式，命令行配置还是配置文件配置

为了避免主节点单点，有了sentinel机制，redis自带，工作逻辑跟MHA非常相似，监控主节点是否OK，主从复制是否没有问题，一旦出现问题，会发送邮件给相关管理员（需要配置）

自动故障转移，就是牺牲从节点为新的主节点，提升哪一个需要靠选举，流言协议互相传输，

还需要用投票协议决定是否把某个从节点提升为主节点

（这里的投票并不是指，投票哪一个从节点为新的主节点，而是投票能不能让这个从节点提升为新的主节点的，）

（如果说我们的sentinel主机探测不到主节点了，（并不一定是主节点宕机了，也有可能是sentinel宕机了，所以就此判断别人宕机了，可能太过武断），所以做集体决策）

sentinel节点不能只有一个，以免出现误判，至少需要三个，qurom机制，超过半数法则，当我们决定把一个从节点提升为一个主的时候，（三个sentinel主机，有两个同意就超过半数了），这样就避免了个人意志，这就是所谓的集体决策的好处， **所以sentinel也需要三个节点，多了以后，也可以自己定义，定义他们选举谁称为主节点时的投票逻辑，也就是所谓的qurom机制，至少应该多少个节点同意这个提议，才能通过 一定是奇数个，以确保大于半数 ** 所有的配置节点配置节点一样，认证要启用就都启用，都使用同一个密码 一旦node3提升为主，node3的slaveof会自动关掉

在这三个节点上各自启动sentinel服务

sentinel有自己的配置文件

主程序 redis-sentinel，redis安装后自带sentinel

这个配置文件可以基于我们当前集群状态会自动被修改的

监听端口26379

本机有多个地址和端口。

announce可以让sentinel宣称用来了哪个地址和端口 sentinel本身不需要存任何数据，有些中间临时数据放到了。tmp mha可以同时监控多个mysql集群，每个集群应该取一个名字放到专门的配置文件中，一个sentinel集群可以帮你监控多个redis集群，每一个主从复制集群，在sentinel当中需要有自己的名字，这个sentinel名字其实叫集群标识，这个标识主要标识集群中的主节点

sentinel monitor mymaster 182.。。。。。

mymaster就是主节点的标识符是什么

182.。。。。。 主节点工作地址

6379 端口

2 需要多少个sentinel节点投票同意这个集群某一节点，才能通过，有3个至少2，有5个至少3

最好多点因为一个人判断宕了，是无法确定最终结果的

乌合之众，群体智商低于个体

sentinel链接个redis节点，要用于控制权限才能设定，比如这个节点成为新主，就要修改slaveoff，需要让sentinel有权限链接以后连接到每个节点，所以要求每一个节点密码得一样就是这个原因

如果一个sentinel节点链接不到每个master了，在多长时间连接不到了，才标识为down sentinel down-after-milliseconds 监控到指定的集群的主节点异常状态持续多久方才将标记为“故障”；

5000=5s 5 秒链接不到就认为down

一次最多给几个从节点完成同步

sentinel parallel-syncs 指在failover过程中，能够被sentinel并行配置的从节点的数量；

设定的并行度越高，主节点压力越大。 故障转义多长时间完成不了，就认为超时，可能需要重新启动故障转移 sentinel failover-timeout sentinel必须在此指定的时长内完成故障转移操作，否则，将视为故障转移操作失败；

默认3分钟，单位是毫秒 一旦发生了故障转移，应该给相关人员发送通知，这里是设定通知脚本的 sentinel notification-script 通知脚本，此脚本被自动传递多个参数； 另外两个节点配置文件应该是一样的 node2-3也启动服务 查看sentinel是否启动起来的、quorum为2 sentinel配置好以后可以用redis-cli redis-cli -h SENTINEL_HOST -p SENTINEL_PORT redis-cli> SENTINEL masters 看你监控了多个集群的各主节点分别是谁 SENTINEL slaves <MASTER_NAME> 某一个指定的主节点的从节点有哪些个 SENTINEL failover <MASTER_NAME> SENTINEL get-master-addr-by-name <MASTER_NAME> sentinel可以设定密码，可以设定与redis不同的密码 在其他节点上也加上 重启redis-sentinel服务，其他节点也一样 requires可能没有用改成bind，复制配置文件，每个节点再次重启 这是第一个对应的主节点的各项信息

name=mymaster

ip=172，16.0.67

奇数是属性名，偶数是相关值 看mymaster有几个从 第二个 SENTINEL failover <MASTER_NAME> 会自动将主节点切换另外一个，就算是主节点没宕，也能切

查看现在的从节点 还可以再一次，正在切换中

切不出去了 查看日志 等三分钟超时完成 当前节点正处于提升的意思，下次宕机，68就接受投票称为新的主 67就没有，重新配置，指向新的主 node3宕server看看 现在就切出去了 现在应该只有一个从 吧69配置好重新上线即可 69这个节点就slave 68是主的了，吧68强行宕 5秒钟认为宕机，来回切，速度比较慢 刚才切，可能不知道master是否宕机，查看下69日志

会尝试向68获取一些数据，但是我们i强行kill，只能等待超时，然后切换

69变成了主节点 看下node2，现在应该是从，最近的配置

slaveoff没有，可能就是要等待超时，才认为故障转移完成，其实应该早就完成，因为68没上线，等待68上线，一直超时了，才认为完成 sentinel： 主要完成三个功能：监控、通知、自动故障转移

选举：流言协议、投票协议			配置项：		port 26379		sentinel monitor 
    
     
      
      
       		sentinel auth-pass 
        
         
         
          表示sentinel集群的quorum机制，即至少有quorum个sentinel节点同时判定主节点故障时， 才认为其真的故障； s_down: subjectively down o_down: objectively down sentinel down-after-milliseconds 
           
           
             监控到指定的集群的主节点异常状态持续多久方才将标记为“故障”； sentinel parallel-syncs 
             
             
               指在failover过程中，能够被sentinel并行配置的从节点的数量； sentinel failover-timeout 
               
               
                 sentinel必须在此指定的时长内完成故障转移操作，否则，将视为故障转移操作失败； sentinel notification-script 
                 
                 
                   通知脚本，此脚本被自动传递多个参数； redis-cli -h SENTINEL_HOST -p SENTINEL_PORT redis-cli> SENTINEL masters SENTINEL slaves 
                  
                    SENTINEL failover 
                   
                     SENTINEL get-master-addr-by-name 
                    
                   
                  
                 
                
               
              
             
            
           
          
         
        
       
      
     
    
   

转载地址：http://jdkgn.baihongyu.com/