1. redis在3.0之前只支持单实例，内存可以到100G~1T级别。

2. 在没有集群之前，各家的解决方案是，把数据分片sharding存储在多个redis实例，每个片是一个redis实例。

3. 集群方案1--客户端分片
    3.1 分片逻辑在redis客户端实现。redis客户端按照预先定义好的路由规则，把对key的访问转发到不同的redis实例，最后把返回结果汇集。
    3.2 优点：所有逻辑是可控的，不依赖第三方。
    3.3 缺点：这是静态方案，如果需要动态增加或者减少redis实例，需要手工调整分片逻辑; 运维有痛点，出了问题，需要运维和开发一起解决; 不用业务系统比如java和php，需要分别实现同一套分片逻辑。

4. 集群方案2--twemproxy
    4.1 这是twitter开源的redis代理。
    4.2 redis客户端把请求发送到twemproxy，twemproxy根据路由规则发送到正确的redis实例，然后twemprxoy把结果汇集到redis客户端。
    4.3 优点：客户端不需要修改任何代码逻辑，象操作单实例一样操作集群，自动删除无效redis实例。
    4.4 缺点：客户端需要经过twemproxy代理，性能有损失; 监控管理界面没有; twemproxy无法平滑增加redis实例--这是最大的问题，不方便运维。


5. 集群方案3--codis
    5.1 codis能支持平滑增加redis实例。
    5.2 codis有四个部分：proxy， codis分支redis， codisconfig，zookeeper。
    5.3 codis实现了一个特定的redis分支，且codis只使用这个分支搭建集群。
    5.4 用zookeeper做同步服务。
    5.5 用redis server group做主动备份实现高可用性，如果主codois挂掉了，需要手工启动一个从codis提供服务，但它没有解决一致性问题，主从以异步复制做一致性，不能保证主codis和从codis数据一致，所以必需手工。
 
6. 集群方案4-redis3集群
    6.1 完全去中心化，所有key分成16384个slot，每个redis负责一个slot。所有的节点端口slot信息通过节点点定期数据交换更新。
    6.2 每个节点保存数据和整个集群状态，每个节点都和其他所有节点连接
    6.3 节点之间使用gossip协议传播信息以及发现新节点
    6.4 每个redis物理节点负责一部分桶的管理，当redis节点增减时，调整桶的分布既可
    6.5 每个redis node可以有一个或者多个slave，当master挂掉，选举一个slave形成新的master。一个redis node包涵一定量的桶，当这些桶对应的master和slave都挂掉时，这部分桶对应的数据不可用。
    6.6 redis cluster异步复制：slave写数据到master，master告诉slave ok; master再更写道slave。如果第3步master崩溃，则数据不能传播到其他slave。或者由于分区，导致有两个master。都会出错。
    6.7 优点：部署简单，不需要各种类似codis的组件。
    6.8 缺点：但无法对业务进行无痛升级，也无法做主从备份; 对redis协议进行了较多修改，无法跟以前的业务进行兼容。

7. 集群方案5-阿里云和ucloud上都有集群服务
    7.1 数据多备，一主一备。
    7.2 自动容灾
    7.3 实惠

8. redis的复制机制
    8.1 master/slave模式的redis集群，有复制功能。
    8.2 复制功能建立在基于内存快照的持久化策略之上。
    8.3 master和salve各有一套状态机流转。
    8.4 整个状态机流程如下：
        8.4.1 slave配置了slave on命令，slave启动时读取配置文件，初始状态是REDIS_REPL_CONNECT
        8.4.2 slave端在定时任务serverCron中连接master，发送sync命令，然后阻塞等待master发送其内存快照文件。
        8.4.3 master收到sync命令，将内存快照发送给slave端
        8.4.4 slave收到内存快照文件，存到本地，接收完成后，清空内存表，根据内存快照文件重建内存表数据结构，设置最终状态为REDIS_REPL_CONNECTED，slave流转完成。
        8.4.5 master端在发送快照文件过程中，接受的任何改变数据集的命令都会缓存在slave网络连接的发送缓存队列里，快照完成后，依次发送给slave，之后收到的命令也同样处理，并将状态位置为REDIS_REPL_ONLINE。
    8.5 缺点：slave恢复的时间很慢，事先配置全部全部从库，避免中途增加从库。
    8.6 如果是做cache，最好使用memcached更合适。如果是做storage，一台redis挂掉，没法快速恢复，几十个g持久话数据，redis重启要几个小时，慢。
    8.7 主动复制解决单点故障：gizzard是twitter的主动复制和分区中间件。如果对数据一致性算法要求非常高，可以使用paxos保证一致性。
    8.8 redis作者提出的presharding方式在线扩容
        8.8.1 在一个机器上部署多个redis实例，当容量不够时将多个实例分拆到不同机器上，由此扩容。
        8.8.2 在新机器上启动好对应端口的redis实例
        8.8.3 配置新端口为待迁移端口的从库
        8.8.4 待复制完成，与主库同步，切换所有客户端配置到新的从库的端口
        8.8.5 配置从库为新的主库
        8.8.6 移除老的端口实例
        8.8.7 重复上述过程迁移好所有的端口到指定服务器上
        8.8.8 要在业务访问低峰时段进行


9. infoq报道过 优酷蓝鲸的700+节点redis集群遇到的问题。

10. 这里有一个完整的redis集群搭建性能测试监控工具的文档