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主要功能：
- 负责整个系统元信息的管理，比如cluster、shard、redis、keeper
- DR切换，提供操作界面和API执行DR切换功能
- 整个系统监控、报警
Keeper主要实现Redis协议，向Redis Master请求数据，并且将数据传播至Slave，用于用磁盘缓存redis复制日志以及RDB数据。
如果本地数据文件可用，Keeper会尽量复用本地的RDB和日志数据，避免向Redis Master请求RDB，可以保持Redis Master的稳定性。
Keeper Container是Keeper的容器，主要提供增加、查询、删除keeper等功能。一个Keeper Container内部可以放置多个Keeper
Meta Server主要有两部分功能:
- 和Console交互，抓取在Console配置的Meta信息；当Console配置信息变化时，Meta Server负责执行这部分变化。
- 管理单机房内的所有keeper、Redis的 状态，并对异常状态进行纠正：
- Redis Master变化时，将Active Keeper指向对应Redis Master
- 当Keeper挂掉时，进行Keeper的主从切换
每个机房部署一套zookeeper集群，功能：
- Keeper的Active选举
- Meta Server的Leader选举
Sentinel负责Redis自身的高可用。
Sentinel与Meta Server的关联：
- Sentinel负责Redis的高可用，Meta Server负责Keeper的高可用
- Redis进行了主从切换后， Meta Server会自动调整Keeper的状态，保证Keeper可以正确的连接Redis Master
-
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命令类似