Redis集群架构模式概述，引领我们穿越在数据存储的未知之旅

redis，不仅是数据存储，更是架构的艺术。从主从到哨兵、再到Cluster，每个模式都有着独特的优势。而代理模式，则是应对大规模场景的得力助手。这是一场探险，Redis引领我们穿越在数据存储的未知之旅。本文先简略介绍Redis的几种架构模式，后续合集再逐一进行详细介绍部署、使用及原理。

一、主从模式

1、简介

主从模式是Redis架构中最简单的模式之一，分为主数据库master和从数据库slave两类,主要特点如下：

• 主数据库支持读写操作，数据变化时自动同步给从数据库。
• 从数据库通常为只读，接收主数据库同步的数据。
• 一个主数据库可以拥有多个从数据库，但一个从数据库只能对应一个主数据库。
• 从数据库宕机不影响其他从数据库和主数据库的读操作，重新启动后同步数据。
• 主数据库宕机不影响从数据库的读，但Redis不再提供写服务，重启后重新提供写服务。
• 主数据库宕机后，不会在从数据库中重新选取主数据库。

2、工作机制

当从数据库启动时，主动向主数据库发送SYNC命令。主数据库接收SYNC命令后，在后台保存快照（RDB持久化）和缓存保存快照期间的命令，然后将保存的快照文件和缓存的命令发送给从数据库。从数据库收到后加载快照文件和执行缓存的命令。复制初始化后，主数据库每次收到写命令都会同步发送给从数据库，确保主从数据一致性。

缺点： 主节点唯一，主节点宕机导致Redis无法提供写服务。

二、哨兵模式

1、简介

哨兵模式解决主从模式的单点故障问题，通过监控Redis集群状态实现高可用性：

• Sentinel模式建立在主从模式基础上。
• 当主节点宕机，Sentinel选择一个从节点作为新主节点，修改配置文件。
• 主节点重新启动后成为从节点。
• Sentinel形成集群，相互监控，防止单点故障。
• Sentinel不与Redis部署在同一台机器，以防Redis服务器宕机导致Sentinel也宕机。

2、工作机制

• 每个Sentinel每秒向所知的主、从和其他Sentinel实例发送PING命令。
• 如果实例距离上次有效回复PING超过设定时间，则被标记为主观下线。
• 当主观下线后，所有Sentinel每秒确认一次，满足条件则标记为客观下线。
• Sentinel以10秒一次的频率向已知的所有主、从发送INFO命令。
• 主被标记为客观下线后，向下线主的从发送INFO命令频率提高。
• 若没有足够Sentinel同意主已下线，客观下线状态移除。
• 若主重新响应PING，主观下线状态移除。

3、注意

客户端不直接连接Redis，连接Sentinel的IP和端口，由Sentinel提供可用Redis实例。避免主节点宕机时Sentinel感知并提供新主节点。

三、Cluster模式

1、简介

哨兵模式基本可以满足一般生产的需求，具备高可用性。但是当数据量过大到一台服务器存不下的情况时，主从模式或sentinel模式就不能满足需求了，这个时候需要对存储的数据进行分片，将数据存储到多个Redis实力中，cluster模式的出现就是为了解决单机Redis容量有限的问题，将Redis的数据根据一定的规则分配到多台机器。

2、工作机制

cluster可以说是sentinal和主从模式的结合体，通过cluster可以实现主从和master重选功能，所以如果配置两个副本三个分片的话，就需要六个Redis实例。因为Redis的数据是根据一定规则分配到cluster的不同机器的，当数据量过大时，可以新增机器进行扩容。
使用集群，只要将redis配置文件中的cluster-enable配置打开即可。每个集群中至少需要3个主数据库才能正常运行，新增节点非常方便。

3、cluster集群优点

• 多个Redis节点网络互联，数据共享
• 所有节点一主一从，支持在线增加、删除节点

4、cluster集群缺点

• 不支持同时处理多个key（如MSET/MGET），因为redis需要把key均匀分布在各个节点上，
• 并发量很高的情况下同时创建key-value会降低性能并导致不可预测的行为

四、代理模式

目前比较流行的代理框架如下 ：

• twemproxy：快速、轻量级memcached和redis代理，Twitter推特公司开发
• codis：redis集群代理解决方案，豌豆荚公司开发，需要修改redis源码
• predixy：高性能全特征redis代理，支持Redis Sentinel和Redis Cluster
• Redis-cerberus: Redis Cluster代理

对比：

1、Twemproxy

（1）工作机制

Twemproxy是一种代理分片机制，由Twitter开源。Twemproxy作为代理，可接受来自多个程序的访问，按照路由规则，转发给后台的各个Redis服务器，再原路返回。该方案很好的解决了单个Redis实例承载能力的问题。通过Twemproxy可以使用多台服务器来水平扩张redis服务，可以有效的避免单点故障问题。

（2）缺点

• Twemproxy本身也是单点（需要用Keepalived做高可用方案）
• 使用Twemproxy需要更多的硬件资源和在redis性能有一定的损失（twitter测试约20%）

（3）不支持的命令

见https://Github.com/twitter/twemproxy/blob/master/notes/redis.md。

2、Codis

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

（1）工作机制

Codis包含如下组件

• Codis Proxy (codis-proxy)
• Codis Manager (codis-config)
• Codis Redis (codis-server)
• ZooKeeper

