探究couchbase分布式框架的笔记

这只是用于给我自己在研究couchbase分布式框架时候记录一些零碎想法的东西，说白了就是懒得写笔记。

9.25

根据couchbase手册的介绍来看，在避免冲突的问题上是直接用vBucket把节点之间的冲突变为节点内的冲突，不过replica的同步机制不明。不清楚vBucket的具体hash方法，应该是能把数据分散得相当均匀的算法才对呢。

客户端实现vBucket的机制不明，可能是与couchbase建立链接后就获取了一个vBucket，然后用相同的hash映射直连对应的节点，也可能是couchbase服务器在收到数据请求后会做重定向，不过应该是前者的可能性比较高，因为手册中也有提到过vBucket的更新会发送至集群中全部参与者，包括节点和正在访问的客户端。

源码里面有个文件夹是libvBucket，大概是讲这部分的吧，明天仔细研究研究去，不过找不到主入口的情况下看源码是真心蛋疼。

9.26

似乎是用CRC32算法来把key映射到不同的vBucket上，再确认一下。而且尚不明确vBucket和节点之间的映射算法是什么，或许是一致性哈希，不过还是去确定一下吧。

replica的数量最大在源码里被设置为4,还真没注意过使用手册中有没有说replica的上限是什么。

找不到入口看着一堆分散的函数真心蛋疼，这种七零八落的代码究竟该怎么看好呢。

似乎找到couchbase的总入口了，就是ns_server这个文件夹，不过这是用erlang写的，这要怎么看才对，或者说根本看不明白。

couchbase的缓存层应该就是直接用的memcached，所以缓存层的key映射node的算法就是Ketama。Ketama是一种一致性哈希加入虚拟节点的亚种算法。

至于replica的映射似乎不在libvbucket中处理，因为这个库的标准输入是这样的：

    {
      "hashAlgorithm": "CRC",
      "numReplicas": 2,
      "serverList": ["server1:11211", "server2:11210", "server3:11211"],
      "vBucketMap":
        [
          [0, 1, 2],
          [1, 2, 0],
          [2, 1, -1],
          [1, 2, 0]
        ]
    }
vBucketMap中已经给出了映射关系。

具体这些数据应该在哪里产生再找吧，还有个问题就是再均衡过程中各个节点之间的数据再分配是怎么进行的，也得进一步调查。

在集群服务器发生增减变动时，需要更新vBucket。此时既需要检查服务器数量是否不变，也要检查服务器的拓扑是否不变。对比服务器是否改变的算法本质就是两个数组一新一旧，用两个循环来找不同，O（N*N）的复杂度，或许可以改良？？

libvbucket部分的功能总结一下：

1.对于缓存层的数据直接对key做ketama映射。

2.需要使用replica时就直接读取读入的信息来映射到相应的节点。

3.集群发生改变时可以检测到vBucket的变动。

总体来说是对vBucket的基本操作，具体使用vBucket完成的高级逻辑不在这里。应该说总感觉这个库是给客户端用的，因为这些操作对于客户端来说刚好足够，足以让它们通过vBucket直接访问对应的节点。

对于这里源码的具体实现细节比如说ketama的实现方式之类的以后再看吧，现在以搞清楚总体上的分布算法为先。

ep-engine作为数据持久化的关键引擎，里面或许有节点之间数据交互的控制台，下一步去看看这个里面。

ep-engine看起来是个比较大的引擎，里面处理了不少东西，而且用的是C++。我可以说我只会C，各种类什么的都看不明白吗？？不过C++还是可以学习一下的，本来也该学学的。

不过代码注释是真不多，也没有什么说明文档，这是只能硬着头皮硬啃的样子。

10.9

嗯，文件真多，只能一个个看了。Kvshard.cc似乎包含管理数据存储的顶级函数，对外提供底层实现透明的数据访问接口，这里或许有一些分布算法。

Conflict_resolution.cc包含冲突管理函数，metadata是冲突判决时的依据，按照metadata中seqno, cas, expiration, flags的顺序依次比较大小，一旦分出大小，则大者胜出，无法分出大小则本地数据胜出。

好乱，真的好乱，这东西究竟应该自顶向下看还是反过来啊。

10.21

看样子moxi是个重点，作为管理客户端连接并且和memcached保持一致的组件，这里最起码会有一部分我需要的。