Redis-3-部署方案&实用工具

Redis-3-部署方案&实用工具

目录

• Redis-3-部署方案&实用工具
  • 0. redis相关软件
  • 1. 主从部署方案
    • 1.1 主节点Master
    • 1.2 从节点Slave
    • 1.3 Master-Slave replication
    • 1.4 复制功能的运行原理
    • 1.5 写请求异步复制
    • 1.6 过期KEY的处理
    • 1.7 主从架构的高可用问题
    • 1.8 存在的问题
  • 2. 哨兵集群&sentinel核心
  • 3. redis cluster集群
    • 3.1 故障检测
  • 4. Redis集群搭建流程
    • 4.1 下载redis安装包
    • 4.2 放入指定目录
    • 4.3 解压
    • 4.4 安装gcc，系统中有gcc的可以跳过此步骤
    • 4.5 make编译并安装
    • 4.6 修改配置文件redis.conf
    • 4.7 防火墙配置
    • 4.8 启动redis实例
    • 4.9 创建集群
  • 5. redis代理
    • 5.1 各Redis代理比较
    • 5.2 redis-cloud-netty

0. redis相关软件

• redis-benchmark : redis压测工具
• redis-shake : 数据迁移工具

1. 主从部署方案

• 主从架构
• 读写分离
• 支撑高并发

redis在读写数据的时候，读数据比写入慢。

redis本质其实和mysql一样，都是提供数据的写入和读取。区别是redis的数据存储在内存中，在数据读写的时候是基于内存的，速度比传统的关系型数据库快得多。要让redis提供极高的数据读写并发，和传统数据库一样，我们也需要将数据的读写区分开。

1.1 主节点Master

• 提供数据写入，集群只有一台机器接受写入请求，再广播(复制)数据到其他的子节点上，保证数据的写入一致性。
• 一个Master可以配置多个slave
• 采用异步的方式复制数据
• 建议开启持久化与数据备份

1.2 从节点Slave

• 提供数据读取服务
• 对集群提供水平扩容，提升整体吞吐量
• 也可以提供写服务，但不会同步到master，可以做临时数据用
• 高可用结构下，Slave可以在master宕机后自动接管

1.3 Master-Slave replication

Redis支持简单易用的主从复制功能。该功能可以让Slave成为Master的精确复制品。

• Redis使用异步复制，从Redis2.8开始。Slave会以每秒一次的频率向Master报告复制流的处理进度
• 一个Master可以有多个Slave
• 不仅Master可以有Slave，Slave也可以有自己的Slave。多个Slave间形成一个图状结构
• 复制功能不会阻塞Master：只要redis.conf中做了相应配置，即使Slave正在进行初次同步，服务器也可以使用旧版本的数据来处理命令查询
• 你还可以配置Slave，让它在和Master的连接断开时，向客户端发送一个错误
• 可以通过复制功能来让Master免于执行持久化操作：只要关闭Master的持久化功能，然后由Slave去执行持久化操作即可

1.4 复制功能的运行原理

1. 无论是初次连接还是重新连接，slave服务器都将向Master发送一个sync命令
2. 接到sync命令的Master节点开始执行bgsave，在此过程中接收到的客户端命令写入内存中临时保存
3. 当bgsave执行完毕后，Master会将生成的rdb文件发送给slave服务器
4. slave接收到rdb文件，保存到磁盘持久化，并将文件中的数据载入到内存中
5. rdb数据同步完成后，master会将之前执行RDB以及同步数据这段时间产生的最新数据同步给slave，达到主从一致

1.5 写请求异步复制

数据可以从Master向任意数量的Slave上同步，同步使用的是发布/订阅机制。

1.6 过期KEY的处理

master如果有KEY过期了，会主动向slave发送一条del命令

1.7 主从架构的高可用问题

1. slave宕机，在系统中配置slave最少在线个数和最小延迟达到阈值的时候会导致整体集群不可写，除此不会导致整个集群不可用。因为还有其他的slave提供服务，只是链接到当前宕机的slave客户端被断开。
2. master宕机，会导致系统不可用

这样就会导致系统出现比较大的风险。

1.8 存在的问题

Redis在使用这种架构的时候，主从之间存在一定的时间差，在使用锁操作的时候存在一定的问题。

2. 哨兵集群&sentinel核心

哨兵集群的核心就是一个高可用哨兵集群（建议为3个），用于监听master和多个slave机器的健康状态，并通过判断主从的健康状态及时切换主机来保证高可用。我认为这也是代理模式的其中一种，但是是伪代理，并不直接代理请求，而是解析获取主机地址，然后连接redis的master节点。

几个关键点

• sdown: 如果一个哨兵节点发现master宕机，则为sdown
• odown: 认为sdoen的哨兵节点数量达到quorum配置的数量后，则置为odown，进入选举新master流程
• quorum: 配置项，配置哨兵集群中多少个节点断开master连接则认为该节点不可用
• 当主节点宕机后，sentinel哨兵会自动选举新master，并通过消息通知客户端切换master的IP来实现高可用
• 哨兵最少3个节点来保证高可用
• 哨兵不保证数据完整性，保证集群的高可用性
• 当集群中节点出现问题，可以通过配置的shell脚本通知管理员
• 一个sentinel集群可以管理多个主从Redis

哨兵的自动发现机制
哨兵的配置中指定了master的地址，name在同一master下的哨兵会自动互相发现。这是利用redis自身的订阅机制实现的。所有的哨兵在上线后都会订阅_sentinel_hello频道。

