集群是个好东西，一个应用解决不了的，多个应用共同分担。提高了程序的高可用！
介绍redis-benchmark
项目遇到性能问题，基本都会以集群方式去解决。在讲Redis的集群之前，我们先学会Redis的性能压力测试。–redis-benchmark
redis 服务在windows环境下的启动命令是redis-server.exe ，在此文件夹，往往还存在一个新的文件redis-benchmark.exe,此文件就是用来进行redis的压力测试的！(linux环境也是一样的！) 中文官网说明：http://www.redis.cn/topics/benchmarks.html
Mac 安装Redis
# Mac 显示隐藏文件夹
defaults write com.apple.finder AppleShowAllFiles -boolean true ; killall Finder# 1 查看是否安装 Homebrew
brew --version
# 2 安装redis
brew install redis
# 3 卸载redis
brew cleanup redis
# 4 启动redis
/opt/homebrew/opt/redis/bin/redis-server /opt/homebrew/etc/redis.conf测试性能
redis-benchmark -q -n 100000
实际每秒10万的处理性能已经很不错了！足够面对企业服务器的需求了！
Redis主从复制
配置Redis一主二从结构
不同版本的Redis配置命令发生变化了：replicaof是新版本的命令，旧版本是slaveof命令
# 主节点 master
port 6379
# 从节点1 slave1
port 6380
# replicaof <masterip> <masterport>
replicaof 127.0.0.1 6379
# 从节点2 slave2
port 6381
# replicaof <masterip> <masterport>
replicaof 127.0.0.1 6379
启动主从Redis
/opt/homebrew/opt/redis/bin/redis-server /opt/homebrew/etc/redis01.conf
/opt/homebrew/opt/redis/bin/redis-server /opt/homebrew/etc/redis02.conf
/opt/homebrew/opt/redis/bin/redis-server /opt/homebrew/etc/redis03.conf检查Redis 主从状态信息
redis-cli -p 6379
输入 infoRedis哨兵模式 Redis Sentinel
什么是Redis哨兵模式？
redis主从复制有个最大的确定就是，主节点挂了，需要人工干预才能保证业务的正常运行。Redis主从复制对主从服务器做一个监视的任务。一旦发现主服务器宕机了，就迅速启动相应的规则将某一台从服务器升级为主服务器，无需人工干预，更稳定更快。
本质就是一个Redis服务器，只是用于监控，不可set，get相关命令！
使用Redis哨兵模式的前提是，至少拥有Redis集群的一个主从结构！
Redis哨兵配置文件
配置文件必须加入下方内容
sentinel monitor master-name ip port quorum
# 配置master节点的密码
#sentinel auth-pass master-name 我是密码上述配置参数讲解
- master-name 监控主节点的名字，多个哨兵需要配置一致 一般配置为 mymaster
- ip 表示：redis主节点ip
- port 表示：redis主节点port
- quorum 表示：判定某节点被哨兵标记为挂掉的哨兵数量，一般配置为哨兵数量除2再减一
port 26379
dir /tmp/redis-test-data-dir
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000port 26380
dir /tmp/redis-test-data-dir
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000port 26381
dir /tmp/redis-test-data-dir
sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 30000
sentinel parallel-syncs mymaster 1
sentinel failover-timeout mymaster 180000启动哨兵 (需提前开启redis主从模式)
哨兵会自动组建集群：我们一般不会单独配置一个哨兵，而是配置哨兵数量为：大于1的奇数，一般为三个。因为哨兵需要进行投票。如果只有1个哨兵，发现redis服务器有问题，很有可能是其自己的网络问题。如果有2个哨兵，一个哨兵，发现故障，另一个哨兵没发现故障，我们就不知要不要切换新的master节点了。如果有3个哨兵，我们就可以设定半数投票机制。如果认定失败数大于总哨兵数一半以上，就认定是相对比较合理的。如果哨兵设置为偶数个，相互投票，可能投票数打平。建议为大于1的奇数
/opt/homebrew/opt/redis/bin/redis-sentinel /opt/homebrew/etc/redis-sentinel01.conf
/opt/homebrew/opt/redis/bin/redis-sentinel /opt/homebrew/etc/redis-sentinel02.conf
/opt/homebrew/opt/redis/bin/redis-sentinel /opt/homebrew/etc/redis-sentinel03.conf当每新开启一个哨兵后，前面的哨兵的配置文件就会发生变化，添加了新哨兵的信息！
如果发生主节点宕机，我们可以简单干预主从切换，那就需要在redis服务端的配置文件，加入replica-priority，此数值越小，优先级越高！选值是 0-100，如果是0，则不会被选举为主节点。设置为1即可。
哨兵原理
1、监控阶段
哨兵1连接master，获取子节点与其记录的哨兵信息，再与master建立cmd连接，如果有其他哨兵，使用发布订阅，公开获取最新的redis服务器信息，其他哨兵获取后，同步自己的数据
哨兵1通过上一步的信息，连接其他Redis子节点并获取其记录的哨兵信息，并建立cmd连接
哨兵2连接master，获取子节点与其他哨兵信息，并与master建立cmd连接
哨兵2通过上一步的信息，连接子节点与其他哨兵信息，并建立与子节点cmd连接，于此同时，使用发布订阅，公开获取最新的redis服务器信息，其他哨兵获取后，同步自己的数据
2、通知阶段
每个哨兵都会与redis服务器进行通信，通信失败后，就会给此服务器标记状态，分为：
sdown主观下线 odown客观下线
sdown 是有哨兵与任一redis节点进行通信，如ping pong，如果在down-after-milliseconds时间内此节点没有响应,则该哨兵认为此redis节点主观下线了。
如果是认定master主观下线的哨兵则会通过指令sentinel is-masterdown-by-addr寻求其它哨兵对主节点的判断，当超过quorum（在sentinel配置中配置的法定人数）个数，此时哨兵节点则认为该主节点确实有问题，这样就客观下线了。一旦触发客观下线，就会触发第三步：故障转移
尚不清晰，非master节点宕机，哨兵会不会判定客观下线，我本机测试只有sdown
3、故障转移
哨兵之间推选出故障转移的哨兵
故障转移的哨兵，拿到所有节点，经过一些列判断，选出主redis服务器
通知选举出的主redis服务器，你作为master服务器了
通知其他从服务器：新的master信息
redis脑裂
redis脑裂是当前master节点与所有哨兵断开连接，但实际是正常的，但是原有哨兵，就安排了新的master出来。也就是说，同时存在了2个master了。客户端有多个连接，有的连接老master，有的连接新master。2个master之间数据是不一样的，过了一段时间，老master网络正常了，加入集群中，就会作为从节点，同步新master的数据，（同步过程是，A发起同步请求，B会打包rdb文件，A拿到rdb文件 A执行flusb db，A还原rdb数据）导致老master在没加入集群期间，新数据的丢失！
解决redis脑裂
redis配置文件添加
min-slaves-to-write ：是指主库最少得有 N 个健康的从库存活才能执行写命令。建议设定为：slaves的数量/2 +1
min-slaves-max-lag ：是指从库和主库进行数据复制时的 ACK 消息延迟的最大时间；
新版本Redis 配置变更为：
min-replicas-to-write 3
min-replicas-max-lag 10如果同时存在多个master，必然有1个master不会拥有子节点。设置min-slaves-to-write后，老master发现没有足够的从节点，就会拒绝写入服务。如果同时设定了min-slaves-max-lag，就变为足够满足从节点数且其复制时间不超过指定时间，master才能正常使用。如果无法满足master就会拒绝写入！大大减少了脑裂造成的数据丢失！脑裂一般无法满足一个数据不丢失！
