BigCouch架构
CHTTPD
封装了FABIC接口，CouchDB在HTTP层的集群操作
FABRIC
CouchDB集群的操作代理。
主要用于控制CouchDB集群，Erlang层面的操作
REXI
Rexi是发送CouchDB的操作节点集群中的一个特制的RPC服务器应用程序。
MEM3
CouchDB集群的节点添加程序，在BigCouch中使用主要用于跟踪集群的两个重要信息：
成员节点信息；
每个数据库节点（分区）的映射关系；
节点信息和分区信息在本地节点数据库中进行跟踪。
拆分与合并分区在尚未成熟。
BigCouch数据库参数
Q参数
在创建数据库时指定数据库的分区数量（一致性哈希分区数）。
可能存在多个分区在同一节点上,允许你在集群的节点数量增长而无需re-shard操作。
默认值是8，可以在配置文件中进行更改：
在default.ini文件中cluster区域的q字段；
也可以在创建数据库时指定，比如：
curl -X PUT http://172.16.10.2:5984/test_db?q=4&n=3
分区示意图:
Q = 4时可以将数据库分为4个分区
假设有5个节点，这4个分区会分布在5个节点上，示例如下：
N参数
每个分片的冗余拷贝数量。
默认值是3，可以在配置文件中进行更改：
在default.ini文件中cluster区域的n字段；
也可以在创建数据库时指定，比如：
curl -X PUT http://172.16.10.2:5984/test_db?q=4&n=3
假设N=3，节点数为5个，每个分区将会复制3份并按一定的算法分片到5个节点上，分区中的文档会复制3份同步到每一个备份分区，示例如下：
BigCouch节点删除
需要删除的节点A，文件备份节点B
数据迁移
将A节点上 var/lib/shards/ 目录下的.couch文件通过scp等方式复制到B节点相同目录里；
数据同步
复制后如果A节点的数据有更新，在5986端口执行同步操作；
通知BigCouch集群新文件地址
在dbs数据库里面更新数据库配置文档，内容示例：
{
"_id": "test_db",
"_rev": "2-45088d2d1bb389c3fced1a952c2ea124",
"by_node": {
"[email protected]": [
"00000000-3fffffff",
"80000000-bfffffff"
],
"[email protected]": [
"40000000-7fffffff",
"c0000000-ffffffff"
],
"[email protected]": [
"40000000-7fffffff",
"c0000000-ffffffff",
"00000000-3fffffff",
"80000000-bfffffff"
],
"[email protected]": [
"40000000-7fffffff",
"c0000000-ffffffff"
],
"[email protected]": [
"00000000-3fffffff",
"80000000-bfffffff"
]
},
"by_range": {
"00000000-3fffffff": [
"[email protected]",
"[email protected]",
"[email protected]"
],
"40000000-7fffffff": [
"[email protected]",
"[email protected]",
"[email protected]"
],
"80000000-bfffffff": [
"[email protected]",
"[email protected]",
"[email protected]"
],
"c0000000-ffffffff": [
"[email protected]",
"[email protected]",
"[email protected]"
]
}
}
修改by_node和by_range字段，将A相关的信息修改为B的。
断开A服务器与集群的连接
修改set-cookie值并重启BigCouch服务器
移除集群A节点
通过集群5986端口访问nodes数据库，删除A服务器相关文档
删除A服务器上的nodes信息和dbs信息
清理shards目录中的文件，重启A服务器的BigCouch
5节点环境中，节点与集群断开时，该节点不可用。
冲突管理
冲突处理的例子
环境介绍
集群中三个节点：
A : 172.16.10.2
B : 172.16.10.3
C : 172.16.10.5
数据库：test_db
Q = 1，N=3
数据库不分区，备份三份。
添加数据：
{
"_id": "2809580fa3dc3d8d719c02c229000518",
"_rev": "1-1bd878534def1c2c9224e7398ab6a987",
"name": "beforeChange"
}
制造冲突
1、关闭B和C服务器；
2、修改A服务器的数据
{
"_id": "2809580fa3dc3d8d719c02c229000518",
"_rev": "2-6de54d127839d323b743435f447cb29f",
"name": "mike"
}
3、关闭A服务器；
4、在A服务器关闭后，启动B服务器；
5、修改B服务器的数据
{
"_id": "2809580fa3dc3d8d719c02c229000518",
"_rev": "2-19f995ede86cd2c367b2d90568a6f8c6",
"name": "MIKE"
}
6、启动A服务器；
验证数据
B服务器已同步为A的数据
2、C服务器数据也同步为A的数据
冲突检测
冲突检查函数：
function(doc){
if(doc._conflicts){
emit(doc._conflicts,null);
}
}
文档中的doc._conflicts属性是一个数组，列出了所有的冲突修订。
处理冲突
couchDB通过一个算法来选出胜利的修订，解决冲突。应用程序不应该信赖于这个算法，而是应该先去解决冲突。
自动冲突处理
每一个修订都包含有一个先前修订的列表，那个拥有最长的修订历史的修订会最终成为胜出的修订；如果两个修订历史刚好一样长，那么会比较它们的_rev值的ASCII序列，ASCII值更大的那个会最终胜出。所以在上面的例子中，2-6de54d127839d323b743435f447cb29f胜出了，2-19f995ede86cd2c367b2d90568a6f8c6落选了。
手动冲突处理
首先，用想要的值在目标文档上进行重写，然后把不想要的修订删除就可以了。
具体如下：
1、 读取当前文档；
2、 读取旧（冲突）版本；
3、 应用特定于域的合并逻辑；
4、 将文档更新为新（合并）版本；
5、 移除冲突文档版本。