Redis架构多种多样，常见的架构有以下几种，根据不同的业务需求，可以选择不同的架构模式。

单节点（Single）

优点

• 架构简单，部署方便
• 高性能
• 高性价比：缓存使用时无需备用节点(单实例可用性可以用 supervisor 或 crontab 保证)，当然为了满足业务的高可用性，也可以牺牲一个备用节点，但同时刻只有一个实例对外提供服务

缺点

• 不保证数据的可靠性
• 在缓存使用，进程重启后，数据丢失，即使有备用的节点解决高可用性，但是仍然不能解决缓存预热问题，因此不适用于数据可靠性要求高的业务
• 高性能受限于单核CPU的处理能力(Redis是单线程机制)，CPU为主要瓶颈，所以适合操作命令简单，排序/计算较少场景

主从复制（Replication）

主从复制模式中包含一个主数据库实例（Master）与一个或多个从数据库实例（Slave），如下图：

优点

• Master能够自动将数据同步到Slave，可以进行读写分离以减轻Master的读压力
• Master与Salve之间数据同步是非阻塞的，同步期间不影响客户端的读写操作

缺点

• 没有自动容错恢复的能力，Master或者Slave宕机都可能导致客户端请求失败
• 数据不一致问题，如果在Master数据同步还没完成前发生宕机，切换到从库则会丢数据
• 很难做到在线扩容，集群总容量受到单机限制

哨兵模式（Sentinel）

优点

• 该模式基于主从模式，因此该模式继承了主从模式的所有优点
• 解决了主从模式的可用性问题，Master宕机哨兵可以自动发现恢复

缺点

• 该模式仍然没有解决数据一致性问题和容量问题
• Sentinel需要格外的资源及管理，也导致Slave只能作为备份而不提供服务

集群模式（Cluster）

Redis集群采用了无中心节点的架构模式，无须proxy，客户端直接与Redis集群每个节点相连，跟进key的hash结果路由到指定的Solt对应的Redis节点操作数据。

优点

• 性能要优于Proxy模式
• 自动故障转义，Slot迁移期间数据可用
• Redis官方提供的原生集群解决方案，可靠性、支持力度有保障

缺点

• 该模式仍然没有解决数据一致性问题和容量问题
• Sentinel需要格外的资源及管理，也导致Slave只能作为备份而不提供服务
• 客户端需要存储集群的路由表

分片模式（Sharding）-客户端分片

客户端分片是把分片的逻辑放在Redis客户端实现，（比如：jedis已支持Redis Sharding功能，即ShardedJedis），通过Redis客户端预先定义好的路由规则(使用一致性哈希)，把对Key的访问转发到不同的Redis实例中，查询数据时把返回结果汇集。这种方案的模式如图所示：

优点

• 客户端sharding技术使用hash一致性算法分片的好处是所有的逻辑都是可控的，不依赖于第三方分布式中间件。
• 服务端的Redis实例彼此独立，相互无关联，每个Redis实例像单服务器一样运行，非常容易线性扩展，系统的灵活性很强。
• 对用户透明，清楚怎么实现分片、路由的规则，易用性更高。

缺点

• 这是一种静态的分片方案，需要增加或者减少Redis实例的数量，需要手工调整分片的程序。
• 运维成本比较高，集群的数据出了任何问题都需要运维人员和开发人员一起合作，减缓了解决问题的速度，增加了沟通的成本。
• 在不同的客户端程序中，维护相同的路由分片逻辑成本巨大。比如：java项目、PHP项目里共用一套Redis集群，路由分片逻辑分别需要写两套一样的逻辑，以后维护也是两套。

分片模式（Sharding）-代理分片

Redis代理分片基本原理是：通过中间件的形式，Redis客户端把请求发送到Proxy，Proxy根据路由规则发送到正确的Redis实例，最后Proxy把结果汇集返回给客户端。Proxy通过引入一个代理层，将多个Redis实例进行统一管理，使Redis客户端只需要在Proxy上进行操作，而不需要关心后面有多少个Redis实例，从而实现了Redis集群。

优点

• 客户端像连接Redis单实例一样连接Proxy，不需要改任何的代码逻辑。
• 支持无效Redis实例的自动删除。
• Proxy与Redis实例保持连接，减少了客户端与Redis实例的连接数。

缺点

• 由于Redis客户端的每个请求都经过Proxy代理才能到达Redis服务器，这个过程中会产生性能损失。
• 没有友好的监控管理后台界面，不利于运维监控。
• Proxy最大的痛点在于，无法平滑地扩容/缩容。对于运维人员来说，当因为业务需要增加Redis实例时工作量非常大。
• 对多跨分片操作的命令不能完美支持，比如key查询、EVAL命令等。

分片模式（Sharding）-Codis

Proxy Sharding模式最大的问题在于无法平滑的扩容/缩容，于是豌豆荚自主研发了Codis，一个支持平滑增加Redis实例的Redis代理软件，其基于Go和C语言开发

具体详见：https://github.com/CodisLabs/codis

以上就是Redis常见架构介绍，如果各位还想了解更多，欢迎评论+关注，Redis图解系列专栏持续更新中。