1、架构演变
![190927zxhiihgex9om0svi.png]()
在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存储节点。
![190927xz6j65kl8kjelzhh.png]()
这是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的架构如下：
![190927m7caoc5khunls60u.jpg]()
图上只有master节点（slave略去），所有节点构成一个完全图,slave节点在集群中与master只有角色和功能的区别。
架构演变讲完了,开始讲第三部分，也是大家最感兴趣的一部分。
本文作者：geelou
本文来自云栖社区合作伙伴rediscn，了解相关信息可以关注redis.cn网站。
