redis四种模式

1、单机模式

单机模式就是在一台服务器上安装redis，然后启动，所有业务都调用这一台redis服务器。
优点：部署简单，只需要在一台服务器上安装并启动redis就行。
成本低，没有备用节点，不需要其他的开支。
高性能，单机不需要同步数据，数据天然一致性。
缺点：可靠性较弱，一旦服务器宕机，所有业务都无法使用redis服务。单机模式redis性能受限于CPU的处理能力。

2、主从模式

主从模式是指有多台redis服务器，其中一台专门用来负责写入客户端请求数据，称为主节点（master），
其他服务专门负责处理客户端的读取数据的请求不负责写入数据，称为从节点。
主节点写入的数据会复制的各个从节点上，并且数据复制的方向是单向的，只能从主节点复制到从节点。

主从模式搭建：
1. 在多台服务器上搭建redis服务。
2. 修改所有作为slave节点的服务器上Redis的配置⽂件，指定要同步的 Master 节点 IP 和端⼝。
replicaof 192.168.126.1 6379
3. 启动所有节点就可以了。
具体⼯作机制：
1. slave启动后，向master发送SYNC命令，master接收到SYNC命令后通过bgsave将当前主节点的全量数据以rdb的⽅式保存快照，同时使⽤缓冲区记录后续主节点执⾏的增量数据。
2. master将保存的快照⽂件发送给slave。
3. slave接收到快照⽂件后，加载快照⽂件，载⼊数据。
4. 当slave节点复制完全量数据后，主节点在将后续的增量数据同步给slave节点，slave接收命令并执⾏，完成复制初始化。
5. 此后master每次执⾏⼀个写命令都会同步发送给slave，保持master与slave之间数据的⼀致性。
优点：
1. 读写分离：master写，slave读，同时可以根据访问需求⼤⼩来添加slave节点数量。
2. 负载均衡：通过读写分离的⽅式来分但服务器负载，主节点负责写⼊数据，多个从节点负责读取数据，缓解单个服务器访问的压⼒，提⾼读的吞吐量。
3. 数据冗余：主从复制实现了数据的热备份，是持久化之外的⼀种数据冗余⽅式。
4. ⾼可⽤性：提⾼了服务的可⽤性，多个节点同时提供服务，当前其中⼀台节点宕机后，其他节点仍然可以提供服务。
5. 故障恢复：master宕机后，快速升级slave为master。
缺点：
1. master宕机后，slave节点升级成新的master节点后，需要⼿动切换主机，同时会有部分数据不能及时同步从服务器，造成数据不⼀致。
2. slave宕机后，多个slave恢复后，⼤量的SYNC同步会造成master IO压⼒倍增。
3. 主从模式只要⼀个maste节点，所以master节点的写数据的能⼒会受到单机的限制。

3、哨兵模式

哨兵模式主要是在主从复制模式基础上，增加了⾃动化的故障恢复功能。
因为主从复制模式下，当master节点宕机后，虽然slave节点会升级成新的master节点，但是升级后的slave节点的ip顺其⾃然的就称为了新的master节点ip，原先其他的slave节点配置的master节点的ip也是需要变更的，在主从复制模式下，这种变更是需要⼈⼯⼿动去修改配置⽂件的。⽽哨兵模式则完美的解决了这⼀缺陷，实现了快速的⾃动恢复，不再需要⼈⼯修改。

