Redis集群的负载均衡

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

概述

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

常见的集群解决方案

读写分离复制集群

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

• 架构图： 例如下图，一个简单的读写分离集群模型。
  

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

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

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

使用数据分片方案

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

源程序实现

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

Redis-Cluster

• 概述： Redis-Cluster是在Redis3.0后推出的官方集群方案。它的实现负载均衡的原理本质上也是通过对槽位的分配。
• 设计结构： Redis-Cluster采用的是一种无中心结构，每个节点保存对应槽位的数据和整个集群的状态，并且每个节点和其他所有节点连接。使用时并不需要代理层，直接连接任意一个集群节点就可以和整个集群通信了。
  
• 高可用： 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的优势在于可以不停机动态增加或者删除节点，并提供了图像化的管理界面！