为人人设计的分布式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]
Posted by 54chen 架构研究