Redis集群方案应该怎么做

Z, ZLW • 2023年1月8日上午4:03 • 科技 • 阅读 598

Redis集群方案的做法：1、Redis Cluster集群；2、Redis Sharding集群；3、哨兵模式；4、codis集群；5、主从模式。Redis Cluster集群是一种服务器Sharding技术，3.0版本开始正式提供。

1、Redis Cluster集群

Redis Cluster是Redis的分布式解决方案，在Redis 3.0版本正式推出的，有效解决了Redis分布式方面的需求。当遇到单机内存、并发、流量等瓶颈时，可以采用Cluster架构达到负载均衡的目的。分布式集群首要解决把整个数据集按照分区规则映射到多个节点的问题，即把数据集划分到多个节点上，每个节点负责整个数据的一个子集。Redis Cluster采用哈希分区规则中的虚拟槽分区。虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有的数据映射到一个固定范围内的整数集合，整数定义为槽（slot）。Redis Cluster槽的范围是0 ～ 16383。槽是集群内数据管理和迁移的基本单位。采用大范围的槽的主要目的是为了方便数据的拆分和集群的扩展，每个节点负责一定数量的槽。Redis Cluster采用虚拟槽分区，所有的键根据哈希函数映射到0 ～ 16383，计算公式：slot = CRC16(key)&16383。每一个实节点负责维护一部分槽以及槽所映射的键值数据。

2、Redis Sharding集群

Redis 3.0服务端sharding推出之前，采用的较普遍的client端集群方式，工作逻辑为：将键值对中的key使用hash算法散列，特定的key映射至特定的redis 实例上，然后由client端主动向该node set/get数据，server端则工作在被动模式。目前java redis的客户端驱动jedis已经支持redis sharding的功能。

但是Redis sharding面临的问题：扩容。在client端sharding模式下，数据控制完全由client端掌控，redis集群各node间彼此独立，因此在扩容（或缩容）时，数据无法直接从原node转向新node，这时会造成缓存无法命中的问题，查询/写入请求会透过缓存层直接访问后端DB，给后端带来较大的压力，为了避免这个问题，官方给出了比较讨巧的解决方案：presharding。

3、哨兵模式

哨兵模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来。哨兵模式核心还是主从复制，只不过在相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制：从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。

哨兵模式的作用：监控所有服务器是否正常运行：通过发送命令返回监控服务器的运行状态，处理监控主服务器、从服务器外，哨兵之间也相互监控；故障切换：当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换master。同时那台有问题的旧主也会变为新主的从，也就是说当旧的主即使恢复时，并不会恢复原来的主身份，而是作为新主的一个从。

4、codis集群

codis是一个分布式redis集群解决方案，对于上层的应用来说, 连接到codis-proxy和连接原生的redis-server没有明显的区别。上层应用可以像使用单机的redis一样使用，codis底层会处理请求的转发，不停机的数据迁移等工作。所有后边的一切事情，对于前面的客户端来说是透明的，可以简单的认为后边连接的是一个内存无限大的redis服务。

5、主从模式

redis单节点虽然有通过RDB和AOF持久化机制能将数据持久化到硬盘上，但数据是存储在一台服务器上的，如果服务器出现硬盘故障等问题，会导致数据不可用，而且读写无法分离，读写都在同一台服务器上，请求量大时会出现I/O瓶颈。
为了避免单点故障和读写不分离，Redis 提供了复制（replication）功能实现master数据库中的数据更新后，会自动将更新的数据同步到其他slave数据库上。

延伸阅读