删除完注释的redis.conf:
protected-mode no
port 6379
tcp-backlog 511
timeout 0
tcp-keepalive 300
daemonize yes
supervised no
pidfile /var/run/redis_6379.pid
loglevel notice
logfile ""
databases 16
always-show-logo yes
save 900 1
save 300 10
save 60 10000
stop-writes-on-bgsave-error yes
rdbcompression yes
rdbchecksum yes
dbfilename dump.rdb
dir ./
replica-serve-stale-data yes
replica-read-only yes
repl-diskless-sync no
repl-diskless-sync-delay 5
repl-disable-tcp-nodelay no
replica-priority 100
requirepass 123456
lazyfree-lazy-eviction no
lazyfree-lazy-expire no
lazyfree-lazy-server-del no
replica-lazy-flush no
appendonly no
appendfilename "appendonly.aof"
appendfsync everysec
no-appendfsync-on-rewrite no
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
aof-load-truncated yes
aof-use-rdb-preamble yes
lua-time-limit 5000
slowlog-log-slower-than 10000
slowlog-max-len 128
latency-monitor-threshold 0
notify-keyspace-events ""
hash-max-ziplist-entries 512
hash-max-ziplist-value 64
list-max-ziplist-size -2
list-compress-depth 0
set-max-intset-entries 512
zset-max-ziplist-entries 128
zset-max-ziplist-value 64
hll-sparse-max-bytes 3000
stream-node-max-bytes 4096
stream-node-max-entries 100
activerehashing yes
client-output-buffer-limit normal 0 0 0
client-output-buffer-limit replica 256mb 64mb 60
client-output-buffer-limit pubsub 32mb 8mb 60
dynamic-hz yes
aof-rewrite-incremental-fsync yes
rdb-save-incremental-fsync yes
哨兵使用的配置文件sentinel.conf
port 26379
sentinel monitor mymaster 192.168.174.131 6379 1
sentinel auth-pass mymaster 123456
daemonize yes
protected-mode no
树状主从
一主多从
一主一从
下面开始redis集群:
http://www.redis.cn/
https://www.cnblogs.com/leeSmall/p/8398401.html
https://www.cnblogs.com/51life/p/10233340.html
Redis有三种集群方式:主从复制,哨兵模式和集群
一、Redis主从复制:主节点负责写数据,从节点负责读数据,主节点定期把数据同步到从节点保证数据的一致性
1. 主从复制的相关操作
master配置修改端口:redis.conf
port 6379
requirepass 123456
masterauth 123456 (下次作为从服务器登录主服务器密码)
slave1修改配置: s1.conf
port 6380
replicaof 192.168.174.132 6379 (5.x) | slaveof 192.168.174.132 6379
requirepass 123456
masterauth 123456
pidfile “/var/run/redis_6380.pid”
replica-read-only yes #从服务器默认只读,从服务写会造成主从不一致
slave2修改配置: s2.conf
port 6381
replicaof 127.0.0.1 6379|6380(slave1的从服务器)
requirepass 123456
masterauth 123456
pidfile “/var/run/redis_6381.pid”
requirepass是认证密码,之后要作主从切换,所以建议所有的密码都一致, masterauth是从机对主机验证时,所需的密码。(即主机的requirepass)
启动主机:
redis-server redis.conf
启动从机:
redis-server s1.conf
redis-server s2.conf
验证主从复制:
master:
[root@localhost master]# redis-cli
127.0.0.1:6379> auth 123456
OK
127.0.0.1:6379> set test chenqm
OK
127.0.0.1:6379> info replication
Replication
role:master
connected_slaves:2
slave0:ip=127.0.0.1,port=6380,state=online,offset=2559,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=2559,lag=0
…
slave1:
[root@localhost slave2]# redis-cli -p 6380
127.0.0.1:6380> auth 123456
OK
127.0.0.1:6380> get test
“chenqm”
slave2:
[root@localhost slave2]# redis-cli -p 6381
127.0.0.1:6381> auth 123456
OK
127.0.0.1:6381> get test
“chenqm”
切换主从:
主节点shutdown后,将从节点转换成为主节点
127.0.0.1:6380> slaveof no one|replicaof no one
将当前服务器转变为某一服务器的副本服务器
127.0.0.1:6381> slaveof 127.0.0.1 6380|replicaof 192.168.174.131 6380
- Redis主从拓扑
a)一主一从:用于主节点故障转移从节点,当主节点的“写”命令并发高且需要持久化,可以只在从节点开启AOF(主节点不需要),这样即保证了数据的安全性,也避免持久化对主节点的影响
b)一主多从:针对“读”较多的场景,“读”由多个从节点来分担,但节点越多,主节点同步到多节点的次数也越多,影响带宽,也加重主节点的不稳定
c)树状主从:一主多从的缺点(主节点推送次数多压力大)可用些方案解决,主节点只推送一次数据到从节点B,再由从节点B推送到C,减轻主节点推送的压力。
-
数据同步
redis 2.8版本以上使用psync命令完成同步,过程分“全量”与“部分”复制
全量复制:一般用于初次复制场景(第一次建立SLAVE后全量)
部分复制:网络出现问题,从节点再次连接主节点时,主节点补发缺少的数据,每次数据增量同步
心跳:主从有长连接心跳,主节点默认每10S向从节点发ping命令,repl-ping-slave-period控制发送频率 -
主从的缺点
a)主从复制,若主节点出现问题,则不能提供服务,需要人工修改配置将从变主
b)主从复制主节点的写能力单机,能力有限
c)单机节点的存储能力也有限
5.主从故障如何故障转移
a)主节点(master)故障,从节点slave-1端执行 slaveof|replicaof no one后变成新主节点;
b)其它的节点成为新主节点的从节点,并从新节点复制数据;
c)需要人工干预,无法实现高可用。
二、哨兵模式:
万一主机挂了,redis提供了一个sentinel(哨兵),以此实现主从切换的功能,类似zookeeper
哨兵模式是一种特殊的模式,首先Redis提供了哨兵的命令,哨兵是一个独立的进程,作为进程,它会独立运行。其原理是哨兵通过发送命令,等待Redis服务器响应,从而监控运行的多个Redis实例
1、通过发送命令,让Redis服务器返回监控其运行状态,包括主服务器和从服务器。
2、当哨兵监测到master宕机,会自动将slave切换成master,然后通过发布订阅模式通知其他的从服务器,修改配置文件,让它们切换主机。
3、一个哨兵进程对Redis服务器进行监控,可能会出现问题,为此,我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控,这样就形成了多哨兵模式。
配置sentinel:
vi sentinel.conf:
port 26379
sentinel monitor mymaster 192.168.174.131 6379 1
sentinel auth-pass mymaster 123456
daemonize yes
protected-mode no
#哨兵服务端口
port 26379
#哨兵监控的master,当集群中有超过一半以上及2个(quorum)sentinel认为master死了时,才能真正认为该master已经不可用了【注意这里ip不能写127.0.0.1,否则将来程序也会去找127.0.0.1】
sentinel monitor mymaster 192.168.174.131 6379 2 (quorum)
#设置master和slave验证密码(sentinel不能分别为master和slave设置不同的密码,因此master和slave的密码应该设置相同)
sentinel auth-pass mymaster 123456
#守护进程模式
daemonize yes
#关闭保护模式
protected-mode no
#master或slave多长时间(默认30秒)不能使用后标记为s_down状态。
sentinel down-after-milliseconds mymaster 30000
#从节点执行replicaof no one命令一直失败的话,当时间超过18S时则故障转移失败
sentinel failover-timeout mymaster 18000
1、启动sentinel服务(到对应的目录(src)执行相应的命令):
./redis-sentinel …/sentinel.conf
注意启动的顺序:首先主机服务,然后启动从机服务,最后启动哨兵服务
2、关闭master进程:kill -9 6379 (使用shutdown退出有时候不能修改配置文件)
3、查看客户端
master切换了,当6379端口的这个服务重启的时候,他会变成slave。
因为sentinel在切换master的时候,把对应的sentinel.conf和redis.conf文件的配置修改。
4、多哨兵模式下选举
http://www.sohu.com/a/318236060_100149956
这个选举的大体思路是:
每个哨兵节点通过向其他哨兵节点发送”sentinel is-master-down-by addr”命令来申请成为哨兵领导者。
而每个哨兵节点在收到一个”sentinel is-master-down-by addr”命令时,只允许给第一个节点投票,其他节点的该命令都会被拒绝。
如果一个哨兵节点收到了半数以上的同意票半且超过它配置的quorum的票数,则成为哨兵领导者。
哨兵模式的优缺点:
优点:
哨兵模式是基于主从模式的,所有主从的优点,哨兵模式都具有。
主从可以自动切换,系统更健壮,可用性更高。
缺点:
Redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂。
三、Redis-Cluster集群
https://blog.youkuaiyun.com/fst438060684/article/details/80712433
https://blog.youkuaiyun.com/qq_36514588/article/details/83856795
https://blog.youkuaiyun.com/weixin_42440345/article/details/95048739
redis的哨兵模式基本已经可以实现高可用,读写分离,但是在这种模式下每台redis服务器都存储相同的数据,浪费内存,所以在Redis3.0上加入了cluster模式,实现的redis的分布式存储,也就是说每台redis节点上存储不同的内容。
搭建集群创建cluster目录,分别配置多个redis.conf,官方建议至少3主3从
redis.conf:
daemonize yes //redis后台运行
pidfile /var/run/redis_6000.pid //pidfile文件对应6000,6001,6002
port 6000 //端口6000,6001,6002
cluster-enabled yes //开启集群 把注释#去掉
cluster-config-file nodes_6000.conf //集群的配置 配置文件首次启动自动生成
cluster-node-timeout 5000 //请求超时 设置5秒够了
masterauth “123456”
requirepass “123456”
Redis5.0开始不再使用ruby搭建集群,使用命令redis-cli:(注意不要写127.0.0.1)
redis-cli --cluster create 192.168.199.130:6001 192.168.199.130:6002 192.168.199.130:6003 192.168.199.130:6004 192.168.199.130:6005 192.168.199.130:6006 -a 123456 --cluster-replicas 1
replicas 1 表示我们希望为集群中的每个主节点创建一个从节点
手动挂载从节点:
redis-cli --cluster add-node 192.168.174.131:6003 192.168.174.131:6000 --cluster-slave
创建集群出错:[ERR] Node xxxxx is not empty. Either the node already knows other nodes (check with CLUSTER NODES)
解决方法:
1)、停止所有redis进程,将需要新增的节点下aof、rdb等本地备份文件删除;
2)、同时将新Node的集群配置文件删除,即:删除你redis.conf里面cluster-config-file所在的文件,一般为nodes.conf;
3)、再次添加新节点如果还是报错,对数据库进行清除:
192.168.174.131:6000> flushdb
测试:
打开端口为6000的客户端 查看:
[root@localhost master]# redis-cli -c -p 6000 -a 123456
127.0.0.1:6000> cluster info
127.0.0.1:6000> set id 111
-> Redirected to slot [7568] located at 127.0.0.1:6002
OK
127.0.0.1:6002> get id
“122”