哨兵集群搭建：
需要注意到是每个哨兵都是⼀个独⽴的redis服务，只是不提供数据的读取服务。⼀般哨兵模式都是以集群的⽅式部署，每个哨兵都部署在不同的服务器上，且每个哨兵的配置⽂件除了ip和端⼝不⼀样，其他基本都是⼀样。⼀般集群中包含的哨兵数⽬都为奇数。
1. 在服务器上搭建redis服务。
2. 在redis⽬录下，创建哨兵的配置⽂件，⽂件名只能是 sentinel .conf。
3. 编辑sentinel.conf配置⽂件，设置哨兵的相关属性。
–后台运⾏
daemonize yes
–本机IP
bind 192.168.11.1
–sentinel端⼝号
port 26372
–指定pid⽂件
pidfile “/var/run/redis-sentinel.pid”
–指定log⽂件
logfile “/home/redis/redis/sentinel.log”
–指定⼯作⽬录
dir “/home/redis/redis”
–避免脚本重置，默认值yes
sentinel deny-scripts-reconfig yes
–监听节点，monitor 后⾯依次我需要监听的节点名、节点ip、节点端⼝、最后的2表示如果有两台服务器认定master已死，则宣传master死记。
sentinel monitor mymaster 192.168.11.152 7001 2
– 30秒连接不上mymaster 节点,则判断定mymaster 已死
sentinel down-after-milliseconds mymaster 30000
– 主备切换时，最多有多少个slave同时对新的master进⾏同步，这⾥设置为默认的1
sentinel parallel-syncs mymaster 1
– 3分钟同步没完成算超时
sentinel failover-timeout mymaster 180000
4. 先启动master再启动slave，再启动哨兵。
哨兵的主要功能：
1. 集群监控：负责监控 master 和 slave 进程是否正常⼯作。
2. 消息通知：如果某个 Redis 实例宕机，那么哨兵负责向（哨兵间，客户端）发送消息。
3. ⾃动故障转移：当master宕机后，由哨兵负责重新在slave节点中选举出新的master节点，并将其他slave连接到新的master，以及告知客户端新的服务器地址。更好的为客户端提供⾼可⽤服务。
哨兵模式的缺点：
哨兵的部署会占⽤额外的服务器资源，且不提供数据的读取服务。哨兵模式除了解决了主从模式⼿动切换主从节点的问题外，其他主从模式存在的问题，哨兵模式基本也都存在。

4、集群模式

1. redis集群解决了哪些问题？
主从模式实现了数据的热备份，哨兵模式实现了redis的⾼可⽤。但是这两种模式存在两个问题：
（1）写并发：这两种都只能有⼀个master节点负责写操作，在⾼并发的写操作场景，master节点就会成为性能瓶颈。⽽redis集群则可以实现多个节点同时提供写操作，redis集群模式采⽤⽆中⼼结构，每个节点都可以看做是⼀个主从模式，节点之间互相连接从⽽知道整个集群状态。
（2）海量数据的存储压⼒：⽆论是哨兵模式还是主从模式，每台机器上存储的数据都是⼀样的，都是从主节点上复制过去的，本质上只有⼀台Master作为存储。所以⽆论增加多少slave节点都⽆法解决单台机器存储的上限问题。但是集群模式就解决了这以问题，因为Redis Cluster是⼀种服务器 Sharding 技术，采⽤数据分⽚的⽅式，将不同的数据存储在不同的master节点上⾯，因为我们可以通过不断的增加集群中的节点，从⽽达到存储海量数据。
2. redis集群的实现原理？
Redis集群采⽤去中⼼化的思想，没有中⼼节点的说法，对于客户端来说，整个集群可以看成⼀个整体，可以连接任意⼀个节点进⾏操作，就像操作单⼀Redis实例⼀样，不需要任何代理中间件，当客户端操作的key没有分配到该node上时，Redis会返回转向指令，指向正确的node。Redis也内置了⾼可⽤机制，⽀持N个master节点，每个master节点都可以挂载多个slave节点，当master节点挂掉时，集群会提升它的某个slave节点作为新的master节点。Redis集群可以看成多个主从架构组合起来的，每⼀个主从架构可以看成⼀个节点（其中，只有master节点具有处理请求的能⼒，slave节点主要是⽤于节点的⾼可⽤）。

