Redis的集群模式:主从 & 哨兵 & 分片集群

  • 基于Redis集群解决单机Redis存在的问题,在之前学Redis一直都是单节点部署

单机或单节点Redis存在的四大问题:

Redis的集群模式:主从 & 哨兵 & 分片集群_第1张图片

  • 数据丢失问题:Redis是内存存储,服务重启可能会丢失数据  =>  利用Redis数据持久化的功能将数据写入磁盘
  • 并发能力问题:单节点Redis并发能力虽然不错,但也无法满足如618这样的高并发场景  =>  搭建一主多从集群,实现读写分离
  • 单点故障 - 故障恢复问题:如果Redis宕机,则服务不可用,需要一种自动的故障恢复手段  =>  利用Redis哨兵,实现健康检测和自动故障恢复
  • 存储能力问题:Redis基于内存存储,单节点能存储的数据量难以满足海量数据要求  =>  搭建分片集群,利用插槽机制实现动态扩容,从理论上来讲,它的存储能力是没有上限的

1. Redis主从

  • 搭建主从架构
  • 主从数据同步原理

单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离。

1.1.主从集群结构

  • Redis的集群往往都是主从集群,它往往会有一个Master主节点,多个Slave / Replica从节点。 

下图就是一个简单的Redis主从集群结构:

Redis的集群模式:主从 & 哨兵 & 分片集群_第2张图片

如图所示,集群中有一个Master主节点、两个Slave从节点(现在叫Replica) =>  起码要包含三个节点,要有三个Redis实例,一主两从

  • 在Redis 5.0以前,从节点是叫Slave的,后来改名叫Replica  =>  都是代表从节点 

当我们通过Redis的Java客户端访问主从集群时,应该做好路由:

  • 如果是写操作,应该访问Master主节点,Master主节点会自动将数据同步给两个Slave从节点

  • 如果是读操作,建议访问各个Slave从节点,从而分担并发压力

Master主节点可以执行set命令(写操作),Replica从节点只能执行get命令(读操作) 。

为什么Redis要做成这种主从的集群,而不是传统的负载均衡集群呢?

  • 这是因为Redis应用当中大多数都是读多写少的场景,也就是查询比较多,而增删改比较少,既然如此,我们更多要应对的是读的压力,那我做了主从以后,我们还可以去做读写分离, 也就是说,我在执行写操作时,我让它去访问Master主节点,但如果执行的是读操作,那我就把你的请求分发到各个Slave或Replica从节点,这样我们一主多从,多个从节点共同承担读的请求,我们的读并发能力就可以得到一个比较大的提升,所以这就是为什么要搭建主从集群的一个原因了。
  • 但是做主从集群,必须保证一点,就是客户端在读取的时候,不管访问到哪个Slave从节点,都必须要保证拿到相同的结果     =>    如何保证?  需要让Master主节点把它上面的数据同步给每一个Slave从节点,这就是Redis主从架构的一个基本模式了

1.2 搭建主从集群 

1. 准备实例和配置  
  • 我们会在同一台虚拟机中开启3个Redis实例,模拟主从集群。  
  • 我们会在同一个虚拟机中利用3个Docker容器来搭建主从集群。

  • 要在同一台虚拟机开启3个实例,必须准备三份不同的配置文件和目录,配置文件所在目录也就是工作目录。

  • 在同一个机器下还要修改每个实例的端口

2. 启动 & 开启主从关系

分别启动多个Redis实例虽然我们启动了3个Redis实例,但是它们并没有形成主从关系,我们需要通过命令来配置主从关系:

# Redis5.0以前
slaveof  
# Redis5.0以后
replicaof  
有临时和永久两种模式:
  • 永久生效:在redis.conf文件中利用slaveof命令指定Master主节点的IP和端口

  • 临时生效:直接利用redis-cli控制台输入slaveof命令,指定Master主节点的IP和端口

INFO replication:查看集群的状态信息

这样,就可以实现读写分离了,如果在Slave从节点上执行set写操作,会报错:

假设有A、B两个Redis实例,如何让B作为A的Slave从节点?

  • 在B节点执行命令:slaveof       A的IP     A的Port端口 

1.3 数据同步原理 

 

你可能感兴趣的:(缓存,分布式,redis)