• codis-proxy：无缝连接的Redis代理服务
  客户端连接的Redis代理服务，实现了Redis协议，表现与原生Redis几乎无差异（类似Twemproxy）。
  业务可部署多个codis-proxy，这些代理是无状态的。
• codis-config：Codis的智能管理工具
  作为Codis的管理工具，支持诸如添加/删除Redis节点、添加/删除Proxy节点、发起数据迁移等操作。
  内置HTTP服务器，启动一个Dashboard，用户可通过浏览器实时观察Codis集群的运行状态。
• codis-server：Codis项目的特制Redis分支
  基于Redis 2.8.13开发，加入了对slot的支持和原子的数据迁移指令。
  Codis的上层组件codis-proxy和codis-config只能与这个特定版本的Redis交互才能正常运行。
• Codis项目依赖ZooKeeper存储数据路由表和codis-proxy节点的元信息。通过ZooKeeper，codis-config发起的命令能够同步到所有存活的codis-proxy，确保集群的协同工作。
• Codis不仅仅是一个扩展，更是智能的扩展。它支持按照Namespace区分不同的产品，每个产品拥有独特的product name，配置互不冲突。Codis让Redis的扩展变得轻松而智能

（2）优点

Codis项目为Redis提供了智能而强大的扩展功能，其显著特点如下：

• 自动平衡：Codis自动平衡数据，确保每个节点负载均衡，提升系统性能。
• 简单易用：使用起来非常简单，无需繁琐的配置，即可享受Codis的强大功能。
• 图形化面板和管理工具：Codis提供直观的图形化面板和管理工具，使集群管理变得轻松而高效。
• 支持绝大多数Redis命令：完全兼容twemproxy，支持Redis丰富的命令集，确保平滑迁移。
• Redis原生客户端支持：与Redis原生客户端完美兼容，保障业务的稳定连接。
• 安全透明的数据移植：数据移植安全可靠，轻松添加或删除节点，保持数据的稳定迁移。
• 命令行接口：提供命令行接口，方便开发人员进行更精细的操作和管理。
• RESTful API：强大的RESTful API，使开发者能够灵活地进行集群管理，提升整体运维效率。

（3）不支持的命令

KEYS, MOVE, OBJECT, RENAME, RENAMENX, SORT, SCAN, BITOP,MSETNX, BLPOP, BRPOP,
 BRPOPLPUSH, PSUBSCRIBE，PUBLISH, PUNSUBSCRIBE, SUBSCRIBE, UNSUBSCRIBE, 
DISCARD, EXEC, MULTI, UNWATCH, WATCH, SCRIPT EXISTS, SCRIPT FLUSH, 
SCRIPT KILL, SCRIPT LOAD, AUTH, ECHO, SELECT, BGREWRITEAOF, BGSAVE, 
CLIENT KILL, CLIENT LIST, CONFIG GET, CONFIG SET, CONFIG RESETSTAT, 
DBSIZE, DEBUG OBJECT, DEBUG SEGFAULT, FLUSHALL, FLUSHDB, INFO, LASTSAVE,
 MONITOR, SAVE, SHUTDOWN, SLAVEOF, SLOWLOG, SYNC, TIME

详情请参考：https://github.com/CodisLabs/codis
https://github.com/CodisLabs/codis/blob/master/doc/tutorial_zh.md。

3、predixy

在Redis3.0版本引入RedisCluster之前，代理层是实现Redis集群的首选方案。其中，Twemproxy和Codis是两个常见的代理工具。然而，Twemproxy存在一些限制，如不支持阻塞命令、事务、发布订阅等，且没有直接支持Redis高可用。之后有了 redis cluster后，Predixy是比较靠谱的代理方案。

（1）Predixy工作机制

Predixy是一个强大的代理工具，同时支持Redis Sentinel和Redis Cluster：

• 后端为Redis Sentinel监控的一组Redis，功能与原始Redis完全相同。
• 后端为Redis Sentinel监控的多组Redis，部分功能受限。
• 后端为Redis Cluster，功能与Redis Cluster相同。

（2）Predixy特点

Predixy拥有多项特点，使其成为强大而灵活的代理工具，主要特点如下：

• 高性能且轻量级。
• 支持多线程。
• 跨平台支持：linux、OSX、BSD、windows。
• 兼容Redis Sentinel，可配置一组或多组Redis。
• 兼容Redis Cluster。
• 支持阻塞型命令（blpop、brpop、brpoplpush）。
• 支持scan命令，无论是单个Redis还是多个Redis实例。
• 多key命令支持：mset/msetnx/mget/del/unlink/touch/exists。
• 支持Redis的多数据库，即可以使用select命令。
• 事务支持，目前仅限于Redis Sentinel下单一Redis组可用。
• 脚本支持，包括命令：script load、eval、evalsha。
• 支持发布订阅机制，即Pub/Sub系列命令。
• 多数据中心支持，读写分离。
• 扩展的AUTH命令，强大的权限控制和键空间限制。
• 日志可按级别采样输出，异步日志记录避免线程被io阻塞
• 日志文件可以按时间、大小自动切分。
• 丰富的统计信息，包括CPU、内存、请求、响应等。
• 延迟监控信息，可查看整体延迟以及后端Redis实例的延迟。
• Predixy的全面特性使其成为一个强大的选择，为Redis集群提供了广泛的支持和灵活的管理

五、小结

本期为概述内容，参考多个文档并修改其中错误内容，后续具体各架构详情将在合集中详细演示。