脑裂现象
例如一主三从的Sentinel主从集群，如果sentinel集群和master的网络出现故障，但是master和slave之间的网络通讯正常，就会出现这个问题。master会被下线，但是仍然会有残存的客户端写请求进入，而根据sentinel的机制，已经会将其中的一台slave提升为master，并接受新的客户端连接，最终出现的结果就是老的master和新的master之间的数据可能会有出入。
解决的方法就是配置sentinel,如下，如果三台sentinel连接的延迟在10ms内，则正常接收请求，否则拒绝。最大限度降低影响

• min-replicas-to-write 3
• min-replicas-max-lag 10

哨兵机制下的java客户端
一般都有支持。单独的sentinel客户端

3. redis cluster集群

• 普通hash：直接对Key做hash，然后取模
• 一致性hash：hash环，先定位节点值，在hashKey的时候，根据节点值，大于节点值则存入下一个节点。出现故障的时候会增加下一个节点的负载
• hash槽（hash slot）：槽机制允许使用不同的策略对KEY的hash进行管理

3.1 故障检测

1. 集群中的每个节点都会定期通过集群内部总线向集群中的其他节点发送PING命令，用于检测对方是否在线，如果接收ping消息的节点没有在指定时间内返回PONG消息，那么发送PING消息的节点就会将接收PING消息的节点标注为疑似下线状态（probable fail, pfail）
2. 检测信息传播集群中的各个节点会通过互相发消息的方式来交换自己掌握的集群中各个节点的状态信息，如在线、疑似下线(pfail)、下线(fail)
3. 基于检测信息作下线判决。如果在一个集群里，超过半数的处理槽的主节点豆浆某个主节点X报告为疑似下线，那么，主节点X将被标记为下线（fail），并广播出去，所有收到这条fail消息的节点都会立即将主节点X标记为fail。至此，故障检测完成

4. Redis集群搭建流程

4.1 下载redis安装包

从redis官网（http://download.redis.io/releases/）可以下载redis所有版本

4.2 放入指定目录

将下载好的压缩包上传到系统指定目录，这里以usr/local为例（其它两台机器同理）
rz -e选择你下载的压缩包上传即可：

4.3 解压

tar -zxvf redis-5.0.3.tar.gz

4.4 安装gcc，系统中有gcc的可以跳过此步骤

由于redis是c语言写的，所以需要gcc编译
yum -y install gc

4.5 make编译并安装

进入r解压后的目录，执行make命令编译
cd redis-5.0.3
make

4.6 修改配置文件redis.conf

修改redis.conf中的以下内容（其它两台机器同理）

port 6379
daemonize yes
pidfile /var/run/redis_6379.pid
logfile "6379.log"
bind 0.0.0.0
daemonize yes
cluster‐enabled yes
cluster-config-file nodes-6379.conf
cluster‐node‐timeout 5000
protected‐mode no
appendonly yes
一台机器上两个实例的话，需要复制一份redis.conf，改名为redis6380.conf，将上面的配置中的6379的地方改为6380即可。（其它两台机器做同样的操作）

4.7 防火墙配置

在防火墙中开放你所有的redis端口以及每个对应端口号+10000的端口

firewall-cmd --zone=public --add-port=6379/tcp --permanent
firewall-cmd --zone=public --add-port=6380/tcp --permanent
firewall-cmd --zone=public --add-port=16379/tcp --permanent
firewall-cmd --zone=public --add-port=16380/tcp --permanent
firewall-cmd --reload

4.8 启动redis实例

src/redis-server redis.conf
src/redis-server redis6380.conf

4.9 创建集群

src/redis-cli --cluster create 192.168.209.128:6379 192.168.209.128:6380 192.168.209.129:6379 192.168.209.129:6380 192.168.209.130:6379 192.168.209.130:6380 --cluster-replicas 1

上面输入yes回车等待创建：

创建完毕

5. redis代理

1. twProxy
2. predixy
3. codis
4. redis-cerberus
5. redis-cloud-netty（自开发）

5.1 各Redis代理比较

特性	predixy	twemproxy	codis	redis-cerberus
高可用	Redis Sentinel或Redis Cluster	一致性哈希	Redis Sentinel	Redis Cluster
可扩展	Key哈希分布或Redis Cluster	Key哈希分布	Key哈希分布	Redis Cluster
开发语言	C++	C	GO	C++
多线程	是	否	是	是
事务	Redis Sentinel模式单Redis组下支持	不支持	不支持	不支持
BLPOP/BRPOP/BLPOPRPUSH	支持	不支持	不支持	支持
Pub/Sub	支持	不支持	不支持	支持
Script	支持load	不支持	不支持	不支持
Scan	支持	不支持	不支持	不支持
Select DB	支持	不支持	支持	Redis Cluster只有一个DB
Auth	支持定义多个密码，给予不同读写及管理权限和Key访问空间	不支持	同redis	不支持
读从节点	支持，可定义丰富规则读指定的从节点	不支持	支持，简单规则	支持，简单规则
多机房支持	支持，可定义丰富规则调度流量	不支持 有限支持	有限支持
统计信息	丰富	丰富	丰富	简单

5.2 redis-cloud-netty

自己的开源实现。
基于netty开发的代理服务，利用了netty、VIP、apollo等机制完成TCP协议的代理和内存数据库的实现。