为什么要使用Redis集群
基于内存大小
Redis是一个内存数据库,也就是说存储数据的容量不能超过主机内存大小。普通主机服务器的内存一般几十G,但是我们需要存储大容量的数据(比如上百G的数据)怎么办?基于访问吞吐量
Redis是基于内存处理,速度非常快,但是人的欲望是永无止境的,如果因为业务需要更快的处理,怎么办?
。。。
来,我们一起学集群之主从模式
主从复制实现
架构图:
特点:
1、Master会将数据同步到slave,而slave不会将数据同步到master。Slave启动时会连接master来同步数据,Master数据变更时会将数据同步刷新到Slave
2、典型的分布式读写分离模型。我们可以利用master来处理写操作,slave提供读操作。这样可以有效减少单个机器的并发访问数量
实现过程:
- 准备三台Redis服务器:
192.168.223.128 6379 master
192.168.223.129 6379 slave
192.168.223.130 6379 slave
实现主从复制这种模式非常简单,主节点不用做任何修改,直接启动服务即可。从节点需要修改redis.conf配置文件,加入配置:slaveof <主节点ip地址> <主节点端口号>,例如master的ip地址为192.168.223.128,端口号为6379,那么slave只需要在redis.conf文件中配置slaveof 192.168.223.1286379即可。
slaveof 192.168.223.128 6379
分别连接主节点和从节点,测试发现主节点的写操作,从节点立刻就能看到相同的数据。但是在从节点进行写操作,提示 READONLY You can’t write against a read only slave 不能写数据到从节点。我们就可以通过这种方式配置多个从节点进行读操作,主节点进行写操作,实现读写分离。
主从复制原理
学一个新技术,不但要学如何用,更要知其所以。。。
执行流程
下面来看一下执行一下过程
开启master/slave的日志:
cd /usr/local/redis-4.0.6
tail -f log/redis.log
保存主节点信息:
主节点128打印日志如下:
- 主节点接受主从复制连接请求,同意建立主slave从同步连接
从节点129/130打印日志如下:
- 从节点保存主节点信息:
建立socket连接
主从建立socket连接
如果从节点无法建立连接,定时任务会无限重试直到连接成功或者执行 slaveof no one 取消复制 连接
发送ping命令
发送首次ping命令,如果能接受主节点的pong回复,复制可以继续;如果不能,继续重连:
同步数据集
主从复制连接正常通信后,对于首次建立复制的场景,主节点会把持有的数据全部发送给从节点,这部分操作是耗时最长的步骤 ,因为所有数据包括持久化的RBD和AOF数据
维持心跳检测
命令持续复制
问题思考
在主从复制这种模式下只有一个主节点,一旦主节点宕机,就无法再进行写操作了。也就是说主从复制这种模式并没有实现高可用!
高可用(HA)是分布式系统架构设计中必须考虑的因素之一,它是通过架构设计减少系统不能提供服务的时间。保证高可用通常遵循下面几点:
- 单点是系统高可用的大敌,应该尽量在系统设计的过程中避免单点。
- 通过架构设计而保证系统高可用的,其核心准则是:冗余。
- 实现自动故障转移。