删除完注释的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”
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
