Update 2016-06
目前想法有改变,现在考虑基于raft + gossip实现类似redis cluster的功能,兼容后续的redis cluster client或者工具。
随着Ardb的Replication实现部分稳定下来,需要开始考虑如何实现集群的方案了。中秋的几天抽空思考了下相关设计,以下是初步设想,可以作为初步设计草案。
目标与约定
- 兼容Redis的client的cluster部分 —— 意味着client端可以直接用redis的各种支持cluster的client实现,而无需单独开发
- 集群节点间复制机制沿用现有异步实现,意味着在主从切换时存在丢数据的可能,这个无法避免;此约束需要特别指明,以防误解
- 此分布式系统应该满足AP限制, 较弱的一致性约束
- 需要支持大于1的备份;
- 每个节点最多只有一个Slave,多备份情况下见后续的slave作为上一slave的slave串行相连
- 数据分库存放 —— 数据按现有的库实现分区存放(和redis的slot实现不同), 支持0到0xFFFFFF, cluster中应该可以限制更小一些,比如16384(redis的取值); 分库存放对后续迁移数据时会比较容易,无需迭代所有底层数据
- 分两部分实现:Cluster Manager以及Node Agent
- 整体基于zookeepr,Cluster Manager用python实现,基于kazoo; Node Agent直接基于zookeeper的c client库,集成到Ardb实例中。
- 集群拓扑关系存于zookeeper中,各个节点同步获取
- 集群环境原则上只支持单key的命令,支持的命令参考redis集群支持情况