Redis集群的负载均衡

Redis集群的负载均衡

  • 概述
  • 常见的集群解决方案
    • 读写分离复制集群
    • 使用数据分片方案
      • 源程序实现
      • Redis-Cluster
      • Codis

阅读本文之前建议先了解Redis主从复制和哨兵机制

概述

前面介绍了Redis的主从复制和保证高可用的哨兵机制,他们都是搭建Redis集群的基础,当单机Redis无法满足需求时就需要考虑进行水平扩展,本篇就来讲讲Redis集群方案(不介绍搭建流程)。

常见的集群解决方案

读写分离复制集群

  • 概述: 这是最简单的一种集群方案,适合用于读多写少的场景,只需要使用到Redis的主从分离和哨兵即可。

  • 架构图: 例如下图,一个简单的读写分离集群模型。
    Redis集群的负载均衡_第1张图片

  • **实现:**使用这样一个读写分离的集群方案,首先需要搭建主从复制和哨兵监控的Redis集群,需要在应用程序中实现对读和写请求的数据源分配,将写请求分配到master中,读请求均衡地分配给slave,就需要涉及到负载均衡算法以及AOP编程的应用。

  • 优点: ①自由度高,程序可以完全按照实际需求来实现对读写请求的分配机制。②实现方便,安全性高

  • 缺点: 不利于维护,每次增加Redis节点时需要暂停服务,对服务器文件进行修改,重启服务器。

使用数据分片方案

数据分片指的是在Redis集群中为每一台服务器逻辑分配一定数量的槽位,然后按照一定的算法,计算数据存放的槽位,从而达到将数据均匀分散在几台服务器中,达到负载均衡的效果。主流有两种实现方式——Redis官方方案、中间件实现。
Redis集群的负载均衡_第2张图片

源程序实现

  • 概述: 在源程序中实现分片,需要实现计算槽位的算法、实现对Redis服务器的逻辑预分片等。
  • 缺点: 缺点显而易见,维护成本高,增加、删除节点时需要对Redis节点中的数据进行手工迁移(槽位不一致),为了保证一致性还需要将服务下线。

Redis-Cluster

  • 概述: Redis-Cluster是在Redis3.0后推出的官方集群方案。它的实现负载均衡的原理本质上也是通过对槽位的分配。
  • 设计结构: Redis-Cluster采用的是一种无中心结构,每个节点保存对应槽位的数据和整个集群的状态,并且每个节点和其他所有节点连接。使用时并不需要代理层,直接连接任意一个集群节点就可以和整个集群通信了。
    Redis集群的负载均衡_第3张图片
  • 高可用: Redis-Cluster为了保证高可用性要求每一个服务器都至少有一个或多个从服务器,主服务器提供服务,从服务器只保证数据的备份,当主服务器宕机后会自动切换到从服务器,但是如果主从都宕机了那么整个集群将无法正确的提供服务。
  • 搭建方式: 十分简单。
  1. 将每个Redis节点配置文件中的cluster-enabled配置为true。启动redis后通过redis命令行输入info cluster,显示cluster_enabled:1即为启动成功。每个集群至少需要3主3从才能运行。
  2. 使用redis-trib.rb工具启动集群即可。
  • 插槽机制:
  1. 键与插槽:Redis中将键名的有效部分(有{}取{}中的值,没有{}使用整个键)使用CRC16算法计算出散列值,然后取对16384的余数即为这个键的槽位。
  2. 插槽分配:集群中默认的插槽数为16384,每个数据库负责处理一部分插槽。redis-trib.rb工具可以未分配的插槽分给节点,也可以将已经分配的插槽转移到指定节点,同时插槽中的数据也会被转移到指定节点。
  • 获取对应节点: 客户端请求获得指定键的值时只需要向任意集群中的节点发送命令,该节点会判断这个键是否在本节点中,在的话直接获取返回,如果不在则返回给客户端一个重定向命令,并附带存储此键对应的节点的ip、端口、槽位。客户端重新发送请求即可。也可以配置令节点自动转发请求到指定节点处理再返回给客户端。当然这样在一定程度上会影响性能,可以由客户端配置缓存插槽和节点的信息来解决。
参考资料:https://www.cnblogs.com/lykxqhh/p/5690923.html

Codis

这里对Codis不做详细介绍,详细了解可以上它的GitHub:传送门

Codis是豌豆荚团队开源的使用Go语言编写的Redis分布式解决方案,它是作为中间件,以代理的身份接收请求,底层再将请求转发到指定的节点中,Codis的优势在于可以不停机动态增加或者删除节点,并提供了图像化的管理界面!

你可能感兴趣的:(Redis集群的负载均衡)