[bigdata-57] redis集群方案+监控+内存复制

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集群搭建性能测试监控工具的文档 https://my.oschina.net/pwd/blog/381212