单机版redis容量有限,且能支持的qps也有限。为了应对大量数据，需要提供集群版的redis方案

方案有：

1. 代理，如 Twemproxy, Codis等。twemproxy在redis的client和server之间引入了一个代理层，代理层通过路由规则打到正确的redis实例上。相当于一个网关的存在。

优点是 redis的client对这个架构不会有任何的感知，不需要任务的修改。网关和redis实例保持链接，降低了redis实例的链接数。并且能支持比较大的集群数量。缺点是节点迁移的运维工作量大，且经过一层网关，有性能损耗。

1. Redis Cluster。官方提供的redis集群解决方案，一种去中心化的方案，每一个分区都是一主多从的架构，每一个节点负责维护一部分slot，slot存真正的key值。每个节点之间通过gossip协议交换信息，每个节点都存了所有的槽信息。

优点是官方推荐的，并且节点的迁移运维工作量不大。缺点是客户端需要做改造，改成smart-client，大致原理是client也存一份所有槽的信息，在client做hash分片，打到节点上。如果正确就直接取数据，如果不正确就move到对应节点上并拉一次槽数据。并且由于redis cluster使用了gossip这种去中心化协议，其节点规模受限。且client直接链接server，server的链接数比较多。

快手和字节都没有采取官方推荐的cluster，都是基于代理方案实现的