2同行回答
常用的有三种，rediscluster、twemproxy、codis
第一种是redis原生的集群，平滑水平扩容比较容易，后两种缓存服务代理
twemproxy特点：1.通过代理的方式减少缓存服务器的连接数。
2.自动在多台缓存服务器间共享数据。
3.通过不同的策略与散列函数支持一致性散列。4.通过配置的方式禁用失败的结点。
5.运行在多个实例上，客户端可以连接到首个可用的代理服务器。
6.支持请求的流式与批处理，因而能够降低来回的消耗。
codis特点：1.Codis是一整套缓存解决方案，包含高可用、数据分片、监控、动态扩态 etc.。走的是 Apps->代理->redis cluster，一定规模后基本都采用这种方式。
2.Codis引入了Group的概念，每个Group包括1个Redis Master及至少1个Redis Slave，这是和Twemproxy的区别之一。这样做的好处是，如果当前Master有问题，则运维人员可通过Dashboard“自助式”切换到Slave，而不需要小心翼翼地修改程序配置文件。
3.为支持数据热迁移（Auto Rebalance），出品方修改了Redis Server源码，并称之为Codis Server。
4.Codis采用预先分片（Pre-Sharding）机制，事先规定好了，分成1024个slots（也就是说，最多能支持后端1024个Codis Server），这些路由信息保存在ZooKeeper中。
5.Codis仅负责维护当前Redis Server列表，由运维人员自己去保证主从数据的一致性。
rediscluster特点：1.无中心架构。
2.数据按照slot存储分布在多个节点，节点间数据共享，可动态调整数据分布。
3.可扩展性，可线性扩展到1000个节点，节点可动态添加或删除。
4.高可用性，部分节点不可用时，集群仍可用。通过增加Slave做standby数据副本，能够实现故障自动failover，节点之间通过gossip协议交换状态信息，用投票机制完成Slave到Master的角色提升。
5.降低运维成本，提高系统的扩展性和可用性。”
推荐两种：
一、Twemproxy：
Twemproxy是Twitter开源的redis集群架构，但是，目前Twitter 内部已放弃使用该方案，新使用的架构未开源。很多互联网公司以twemproxy为基础，开发出自己需要的功能属性。
架构图如下：
多个同构 Twemproxy（配置相同）同时工作，接受客户端的请求，根据 hash 算法，转发给对应的 Redis。
Twemproxy 方案比较成熟了，但是有两个主要缺点：一方面是定位问题比较困难，另一方面是它对自动剔除节点的支持不是很友好。
二、redis cluster：
redis官方推出的无中心的集群架构。
架构图：
每个节点要打开两个TCP端口，分别是：
1、TCP命令端口：
正常服务端口，为客户端提供服务，存储键值数据、查询数据。
2、集群端口（TCP命令端口+ 10000）：
集群节点间通过gossip协议进行通信，将交换的信息封装在gossip消息中。
每个节点在固定的时间周期内（每秒执行10次）选择几个节点发送ping消息。接收ping消息的节点用pong消息作为响应。
为了保证Redis命令端口的正常使用，请确保在防火墙中打开这两个端口，否则Redis群集节点将无法通信。
缺点：
redis集群对客户端通信协议进行了大的修改，为了追求性能，没有采用代理形式，而是采用客户端直连节点的形式，因此需要客户端修改代码。
集群模式下，redis节点收到任何命令，先计算键对应的槽，如果在自身节点上，则处理命令；如果不在，则返回moved错误，通知客户端请求正确的节点。收起