Redis三种集群方案

01.Redis主从架构(读写分离)

现在企业用主从架构的不多了,
搭建过程看这里:
https://www.yuque.com/crow/xq7vsx/17705

如果你redis是单击模式的话,假如你客户端访问的话,万一redis挂了没办法重启,那个整个架构就崩溃了.

主从架构就是你操作redis还是操作 master ,然后master里面的数据会实时同步到slave里面去,万一master挂掉了,我可以把某一个slave变成新的master.

如果你为master配置了一个slave，不管这个slave是否是第一次连接上Master，它都会发送一个SYNC命
令(redis2.8版本之前的命令)给master请求复制数据。
master收到SYNC命令后，会在后台进行数据持久化通过bgsave生成最新的rdb快照文件，持久化期间，
master会继续接收客户端的请求，它会把这些可能修改数据集的请求缓存在内存中。当持久化进行完毕以
后，master会把这份rdb文件数据集发送给slave，slave会把接收到的数据进行持久化生成rdb，然后再加
载到内存中。然后，master再将之前缓存在内存中的命令发送给slave。
当master与slave之间的连接由于某些原因而断开时，slave能够自动重连Master，如果master收到了多
个slave并发连接请求，它只会进行一次持久化，而不是一个连接一次，然后再把这一份持久化的数据发送
给多个并发连接的slave。
当master和slave断开重连后，一般都会对整份数据进行复制。但从redis2.8版本开始，master和slave断
开重连后支持部分复制。
数据部分复制
从2.8版本开始，slave与master能够在网络连接断开重连后只进行部分数据复制。
master会在其内存中创建一个复制数据用的缓存队列，缓存最近一段时间的数据，master和它所有的
slave都维护了复制的数据下标offset和master的进程id，因此，当网络连接断开后，slave会请求master
继续进行未完成的复制，从所记录的数据下标开始。如果master进程id变化了，或者从节点数据下标
offset太旧，已经不在master的缓存队列里了，那么将会进行一次全量数据的复制。
从2.8版本开始，redis改用可以支持部分数据复制的命令PSYNC去master同步数据

主从复制(全量复制)流程图：

主从复制(部分复制)流程图：

1．主从架构的核心原理

当启动一个slave node的时候，它会发送一个PSYNC命令给master node

如果这是slave node重新连接master node，那么master node仅仅会复制给slave部分缺少的数据; 否则如果是slave node第一次连接master node，那么会触发一次full resynchronization(全量的复制,可以理解为全部复制)

开始full resynchronization的时候，master会启动一个后台线程，开始生成一份RDB快照文件，同时还会将从客户端收到的所有写命令缓存在内存中。RDB文件生成完毕之后，master会将这个RDB发送给slave，slave会先写入本地磁盘，然后再从本地磁盘加载到内存中。然后master会将内存中缓存的写命令发送给slave，slave也会同步这些数据。

slave node如果跟master node有网络故障，断开了连接，会自动重连。master如果发现有多个slave node都来重新连接，仅仅会启动一个rdb save操作，用一份数据服务所有slave node。

2．主从复制的断点续传

从redis 2.8开始，就支持主从复制的断点续传，如果主从复制过程中，网络连接断掉了，那么可以接着上次复制的地方，继续复制下去，而不是从头开始复制一份

master node会在内存中常见一个backlog，master和slave都会保存一个replica offset还有一个master id，offset就是保存在backlog中的。如果master和slave网络连接断掉了，slave会让master从上次的replica offset开始继续复制

但是如果没有找到对应的offset，那么就会执行一次resynchronization

3．磁盘化复制

master在内存中直接创建rdb，然后发送给slave，不会在自己本地落地磁盘了

repl-diskless-sync
repl-diskless-sync-delay，等待一定时长再开始复制，因为要等更多slave重新连接过来

4．过期key处理

slave不会过期key，只会等待master过期key。如果master过期了一个key，或者通过LRU淘汰了一个key，那么会模拟一条del命令发送给slave。

02.Redis哨兵高可用架构

搭建过程看这里:
https://www.yuque.com/crow/xq7vsx/17705

哨兵架构还是会有主从架构,但是我会开启几个哨兵服务(sentinel).

我redis客户端连接的是哨兵服务,sentinel哨兵是特殊的redis服务，不提供读写服务，主要用来监控redis实例节点。
Java客户端通过哨兵可以拿到redis里面的所有信息的,后面Java客户端会直接访问从哨兵那里获取到到redis地址数据,
如果redis的master挂了,哨兵会从我们剩下的slave里面选出一个新的节点作为master.哨兵会把master节点告诉Java客户端.
说白了了就是类似一种监听机制,哨兵监听redis主从架构的情况.

哨兵架构下client端第一次从哨兵找出redis的主节点，后续就直接访问redis的主节点，不会每次都通过sentinel代理访问redis的主节点，当redis的主节点发生变化，哨兵会第一时间感知到，并且将新的redis主节点通知给client端(这里面redis的client端一般都实现了订阅功能，订阅sentinel发布的节点变动消息)

03.Redis集群

安装参考:
https://www.yuque.com/crow/xq7vsx/17748
https://www.yuque.com/crow/xq7vsx/17747

哨兵模式的问题

在redis3.0以前的版本要实现集群一般是借助哨兵sentinel工具来监控master节点的状态，如果master节点异常，则会做主从切换，将某一台slave作为master，哨兵的配置略微复杂，并且性能和高可用性等各方面表现一般，特别是在主从切换的瞬间存在访问瞬断的情况，而且哨兵模式只有一个主节点对外提供服务，没法支持很高的并发，且单个主节点内存也不宜设置得过大，否则会导致持久化文件过大，影响数据恢复或主从同步的效率.

高可用集群模式

redis集群是一个由多个主从节点群组成的分布式服务器群，它具有复制、高可用和分片特性。Redis集群不需要sentinel哨兵也能完成节点移除和故障转移的功能。需要将每个节点设置成集群模式，这种集群模式没有中心节点，可水平扩展，据官方文档称可以线性扩展到上万个节点(官方推荐不超过1000个节点)。redis集群的性能和高可用性均优于之前版本的哨兵模式，且集群配置非常简单.
redis集群数据是分片存储的,每一个主从架构里面的数据是完全不一样的.数据是分片存储的.存数据的时候会通过某种算法对key进行运算后,再把key和value指定到运算后应该存放的主从小组里面.
这个就类似HashMap的key通过hash()算法后找到对应的数组一样.