1. 分布式寻址算法
（1）hash算法：将key使⽤hash算法计算之后，按照节点数量来取余，即hash(key)%N。如果增加⼀个redis，映射公式变成了 hash(key)%(N+1)。如果⼀个redis宕机了，映射公式变成了hash(key)%(N-1)。优点就是⽐较简单，但是扩容或者摘除节点时需要重新根据映射关系计算，会导致数据重新迁移，从⽽造成数据库访问的压⼒陡增。
（2）⼀致性hash算法：将所有的存储节点排列在⾸尾相接的hash环上，各个节点通常是以节点的ip或者主机名进⾏hash计算来得到排列在hash环上的具体位置。然后每个key在计算Hash后会得到排列在hash环上的具体位置，最后分布在hash环上的key会顺时针找到最近的存储节点存放。优点是在加⼊和删除节点时只影响该节点与之逆时针⽅向最近⼀个节点之间的数据，缺点是数据的分布和节点的位置有关，因为这些节点不是均匀的分布在哈希环上的，所以数据在进⾏存储时达不到均匀分布的效果，可能造成雪崩效应。
（3）hash slot 算法：hash槽算法主要为了解决⼀致性hash算法数据倾斜不⼀致性的问题，所谓的槽其实就是⼀个数组。Redis集群有16384 个哈希槽，每个key通过CRC16校验后对16384取模来决定放置哪个槽，集群的每个节点负责⼀部分hash槽。客户端可能会挑选任意⼀个redis实例去发送命令，接收到命令的redis实例都会计算key对应的hash slot，如果在本地就在本地处理，否则返回moved给客户端，让客户端进⾏重定向到hash slot对应的节点上去处理。优点是解耦数据和节点之间的关系，简化了节点扩容和收缩难度。节点⾃身维护槽的映射关系，⽀持节点、槽、键之间的映射查询，⽤于数据路由、在线伸缩等场景。
2. 节点间的内部通信机制
redis cluster节点间采取gossip协议进⾏通信，跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，⽽是互相之间不断通信，保持整个集群所有节点的数据是完整的。集中式的好处在于节点信息的更新和读取时效性⾮常好，所有节点的元数据信息都集中式的存储在⼀起，⼀旦某个节点元数据出现了变更，⽴即就更新到集中式的存储中。不好在于，所有的元数据的跟新压⼒全部集中在⼀个地⽅，可能会导致元数据的存储有压⼒。gossip好处在于，将元数据的更新分散到各个节点上，不再集中在⼀个地⽅处理，降低了集中式处理的压⼒，但是有⼀定的延时，可能导致集群的⼀些操作会有⼀些滞后。且gossip协议对服务器时间的要求较⾼，时间戳不准确会影响节点判断消息的有效性。随着节点数量增多后的节点间频繁的通信会导致⽹络开销增加，同时结点数太多，意味着达到最终⼀致性的时间也相对变⻓，因此官⽅推荐最⼤节点数为1000左右。
通信端⼝
每个节点都有⼀个专⻔⽤于节点间通信的端⼝，就是⾃⼰提供服务的端⼝号+10000，⽐如8011，那么⽤于节点间通信的就是18011端⼝。
交换的信息
节点间的通信主要有：故障信息，节点的增加和移除，hash slot信息，等等。
gossip常⻅协议类型
gossip协议常⻅的消息类型包含： ping、pong、meet、fail等等。
（1）meet: 某个节点发送meet给新加⼊的节点，让新节点加⼊集群中，然后新节点就会开始与其他节点进⾏通信。
（2）ping：⽤于交换节点的元数据。每个节点每秒会向集群中其他节点发送 ping 消息，消息中封装了⾃身节点状态还有其他部分节点的状态数据，也包括⾃身所管理的槽信息等等。
（3）pong：ping和meet消息的响应，同样包含了⾃身节点的状态和集群元数据信息。
（4）fail：某个节点判断另⼀个节点 fail 之后，向集群所有节点⼴播该节点挂掉的消息，其他节点收到消息后标记已下线。
3. 集群的扩容与收缩
集群主要是采⽤hash slot 算法进⾏寻址的，由于集群hash槽的数⽬是固定的，所以随着集群中节点数⽬的增减，每个节点所负责的hash槽的数⽬也会随之发⽣变化，因此对应槽和数据都会在节点之间移动。
1.扩容步骤：
（1）启动新节点；
（2）刚启动的新节点是没有和其他节点进⾏通讯的，因此需要在集群中任意节点执⾏ clustermeet 命令让新节点加⼊到集群中；
（3）新的节点加⼊到集群后，迁移槽和数据，将⼀些槽和数据从旧节点迁移到新节点；
（4）槽和数据迁移到新加⼊的节点后，新的节点会向集群中的各个主节点⼴播通知迁移过来的槽，并更新⾃身的槽节点对应表。
2. 收缩步骤：
（1）迁移槽，⾸先判断要下线的节点是否有负责的槽，如果有，则先将该节点下的槽全部迁移到其他节点，否则直接删除该节点。
（2）通知集群的各个节点忘记⾃⼰。

详细可参考：
https://blog.csdn.net/qq_33807380/article/details/124484627