Redis 集群之主从架构原理及安装部署

为什么需要集群?

Redis 单机能够支持的 QPS 大概在 几万左右,具体是多少和服务器的配置以及业务的操作有关。但如果你的应用的 需要支撑上十万的 QPS 时,单机的 Redis 是无法支撑这么大的 QPS 的,如果卡死在 Redis,那么系统就无法做到高并发了。这个时候就需要使用集群。这里我们先介绍最简单的一种Redis 集群架构——主从架构。

什么是 Redis 主从架构?

Redis 主从架构一般是指定一主一从,或者一主多从。主节点负责写数据,并且把数据复制到从节点。从节点负责读。所有的读请求都使用从节点。主节点我们称为 master node 。从节点我们称为 slave node。我们如果,要支撑上十万或更多的 QPS 时,只需求多部署几个从节点即可,可以非常方便的进行水平扩展。

主从架构的核心原理

当启动一个从节点的时候,它会发送一个 psync 命令给主节点。如果这个从节点是重新连接主节点的,那么 master node 只会复制给 slave node 丢失的部分数据。而如果是第一次连接的话,则会解决一次 full resynchronization,即全量复制。

全量复制机制

开始 full resynchronization 操作的时候,master node 会启动一个后台进行,开始生成一份 RDB 快照文件,同时还会将客户端收到的所有写命令缓存写入内存中。RDB 文件生成完毕以后,master node 会把这个文件发送给 slave node。slave node 会把这个文件先保存到磁盘,然后加载到内存中去。最后 master node 会把执行 full resynchronization 操作后,生成的内存数据发送给 slave node, slave node 也会同步这部分数据。

RDB 复制有一个超时时间,默认值是 60s ,如果 RDB的复制时间超过了这个设定值,那么 slave node 就会认为复制失败。对于千网网网卡,60s 能够传输的数据在 6G 左右,在生产过程中,可以适当的调整这个值。

在复制 RDB的过程中,master node 会把后面的写操作缓存到内存中,这其中有一个配置 client-output-buffer-limit slave 256MB 64MB。即如果在复制期间,如果缓冲区的持续消耗 64M 或者一次性超过 256M,那么也会停止复制,复制失败。

增量复制机制

如果在复制的过程中,如果 slave node 跟 master node 有网络故障,断开了连接,会自动进行重连,触发增量复制。Redis 支持断点续传,即网络重连后,可以接上上次复制的地方,继续复制下去,而不是从头开始复制一份新的数据

那是如果实现断点续传功能的呢?

在复制的过程中,master node 会维护一个内存缓存区 backlog。master node 和 slave node 都会维护一个 replica offset 和 master run id。offset 就是保存在 backlog里面的。当连接断开以后,slave node 重新连接到 master node,如果二个服务器的 master run id 相同,并且指定的 offerset 在内存中还有效,而复制从上次中断的地方开始续传。如果 master run id 不一致,或者未找到 offset ,则会进行全量复制。

无磁化复制

master 直接在内存中生成 RDB快照,不写入磁盘,直接发送给 slave node,这样可以减小 IO 操作,提升性能。

过期 key 的处理

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

Redis 主从架构安装部署

Redis 5 的主从架构配置与之前的主从架构配置有所不同。

准备

准备三台服务器,配置一主二从的架构。其中 IP 映射关系:

192.168.56.101 worker-01        worker-01.joyxj.com
192.168.56.102 worker-02        worker-02.joyxj.com
192.168.56.103 worker-03        worker-03.joyxj.com

其中配置 worker-01 为主节点,worker-02 和 worker-02 为从节点。

下载、解压、编译

这部分可以参可这篇文章: redis 快速安装及配置开机自启动。或者使用以下脚本:

