redis群集部署，主从结构及哨兵模式

redis群集

部署原因

问题：单字节Redis服务器带来的问题
单点故障，服务不可用
无法处理大量的并发数据请求
数据丢失——大灾难

解决方法
搭建Redis集群（至少3个，奇数个服务器）
基于高可用性，有主备节点备份，集群规模至少6个服务器

Redis集群介绍

Redis集群是一个提供在多 个Redis间节点间共享数据的程序集

Redis集群并不支持处理多个keys的命令,因为这需要在不同的节点间移动数据，从而达不到像Redis那样的性能，在高负载的情况下可能会导致不可预料的错误

Redis集群通过分区来提供一定程度的可用性，在实际环境中当某个节点宕机或者不可达的情况下可继续处理命令

优势

自动分割数据到不同的节点上

整个集群的部分节点失败或者不可达的情况下能够继续处理命令（数据顺序存储，有主备替补）

实现方式

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

Redis-Cluster数据分片

Redis集群没有使用一致性hash,而是引入了哈希槽（数据存储空间）概念
Redis集群有16384个哈希槽（0-16383）
每个key通过CRC1 6校验后对16384取模来决定放置槽
集群的每个节点负责一部分哈希槽

槽与节点的使用

以3个节点组成的集群为例：
节点A包含0到5500号哈希槽
节点B包含5501到11000号哈希槽
节点C包含11001到16383号哈希槽

支持添加或者删除节点时，无需停止服务

如果想添加新节点,需要移动其他节点中的部分槽到要添加的节点上
如果想移除旧节点,需要将要移除的节点中的槽移到其他节点上，再将没有任何槽的节点从集群中移除

Redis-Cluster的主从复制模型

集群中具有A，B，C三个节点，如果节点B失败了，整个集群就会因缺少5501-11000这个范围的槽而不可用

为每个节点添加一一个从节点A1, B1, C1,整个集群便有三个master节点和三个slave节点组成，在节点B失败后，集群便会选举B1为新的主节点继续服务

当B和B1都失败后，集群将不可用

redis群集部署

redis群集拓扑

配置六台1，2，3，4，5，6主机，IP地址为20.0.0.10/20/30/40/50/60保证全网互通后，关闭所有防火墙

安装redis群集

解压缩

tar zxvf redis-5.0.4.tar.gz

编译安装

