为人人设计的分布式key-value系统架构[原创]

[作者:陈臻 转载请注明出处:http://www.54chen.com/714-design-for-all-key-value-of-the-distributed-system-architecture-original/ 版本:1.1  2090810]

8.10 增加dev4server组里esx大侠提出的几个代表性问题

这个架构的产生,是为了公司的一个新项目,而后来慢慢变成了解决整个公司的所有问题的一个架构,期间经yahoo的angentZh先生、dev4server组里张立冰先生、盛大的许式伟先生推荐研究了bigtable、Dynamo等很有代表性的分布式架构。

如下图所示:

总体:底层以key-value存储,每个节点内作主主互备,节点以一致性哈希存取,哈希所使用的key为relation-key,非直接存取时的key。

step 0:连接客户端收到一个key为relatioin-key_id的存取请求,取出relation-key进行一致性哈希计算,这里是为了让相关的内容都能存在一个节点上,类似bigtable的tablet;

step 1:连接客户端读取最新的配置文件,server.conf。

step 2:根据配置文件寻找正确的节点。

step 3:在B节点之间增加了一个节点A的时候,A前的虚拟节点将寻找不到数据,此时连接客户端会重新读取老的配置文件server.conf.1,根据老的配置,这里的数据会去B节点读取原来的数据,读到的数据会转移到新增加的节点A中。

step 4:增加节点A后,服务器端会同时运行手动的转移脚本,转移脚本直接将B节点中符合A节点的存取规则的数据全部转移,转移结束将操作server.conf.1,进行删除老配置文件的操作。

这个架构的特点:

1.底层的key-value引擎并不特指某种,用cabinet或者是mysql都是可以的;

2.增加或者删除节点都可以是半自动+半手动或者是全手动处理;

3.适合大多数大型网站任何业务。

这个架构的名字:未命名

1. 速度:relation-key存储的方式,使相关性强的数据都在一起,保障批量的速度;

2.容灾:底层master-master同步的DB保障了其中一台出现故障不会影响整个系统;

3.扩展:手动加自动的方式使扩展节点应对自如。

Q&A:

Q:如何发现是找不到数据,而不是数据本来就没有?

A:系统中有server.conf server.conf.1 server.conf.2....只检测历史配置文件,如果手动迁移数据结束,历史配置文件将被删除。
Q:节点A进入时,是否能有选择的向B所要数据?

A:这里的确是忽略了同一个key的数据的版本控制的问题。如果先执行了手动脚本再存到A结点是正常的,如果先存到A再执行手动脚本,会出现老数据盖了新数据。不知有啥好的idea没?
Q:所要数据后,何时算完成?因为B可能一直在有新数据生成。

A:如果是新的配置文件上来了,写入B的数据应该就已经是新的规则了,这样,只需要手动执行的脚本循环当前的数据一圈,其中的数据自然是正确无误的了。手动脚本完成后删除老的配置文件标志迁移结束。
Q:完成后,节点A如何生效?

A:老的配置文件删除前,读数据操作是半生效状态(逐步恢复);老的配置文件被删除后,A节点的读写都自然生效了。
Q:容灾,如果节点A掉了,那B上是否有A所保存的信息?

A:一个节点下有至少两个物理实际节点做主主备份,上面是一个带网络检测和自动选取连接的工具,虚拟成一个节点,换句话说,A节点两台机器全部坏掉的可能性这里视为零。


原创文章如转载,请注明:转载自五四陈科学院[http://www.54chen.com]

捐款订阅54chen
捐赠说明

Comments