# 进入目录,redis 安装包路径
cd /opt/tools
# 下载
wget http://download.redis.io/releases/redis-5.0.5.tar.gz
# 解压
tar -zxvf redis-5.0.5.tar.gz
cd redis-5.0.5
REDIS_DIR=`pwd`
# 安装相关依赖
yum -y install gcc gcc-c++ libstdc++-devel tcl
# 编译
make MALLOC=libc && make test && make install
# 复制启动脚本
echo "复制配置脚本"
cp ${REDIS_DIR}/utils/redis_init_script /etc/init.d/
mv /etc/init.d/redis_init_script /etc/init.d/redis_6379
# 创建目录,用于在放配置脚本和持久化目录
mkdir -p /etc/redis
mkdir -p /var/redis/6379

# 复制配置文件到 /etc/redis目录下,并重命名
cp ${REDIS_DIR}/redis.conf /etc/redis
mv /etc/redis/redis.conf /etc/redis/6379.conf

# 配置自启动
cd /ect/init.d
sed -e '4a  # chkconfig:   2345 90 10' -i redis_6379
sed -e '5a  # description:  Redis is a persistent key-value database' -i redis_6379
chkconfig redis_6379 on

配置文件修改

  • worker-01

      # 本机的 IP 地址,默认的只能本地访问
      bind worker-1
      # 持久化数据目录
      dir  /var/redis/6379
      # 后台运行
      daemonize yes
    
  • worker-02 配置

      # 本机的 IP 地址,默认的只能本地访问
      bind worker-2
      # 持久化数据目录
      dir  /var/redis/6379
      # 后台运行
      daemonize yes
      # 主节点地址和端口
      replicaof worker-01 6379
      # 只读
      replica-read-only yes
    
  • worker-03 配置
      # 本机的 IP 地址,默认的只能本地访问
      bind worker-3
      # 持久化数据目录
      dir  /var/redis/6379
      # 后台运行
      daemonize yes
      # 主节点地址和端口
      replicaof worker-01 6379
      # 只读
      replica-read-only yes
    

    启动

分别启动 三个服务器,先启动 主节点,再启动 从节点。

启动命令:

sh /etc/init.d/redis-6379 start

测试

主节点服务器 worker-01 上新增一个key。

[root@localhost shell]# redis-cli -h worker-01
worker-01:6379> set key1 value1
OK
worker-01:6379> get key1
"value1"
worker-01:6379>

从节点可以看到已经同步过来了。

[root@localhost init.d]# redis-cli -h worker-02
worker-02:6379> get key1
"value1"
worker-02:6379> 

测试成功。

Redis 压测

通过执行 redis 目录下的 src/redis-benchmark,可以测本机的Redis 服务进行压测。其会对各种 redis 的操作进行压测,通过这个就可以大概知道服务器的性能如何。下面是部分的压测结果:

====== SET ======
  100000 requests completed in 1.47 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

97.80% <= 1 milliseconds
99.89% <= 2 milliseconds
100.00% <= 2 milliseconds
68212.83 requests per second

====== GET ======
  100000 requests completed in 1.40 seconds
  50 parallel clients
  3 bytes payload
  keep alive: 1

98.76% <= 1 milliseconds
99.80% <= 2 milliseconds
99.93% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
71633.23 requests per second

可以知道 redis 的 qps 在 6-7 万左右。需要注意的是:不同操作的 QPS 是不同的,而且差别会很大


   转载规则


《Redis 集群之主从架构原理及安装部署》 孤独如梦 采用 知识共享署名 4.0 国际许可协议 进行许可。
 上一篇
【dubbo系列】 12-Dubbo 服务导出 【dubbo系列】 12-Dubbo 服务导出
前言Dubbo 服务导出过程始于 Spring 容器发布刷新事件,Dubbo 收到事件后,会立即执行导出逻辑。整个逻辑大概可以分成三个部分:每一部分是前置工作,主要用于检查参数和组装URL。第二部分是导出服务,包含导出到本地(JVM),和导
2019-07-17
下一篇 
【Elasticsearch 系列】 Elasticsearch 7.2.0 集群部署 【Elasticsearch 系列】 Elasticsearch 7.2.0 集群部署
准备这里用三台服务器作为演示部署 ES 集群,三台服务器的 IP 映射关系为: 192.168.56.101 worker-01 worker-01.joyxj.com 192.168.56.102 worker-02
2019-07-15
  目录