redis集群原理
一、主从架构
1、架构图
（图略）
2、主从复制概述：
主从复制的作用：
- 数据副本（对数据在别的服务器上面进行备份，且从服务器中的数据将会清空并备份主服务器中的数据）
- 拓展读的性能（客户端访问服务器的时候访问从节点，从而减少对主服务器的访问压力）
存在的问题：
- 主节点出现故障的时候，需要手动故障转移，使得在从节点slave中产生一个父节点master【所以需要引入哨兵模式】
- 写能力和存储能力受限(只能对主节点master进行写和存储的操作)
主从复制的实现方式：
1、命令：（优点：无需重启，缺点：不便于管理）
slaveof ip port：设置ip地址为当前服务器中的从服务器，从而实现主从关系。
slaveof no one：取消当前服务器的所有主从关系，不允许有成为任何服务器的从属服务器，但是之前备份的数据不会被删除，只是说之后产生的数据从服务器不会进行备份。
2、配置：(在redis启动之前进行配置，优点：统一配置，缺点：需要重启)
slaveof ip port：设置从节点的ip和端口
slave-read-only yes：设置节点为只读模式，这样会产生节点直接的数据不同步，即从服务器设置为只读模式，主服务器修改了数据，从服务器能同步备份数据，但是如果从服务器修该了数据，主服务不会产生备份效果。
3、主从复制原理
一些概念：
（1）run_id：每次启动redis都会分配一个id，重启之后run_id会变化。
（2）offset：请求master数据得偏移量，部分复制
（3）repl_backlog_size：复制缓冲区大小，默认为1M，部分复制的时候，如果offset在这个范围内，则开始部分复制，否者要进行全量复制。可以修改这个大小以达到更好地复制机制。
redis复制形式分为全量复制和增量复制两种
全量复制的情况：
(1) redis slave首次启动或重启时发生
(2) redis slave进程没有重启，但是掉线了，重新连接后不满足部分复制的条件
增量复制的情况：
(1) 主从的redis版本>=2.8
(2) redis slave进程没有重启，但是掉线了，重连了master(因为slave进程重启的话，run id就没有了)
(3) redis slave保存的run id与master当前run id一致 (注：run id并不是pid，slave把它保存在内存中，重启就消失)
(4) redis slave掉线期间，master保存在内存的offset可用，也就是master变化不大，被更改的指令都保存在内存
redis主从同步策略：slave刚加入集群会触发一次全量同步（全量复制）。全量同步之后，进行增量复制。slave优先是增量同步，如果增量同步失败会尝试从master节点进行全量复制。
redis全量复制过程：
① slave发送psync，由于是第一次复制，不知道master的run_id，自然也不知道offset，所以发送psync ？ -1
② master收到请求，发送master的run_id和offset给从节点。
③ 从节点slave保存master的信息
④ 主节点bgsave保存rdb文件
⑤ 主机点发送rdb文件
并且在④和⑤的这个过程中产生的数据，会写到复制缓冲区repl_back_buffer之中去。
⑥ 主节点发送上面两个步骤产生的buffer到从节点slave
⑦ 从节点清空原来的数据，如果它之前有数据，那么久会清空数据
⑧ 从节点slave把rdb文件的数据装载进自身。
全量复制的开销：
① bgsave时间
② rdb文件网络传输时间
③ 从节点清空数据的时间
④ 从节点加载rdb的时间
⑤ 可能的aof重写时间，这是针对从节点，例如开启了aof之后，从节点添加buffer数据时候，可能需要aof重写
增量复制的过程
① 假设发送网络抖动或者别的情况，暂时失去了连接
② 这个时候，master还在继续往buffer里面写数据
③ slave重新连接上了master
④ slave向master发送自己的offset和runid
⑤ master判断slave的offset是否在buffer的队列里面，如果是，那就返回continue给slave，否则需要进行全量复制（因为这说明已经错过了很多数据了）
⑥master发送从slave的offset开始到缓冲区队列结尾的数据给slave
4、主从架构常见的问题
1、读写分离
好处：流量可以分摊到不同的节点上
可能遇到的问题：
① 复制数据的延迟：例如从节点发生阻塞，就会到值复制数据的延迟
② 读到过期的数据
③ 从节点也有可能发生故障
2、配置不一致
例如maxmemory不一致，容易丢失数据，或者发生诡异的情况
数据结构优化参数（例如has-max-ziplist-entries）：会出现内存不一致的情况
3、规避全量复制
① 第一次全量复制：第一次不可避免，但是我们可以使用小的主节点，或者在半夜低峰的时刻做全量复制
② 节点运营的ID不匹配：例如主节点重启，run_id就会变化，我们可以使用自动故障转移，例如哨兵或者集群
③ 复制积压缓冲区不足：网络中断，部分复制功能无法满足，这个时候可以增大复制缓冲区配置rep_backlog_size。
4、规避复制风暴
① 单主节点复制风暴：由于主节点从起，多个从节点要复制，会产生复制风暴，解决办法是：更换复制0拓扑
② 单机器复制风暴：由于多个主节点都部署在同一个机器上面，机器宕机后需要大量的全量复制，解决办法是：主节点分配到多台机器上面或者使用一些高可用架构，讲从节点晋升为主节点
二、Cluster 集群架构 ————————（3.0版本之后推出的）
Redis 的哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在redis3.0上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，也就是说每台 Redis 节点上存储不同的内容。
1、架构图
2、Cluster集群架构概述
集群的配置：
根据官方推荐，集群部署至少要 3 台以上的master节点，最好使用 3 主 3 从六个节点的模式。在测试环境中，只能在一台机器上面开启6个服务实例来模拟。
集群的特点：
所有的redis节点彼此互联(PING-PONG机制),内部使用二进制协议优化传输速度和带宽。 - 节点的fail是通过集群中超过半数的节点检测失效时才生效。 - 客户端与 Redis 节点直连,不需要中间代理层.客户端不需要连接集群所有节点,连接集群中任何一个可用节点即可。
集群的数据分布算法：
（1）hash算法
hash(key)
存在问题： 如果增加一个redis，映射公式变成了 hash(key)%(N+1)，如果一个redis宕机了，映射公式变成了 hash(key)%(N-1)，在这两种情况下，几乎所有的缓存就都失效了。会导致数据库的访问压力陡增，导致数据库宕机。
（2）一致性哈希算法
一个master宕机不会导致大部分缓存失效，可能存在缓存热点问题。可以用虚拟节点改进
（3）**redis cluster的hash slot算法**
在 Redis 的每一个节点上，都有这么两个东西，一个是插槽（slot），它的的取值范围是：0-16383。还有一个就是cluster，可以理解为是一个集群管理的插件。当我们的存取的 Key到达的时候，Redis 会根据 crc16的算法得出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。
###### 节点间的内部通信机制：
（1）redis cluster节点间采取gossip协议进行通信
跟集中式不同，不是将集群元数据（节点信息，故障，等等）集中存储在某个节点上，而是互相之间不断通信，保持整个集群所有节点的数据是完整的
集中式：好处在于，元数据的更新和读取，时效性非常好，一旦元数据出现了变更，立即就更新到集中式的存储中，其他节点读取的时候立即就可以感知到; 不好在于，所有的元数据的跟新压力全部集中在一个地方，可能会导致元数据的存储有压力
gossip：好处在于，元数据的更新比较分散，不是集中在一个地方，更新请求会陆陆续续，打到所有节点上去更新，有一定的延时，降低了压力; 缺点，元数据更新有延时，可能导致集群的一些操作会有一些滞后
（2）10000端口
每个节点都有一个专门用于节点间通信的端口，就是自己提供服务的端口号+10000，比如7001，那么用于节点间通信的就是17001端口
每个节点每隔一段时间都会往另外几个节点发送ping消息，同时其他几点接收到ping之后返回pong
（3）交换的信息
故障信息，节点的增加和移除，hash slot信息，等等
