1、架构演变
 

在2014年7月，为了准备当时的814撒娇节大促销活动，我们把单个redis的服务迁移到twemproxy上。twemproxy在后端快速完成数据分片和扩容。为了避免再次扩容，我们静态分配足够多的资源。
之后，twemproxy暴露出来的系统瓶颈很多，资源使用很多，也存在一定的浪费。我们决定用redis cluster取代这种复杂的三层架构。
redis cluster GA之后，我们就开始上线使用。最初是3.0.2 版本，后面大量使用3.0.3 ，上个月开始使用3.0.7版本。
下面简单对比下两种架构，解析下他们的优缺点。

2、Twemproxy架构 优点

• sharding逻辑对开发透明，读写方式和单个redis一致。
• 可以作为cache和storage的proxy（by auto-eject）。

缺点

• 架构复杂，层次多。包括lvs、twemproxy、redis、sentinel和其控制层程序。
• 管理成本和硬件成本很高。
• 2 * 1Gbps 网卡的lvs机器，最大能支撑140万pps。
• 流量高的系统，proxy节点数和redis个数接近。
• Redis层仍然扩容能力差，预分配足够的redis存储节点。

 


这是twemproxy的架构，客户端直接连接最上面的lvs（LB），第二层是同构的twemproxy节点，下面的redis master节点以及热备的slave节点，另外还有独立的sentinel集群和切换控制程序，twemproxy先介绍到这里。

3、Redis Cluster架构 优点

• 无中心 架构。
• 数据按照slot存储分布在多个redis实例上。
• 增加slave做standby数据副本，用于failover，使集群快速恢复。
• 实现故障auto failover。节点之间通过gossip协议交换状态信息；投票机制完成slave到master角色的提升。
• 亦可manual failover，为升级和迁移提供可操作方案。
• 降低硬件成本和运维成本，提高系统的扩展性和可用性。

缺点和不足的地方

• client实现复杂，驱动要求实现smart client，缓存slots mapping信息并及时更新。
• 目前仅JedisCluster相对成熟，异常处理部分还不完善，比如常见的“max redirect exception”。
• 客户端的不成熟，影响应用的稳定性，提高开发难度。
• 节点会因为某些原因发生阻塞(阻塞时间大于clutser-node-timeout），被判断下线。这种failover是没有必要，sentinel也存在这种切换场景。
  cluster的架构如下：

 


图上只有master节点（slave略去），所有节点构成一个完全图,slave节点在集群中与master只有角色和功能的区别。
架构演变讲完了,开始讲第三部分，也是大家最感兴趣的一部分。

本文作者：geelou

本文来自云栖社区合作伙伴rediscn，了解相关信息可以关注redis.cn网站。