NoSQL之Redis集群

---

一、单节点服务器带来的问题

• 单点故障，服务不可用
• 无法处理大量的并发数据
• 数据丢失—大灾难
• 开启多Redis进程
• Redis默认单进程
• 开启多进程导致CPU压力过大
• 对于服务器（纵向）消耗服务器硬件性能CPU
• 解决方法
  搭建Redis集群

二、Redis集群

2.1Redis集群概述

• Redis集群是一个提供在多个Redis间节点间共享数据的程序集
• Redis集群并不支持处理多个keys的命令，因为这需要在不同节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误
• Redis集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令

2.2Redis集群的优点

• 自动分割数据到不同的节点上
• 整个集群的部分节点失败或者不可达的情况下能果继续处理命令

2.3Redis集群的方法

• 有客户端分片
• 代理分片
• 服务器端分片

三、Redis-Cluster数据分片

• Redis集群没有使用一致性hash，而是引入了哈希槽概念
• Redis集群有16384个哈希槽
• 每个key通过CRC16校验后对16384取模来决定放置槽
• 集群的每个节点负载一部分哈希槽
• 以3个节点组成的集群为例
  ①节点A包含0到5500号哈希槽
  ②节点B包含5501到11000号哈希槽
  ③节点C 包含11001到16384号哈希槽
• 支持添加或者删除节点
  ①添加删除节点无需停止服务

四、Redis集群模式

4.1Redis集群模式分类

• 主从同步、复制
• 哨兵模式
• Cluster

4.2主从复制

4.2.1主从复制概述

• 主从复制是高可用Redis的基础，哨兵和集群都是在主从复制基础上实现高可用的，主从复制主要实现了数据的多机备份，以及对于读操作的负载均衡和简单的故障恢复
• 缺陷
  故障恢复无法自动化，写操作无法负载均衡，存储能力受到单机的限制
• 通过持久化功能，redis保证了即使在服务器重启的情况下也不会丢失(或少量丢失)数据，因为持久化会把内存中的数据保存到硬盘上，重启会从硬盘上加载数据，但是由于数据是存储在一台服务器上的，如果这台服务器出现硬盘故障等问题，也会导致数据丢失。为了避免单点故障，通常的做法是将数据库复制多个副本以部署在不同的服务器上，这样即使有一台服务器出现故障，其他服务器依然可以继续提供服务，为此，redis提供了复制(replication)功能，可以实现当一台数据库中的数据更新后，自动将更新的数据同步到其他数据库上。
• 在复制的概念中，数据库分为两类，一类是主数据库(master)，另一类是从数据(slave)。主数据可以进行读写操作，当写操做导致数据变化时自动把数据同步给从数据库，而从数据库一般是只读的，并接收主数据同步过来的数据。一个主数据库可以拥有多个从数据库，而一个从数据库只能拥有一个主数据库

4.2.2主从复制流程

redis-主

• 缓存写入操作的命令
• 主redis派生一个子进程，触发RDB持久化，生成RDB快照文件
  在触发RDB持久化到完成的过程中，客户端在持续写入，这段数据是保存在内存、缓存，这类的数据，靠AOF进行持久化
• 在ADB持久化完成，生成.rdb文件后，主会将.rdb文件和aof持久化的缓存命令，全部交给redis-从服务
• 在持续的主从同步过程中，客户端会持续进行写入命令操作，命令操作也会由主安按照一定的规则来同步给从服务器
  redis-从
  rdb文件和缓存的命令
  基于以上部分进行加载以达到与master趋于一致的状态
  
  

4.3哨兵

4.3.1哨兵概述

哨兵是Redis集群架构中非常重要的一个组件，哨兵的出现主要是解决了主从复制出现故障时需要人为干预的问题

4.3.2 哨兵模式主要功能

• 集群监控：负责监控Redis的master和slave进程是否正常工作
• 消息通知：如果某个Redis实例有故障，那么哨兵负责发送消息作为告警通知给管理员
• 故障转移：如果master node(master角色)挂掉了，会自动转移到slave node上
• 配置中心：如果故障转移发生了，通知client客户端新的master地址
• 使用一个或者多个哨兵(Sentinel)实例组成的系统，对redis节点进行监控在主节点出现故障的情况下，能将从节点中的一个从节点角色升级为主节点，进行故障转义，保证系统的可用性

4.3.3哨兵监控整个系统节点的过程

• 哨兵之间相互进行命令连接目的为了在同一频道进行信息共享和监控
• 哨兵们向master发送命令连接和订阅连接(周期性)
• 哨兵10/s向master发送info,iR-M会回应哨兵本节点的信息状态+从节点的位置
• 哨兵收到回复之后,知晓R-S01 R-S02的位置
• 然后再向slaves发送命令连接和订阅连接(周期性) ,以达到监控整个集群的目的

4.3.4哨兵模式下的故障迁移

• 主观下线
  哨兵(Sentinel)节点会每秒一次的频率向建立了命令连接的实例发送PING命令，如果在down-after-milliseconds毫秒内没有做出有效响应包括(PONG/ LOADING/MASTERDOWN)以外的响应，哨兵就会将该实例在本结构体中的状态标记为SRI_s_DOWN主观下线
• 客观下线
  当一个哨兵节点发现主节点处于主观下线状态是，会向其他的哨兵节点发出询问，该节点是不是已经主观下线了。如果超过配置参数quorum个节点认为是主观下线时，该哨兵节点就会将自己维护的结构体中该主节点标记为SRIO DOWN客观下线询问命令SENTINEL is-master-down-by-addr
• master选举
  在认为主节点客观下线的情况下，哨兵节点节点间会发起一.次选举，命令为:SENTINEL is-master-down-by-addr只是runid这次会将自己的runid带进去， 希望接受者将自己设置为主节点。如果超过半数以.上的节点返回将该节点标记为leacer的情况下，会有该leader对故障进行迁移
• 故障转移
  ①在从节点中挑选出新的主节点
  ②通讯正常
  ③优先级排序
  ④优先级相同时选择offset最大的( 最接近master的)
  ⑤将该节点设置成新的主节点SLAVEOFnoone,并确保在后续的⑥INGO命令时该节点返回状态为master
  ⑦将其他的从节点设置成从新的主节点的从节点，SLAVEQF命令
  ⑧将旧的主节点变成新的主节点的从节点

五、Cluster集群

• redis的哨兵模式基本已经可以实现高可用、读写分离，但是在这种模式每台redis服务器都存储相同的数据，很浪费内存资源，所以在redis3.0上加入了cluster群集模式，实现了redis的分布式存储，也京是说每台redis节点存储着不同的内容根据官方推荐，集群部署至少要3台以上的master节点，最好使用3主3从六个节点的模式
• Cluster群集由多个redis服务器组成的分布式网络服务群集，群集之中有多个master主节点，每一个主节点都可读可写，节点之间会相互通信，两两相连，redis群集无中心节点
• 在redis-Cluster群集中，可以给每个一个主节点添加从节点，主节点和从节点直接尊循主从模型的特性，当用户需要处理更多读请求的时候，添加从节点可以扩展系统的读性能
• redis-cluster的故障转移:redis群集的主机节点内置了类似redissentinel的节点故障检测和自动故障转移功能，当群集中的某个主节点下线时，群集中的其他在线主节点会注意到这一点，并且对已经下线的主节点进行故障转移
• 集群进行故障转移的方法和redis sentinel进行故障转移的方法基本一样，不同的是，在集群里面，故障转移是由集群中其他在线的主节点负责进行的，所以群集不必另外使用redis sentinel