cd redis-5.0.4/
make   
make PREFIX=/usr/local/redis install #更改安装路径可以用make PREFIX=安装路径 install
ln -s /usr/local/redis/bin/* /usr/local/bin #创建命令链接

查看并运行安装脚本

cd redis-5.0.4/utils/
./install_server.sh 

查看端口状态

netstat -anpt | grep redis

编辑配置文件

vi /etc/redis/6379.conf
70  bind 20.0.0.10                    #修改127.0.0.1为本机地址
89  protected-mode no #关闭保护模式
137 daemonize yes #以独立进程启动
700 appendonly yes                    #开启AOF持久化
839 cluster-enabled yes       #开启群集功能
847 cluster-config-file nodes-6379.conf #群集名称文件设置
853 cluster-node-timeout 15000 #群集超时时间
930 cluster-require-full-coverage yes #当主节点宕机，且无从节点时，集群任可使用

/etc/init.d/redis_6379 stop   #关闭服务
/etc/init.d/redis_6379 start  #启动服务
#配置其余服务器时，bind后为其本机地址

在1号主机上

yum -y install ruby rubygems
gem install redis-3.2.0.gem 
redis-cli --cluster create --cluster-replicas 1 20.0.0.10:6379 20.0.0.20:6379 20.0.0.30:6379 20.0.40:6379 20.0.0.50:6379 20.0.0.60:6379
#建立集群配置
yes

测试群集

在从节点上建立数据库后，在主节点查看
在4号主机上

redis-cli -h 20.0.0.40 -p 6379 -c #登录数据库
set a 1 #添加a键值为1
Redirected to slot [8949] located at 20.0.0.10:6379 #提示存储该键值的哈希槽为8949，位置定位到在服务器20.0.0.11上

在3号主机上

redis-cli -h 20.0.0.30 -p 6379 -c
get a

在1号主机上

redis-cli -h 20.0.0.10 -p 6379 -c 
get a

可以在任意一台服务器上查看群集信息
cluster info 查看群集信息
cluster nodes 查看节点信息

Redis 主从结构

现存问题

Redis虽然读取写入的速度都特别快，但是也会产生读压力特别大的情况。为了分担读压力，Redis支持主从复制，保证主数据库的数据内容和从数据库的内容完全一致。

结构和分类

Redis的主从结构可以采用一主多从或者级联结构，Redis主从复制可以根据是否是全量分为全量同步和增量同步。

全量同步

Redis全量复制一般发生在Slave初始化阶段，这时Slave需要将Master上的所有数据都复制一份。

步骤
1.从服务器连接主服务器，发送SYNC命令；
2.主服务器接收到SYNC命令后，开始执行BGSAVE命令生成RDB文件并使用缓冲区记录此后执行的所有写命令；
3.主服务器BGSAVE执行完后，向所有从服务器发送快照文件，并在发送期间继续记录被执行的写命令；
4.从服务器收到快照文件后丢弃所有旧数据，载入收到的快照；
5.主服务器快照发送完毕后开始向从服务器发送缓冲区中的写命令；
6.从服务器完成对快照的载入，开始接收命令请求，并执行来自主服务器缓冲区的写命令；

增量同步

Redis增量复制是指Slave初始化后开始正常工作时主服务器发生的写操作同步到从服务器的过程。
增量复制的过程主要是主服务器每执行一个写命令就会向从服务器发送相同的写命令，从服务器接收并执行收到的写命令。

Redis主从同步策略流程

主从刚刚连接的时候，进行全量同步；全同步结束后，进行增量同步。当然，如果有需要，slave 在任何时候都可以发起全量同步。

redis 策略：首先会尝试进行增量同步，如不成功，要求从机进行全量同步。

主从复制的目的

为了让主数据库中的数据复制给从数据库，保证主数据库与从数据库的一致性，使客户端从主与备数据库读取无差别，可以帮助主数据库减轻负载压力，也解决单点故障问题。

部署

拓扑

需保证互通，且关闭防火墙

流程

redis基础安装

同时在三台主机上安装

tar zxvf redis-5.0.4.tar.gz #解压软件包
cd redis-5.0.4/ 
make #配置安装
make DREFIX=/usr/local/redis install #更改安装路径
cd
ln -s /usr/local/redis/bin/* /usr/local/bin/ #创建命令链接
cd redis-5.0.4/utils/
./install_server.sh #运行安装脚本
netstat -anpt | grep redis #查看端口状态

redis主服务器配置

vi /etc/redis/6379.conf 
70    bind 0.0.0.0                               #修改监听地址为0.0.0.0
137 daemonize yes                         #开启守护进程
172 logfile /var/log/redis_6379.log  #修改日志文件目录
264 dir /var/lib/redis/6379               #修改工作目录
700 appendonly yes                       #开启AOF持久化功能
 
 /etc/init.d/redis_6379 restart          #服务重启

redis从服务器配置

vi /etc/redis/6379.conf 
70   bind 0.0.0.0                       #修改监听地址为0.0.0.0
700 appendonly yes                 #开启AOF持久化功能
287 replicaof 20.0.0.10 6379    #增加一个同步master节点IP和端口

/etc/init.d/redis_6379 restart     #服务重启

查看效果

在主服务器上

tail -f /var/log/redis_6379.log #查看日志

在从服务器上

tail -f /var/log/redis_6379.log #查看日志

检测主从数据复制功能
在主服务器上

redis-cli #进入数据库
set a 1 #建立键为a值为1
get a #查看键a
info replication  #状态信息
exit #退出数据库

在从服务器上

redis-cli #进入数据库
get a #查看键a
info replication  #状态信息
exit #退出数据库

模拟主服务器宕机
将主服务器服务关闭

/etc/init.d/redis_6379 stop      关闭服务
tail -f /var/log/redis_6379.log  查看日志

查看从服务器状态


在祝主服务器宕机后，虽然仍会转移数据，且不影响读取，但从服务器不会转化为主服务器

可以通过哨兵功能实现主从的状态转化

哨兵模式

概述

哨兵(sentinel) 是一个分布式系统，用于对主从结构中的每台服务器进行监控，当出现故障时通过投票机制选择新的master并将所有slave连接到新的master。所以整个运行哨兵的集群的数量不得少于3个节点。

作用

监控

不断的检查master和slave是否正常运行。
master存活检测、master与slave运行情况检测

通知

当被监控的服务器出现问题时，向其他（哨兵间，客户端）发送通知。

自动故障转移

断开master与slave连接，选取一个slave作为master，将其他slave连接到新的master，并告知客户端新的服务器地址

TIP:哨兵也是一台redis服务器，只是不提供数据服务哨兵的启动依赖于主从模式，所以须把主从模式安装好的情况下再去做哨兵模式，所有节点上都需要部署哨兵模式，哨兵模式会监控所有的redis工作节点是否正常，当master出现问题的时候，因为其他节点与主节点失去联系，因此会投票，投票过半就认为这个master的确出现问题，然后会通知哨兵间，然后从slaves中选取一个作为新的master

哨兵部署流程

在主服务器上

vi redis-5.0.4/sentinel.conf 
protected-mode no                 #关闭保护模式
daemonize yes                     #指定sentine1为后台启动，开启守护进程
logfile "/var/log/sentinel.log"   #指定日志存放路径
dir /var/lib/redis/6379           #指定数据库存放路径
sentinel monitor mymaster 20.0.0.10 6379 2     #指定几个哨兵（slave）检测主服务器故障，才会进行故障迁移（主服务器ip地址，端口号，slave数）
sentinel down-after-milliseconds mymaster 3000   #判定服务器down掉的时间周期，默认30000毫秒（30秒）
sentinel failover-timeout mymaster 100000#故障节点的最大超时时间为180000毫秒（180秒）

将文件拷贝到两个从服务器上

scp redis-5.0.4/sentinel.conf root@20.0.0.20:/root/redis-5.0.4
scp redis-5.0.4/sentinel.conf root@20.0.0.30:/root/redis-5.0.4

启动哨兵模式，从主服务器开始，然后启动两个从服务器

redis-sentinel redis-5.0.4/sentinel.conf &
ps aux | grep redis
ps aux | grep sentinel #查看进程状态

查看数据库状态信息

redis-cli -h 20.0.0.10 -p 26379 info sentinel
redis-cli -h 20.0.0.10 -p 6379 info replication

模拟主服务器宕机

/etc/init.d/redis_6379 stop  #停止服务
ps aux | grep redis          #查看进程状态

查看日志，已经转移到2号主机上了

 tail -f /var/log/sentinel.log 

在新的主服务器上查看状态信息

将原本的主服务器服务开启后


master状态并不会再次转换重新到自己上，这一点不同于vrrp服务，原因vrrp有优先级设置，此服务没有。