集群是个好东西，一个应用解决不了的，多个应用共同分担。提高了程序的高可用！
介绍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
仅仅截取常规的命令速度，可以看出来M1 Pro，每秒处理10万个请求没问题！我也加大了10万连接数调整为20万，实际速度能达到12万左右
实际每秒10万的处理性能已经很不错了！足够面对企业服务器的需求了！
Redis主从复制
参照：https://www.jb51.net/article/224568.htm
上述图片描述的是：1个主库 + 2 个从库。同时两个从库，本身就各带有2个从库。
Redis集群数据复制的原理
1、同步SYNC：主服务器收到SYNC命令后，生成RDB快照文件，然后发送给从服务器
- 发送psync命令进行数据同步，由于是第一次进行复制，从节点没有复制偏移量和主节点的运行ID，所以发送psync-1。
- 主节点根据psync-1解析出当前为全量复制，回复+FULLRESYNC响应。
- 从节点接收主节点的响应数据保存运行ID和偏移量offset
- 主节点执行bgsave保存RDB文件到本地
- 主节点发送RDB文件给从节点，从节点把接收的RDB文件保存在本地并直接作为从节点的数据文件
- 对于从节点开始接收RDB快照到接收完成期间，主节点仍然响应读写命令，因此主节点会把这期间写命令数据保存在复制客户端缓冲区内，当从节点加载完RDB文件后，主节点再把缓冲区内的数据发送给从节点，保证主从之间数据一致性。
- 从节点接收完主节点传送来的全部数据后会清空自身旧数据
- 从节点清空数据后开始加载RDB文件
- 从节点成功加载完RDB后，如果当前节点开启了AOF持久化功能， 它会立刻做bgrewriteaof操作，为了保证全量复制后AOF持久化文件立刻可用。
2、命令传播：主服务器收到客户端修改数据命令后，数据库数据发生变化，同时将命令缓存起来，然后将缓存命令发送到从服务器，从服务器通过载入缓存命令来达到主从数据一致。
命令传播的方式是：使用psync {runId} {offset}
下面介绍的是命令传播中图遇到失败的情况。
- 当主从节点之间网络出现中断时，如果超过repl-timeout时间，主节点会认为从节点故障并中断复制连接
- 主从连接中断期间主节点依然响应命令，但因复制连接中断命令无法发送给从节点，不过主节点内部存在的复制积压缓冲区，依然可以保存最近一段时间的写命令数据，默认最大缓存1MB。
- 当主从节点网络恢复后，从节点会再次连上主节点
- 当主从连接恢复后，由于从节点之前保存了自身已复制的偏移量和主节点的运行ID。因此会把它们当作psync参数发送给主节点，要求进行部分复制操作。
- 主节点接到psync命令后首先核对参数runId是否与自身一致，如果一 致，说明之前复制的是当前主节点；之后根据参数offset在自身复制积压缓冲区查找，如果偏移量之后的数据存在缓冲区中，则对从节点发送+CONTINUE响应，表示可以进行部分复制。
- 主节点根据偏移量把复制积压缓冲区里的数据发送给从节点，保证主从复制进入正常状态。
了解上述两种机制后，Redis集群数据复制的原理就是：从库向主库发送SYNC命令，主库开始执行bgsave生成RDB文件，发送给从库。如果此时主库生成完RDB文件，主库依旧有命令操作数据变化，主库就利用命令传播机制，将主库的变化命令给从库。
看一下别人上传的时序图
配置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
以下均是 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 redis-cli -p 6379 输入info，执行后会打印大量的信息，如果想了解具体含义，可以前往：https://www.zanglikun.com/7123.html info
Redis 主从复制 优缺点
优点：提供了可用性（可以实现读写分离），从库多了，宕机一个问题不大。
缺点：
- master节点挂了需要人工干预切换master节点。
- master节点宕机后，恢复瞬间会有大量从节点SYNC命令进来，Master节点 IO压力大。
Redis哨兵模式 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再减一
3个哨兵的配置
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 180000
port 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 180000
port 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的奇数
下面是启动3个哨兵的命令 /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-server端（非哨兵）的配置文件，加入replica-priority参数，此数值越小，被推为主节点优先级越高！选值是 0-100，如果是0，则不会被选举为主节点。设置为1即可。
哨兵原理
1、检测主节点挂了
2、确定主节点挂了，Sentinel将server2升级为主服务器，server3/4从新的主服务器进行复制。同时等待server1的再次上线。
3、如果Server1此事正常了。Sentinel系统也可以主动降级主节点为从节点，将从节点升级为主节点。
底层实现机制
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就会拒绝写入！大大减少了脑裂造成的数据丢失！脑裂一般无法满足一个数据不丢失！
Redis哨兵模式的缺点
优点：主要用来监控redis主从集群，提高了redis 主从集群的可用性。
缺点：Redis较难支持在线扩容（我不是很理解在线扩容的含义）
Cluster模式
Redis Cluster是一种服务器 Sharding 技术，redis 3.0版本开始正式提供。
哨兵模式基本已经实现了高可用，但是每台机器都存储相同内容，很浪费内存，所以Redis Cluster实现了分布式存储。每台机器节点上存储不同的内容。
Cluster模式的每一个主机都是主节点，同时会对每个节点进行Slot范围划分。大意就是。每次操作执行读写操作时，会依据key做算法判定，得出slot数，针对slot范围，读写操作就针对某个节点了。
操作落在那个节点公式是：slot = crc16(“KeyName”) % 16384
Redis Cluster数据分片原理
redis 数据分片使用的是hash slot， redis集群有16384个哈希槽（用bitmap存储就是占有内存2kb，大意就是最多16384个节点，正常业务不会超过那么多的节点的），每个Key通过CRC16校验后对16384取模来决定放置哪一个槽。
当存取redis key时候，redis会根据CRC16算法得到一个结果，然后把结果和16384求余，通过这个值去对应得节点获取数据。
这个时候，应用客户端实际上只需要连接其中任意一个节点即可，然后Redis Cluster 中每个节点都保存了其他节点得槽信息。这样当存取key计算完槽之后，通过保存槽信息从配置中获取节点信息，然后再去对应得节点获取数据。
Redis建议Cluster模式是3主3从模式，一共6个节点。
如果构建了3主3从模式。
如果：主节点挂了，会把从节点推选为新主节点。如果老主节点恢复，就加入从节点。
如果：主节点挂了，从节点也挂了，整个集群拒绝执行。
1、实现了分布式存储，节省了内存
