Design
- Redis Master: 主Redis，提供写、读功能
- Redis Slave: 从Redis，只读
- Active keeper: 数据中继层
- Backup keeper: Active keeper 的备份，保证Keeper可用性
- 主机房: 有且仅有一个主机房配置。主机房中应配置有Redis Master一台，Keeper两台以及若干Redis Slave。
- 从机房: 可以有多个从机房配置。从机房中应配置有Keeper两个以及若干Redis Slave。
- Cluster: Redis集群。
- Shard: 一个Cluster下可以有多个shard（分片），每一个shard至少需要包含最小的完整跨机房主从结构
-
Console
Console主要功能- 负责整个系统元信息的管理，比如cluster、shard、redis、keeper。
- DR切换，提供操作界面和API执行DR切换功能
- 整个系统监控、报警
-
Keeper
Keeper主要实现Redis协议，向Redis Master请求数据，并且将数据传播至Slave，用于用磁盘缓存redis复制日志以及RDB数据。
如果本地数据文件可用，Keeper会尽量复用本地的RDB和日志数据，避免向Redis Master请求RDB，可以保持Redis Master的稳定性。
-
Keeper Container
Keeper Container是Keeper的容器，主要提供增加、查询、删除keeper等功能。一个Keeper Container内部可以放置多个Keeper
-
Meta Server
Meta Server主要有两部分功能:
- 和Console交互，抓取在Console配置的Meta信息；当Console配置信息变化时，Meta Server负责执行这部分变化。
- 管理单机房内的所有keeper、Redis的 状态，并对异常状态进行纠正。
- Redis Master变化时，将Active Keeper指向对应Redis Master
- 当Keeper挂掉时，进行Keeper的主从切换
-
Zookeeper
每个机房部署一套zookeeper集群，功能：
- Keeper的Active选举
- Meta Server的Leader选举
-
Keeper active/backup选举
Keeper启动后，会在Zookeeper上注册相应的节点，Meta Server监控Keeper的注册路径，当keeper增加、挂掉时，选举出合适的active角色，保证数据复制的高可用。
-
Keeper变更
用户在Console端配置新的keeper的信息后，Meta Server通过两个渠道获取此变化：
- Console会调用Meta Server的接口，告知Meta Server信息的变化。
- Meta Server定期向Console拉取元信息，和本地元信息进行比较，获取配置变化。
Meta Server获取变化后，,在相应的Keeper Container上增加、删除对应的keeper
-
slot(槽)
Meta Server集群默认有256个槽，每个特定的Cluster会落入某个槽中，每个槽会而且只会被一个Meta Server负责管理。所有Meta Server管理整体256个槽。
-
Meta Server Leader
在多个Meta Server中，会选出特定的Meta Server作为Leader，用来负责整个Meta Server集群的负载均衡以及高可用。如果Leader挂掉，集群会选出另外的Leader作为替代。
-
负载均衡
Leader会定期调整每个Meta Server负责的Slot，保证所有Meta Server之间负载均衡
-
高可用
当某一个Meta Server挂掉后，Meta Server Leader会将其所负责的slots转移到其它Meta server。
- 提供Rest API供Meta Server调用，可以增加、删除Keeper
Keeper实现Redis协议，从Redis Master获取数据，并且将获取的数据复制到Slave。
keeper提供部分redis命令：
- info
和redis的info命令类似，查询当前server服务情况 - psync
和redis的psync命令类似，用于redis从keeper复制数据 - role
和redis的role命令类似