Raft 高可用
hugegraph 的开源版本是单机sever
使用内存缓存了schema 和节点相关的信息，
所以，在做 hugegraph server 的高可用性的时候存在问题。
比如，使用nigix 后面接多个 hugegraph server， 然后连接一个 cassandra 集群。
这种方式，如果只读的场景没有问题， 但是如果有线上写入就会有 数据一致性的问题。
关闭缓存功能，是一个临时的HA方案。
0.11版本的 Raft 协议
Raft 是一个一致性协议，核心原理，对于 hugegraph 任何的一个 写操作，
都交给 Raft， Raft 通过Leader，把数据写入到 Follower，并在协议上保证一致性。
Hugegraph 使用Raft来保证缓存一致性， 对于任何一个 写的操作被apply的时候，都会
调用 updateCache方法来更新节点的缓存。
@Override
public void onApply(Iterator iter) {
LOG.debug("Node role: {}", this.node().selfIsLeader() ?
"leader" : "follower");
StoreClosure closure = null;
try {
while (iter.hasNext()) {
closure = (StoreClosure) iter.done();
if (closure != null) {
// Leader just take it out from the closure
StoreCommand command = closure.command();
BytesBuffer buffer = BytesBuffer.wrap(command.data());
// The first two bytes are StoreType and StoreAction
StoreType type = StoreType.valueOf(buffer.read());
StoreAction action = StoreAction.valueOf(buffer.read());
boolean forwarded = command.forwarded();
// Let the producer thread to handle it
closure.complete(Status.OK(), () -> {
this.applyCommand(type, action, buffer, forwarded);
return null;
});
} else {
this.applyCommand()方法：
private void applyCommand(StoreType type, StoreAction action,
BytesBuffer buffer, boolean forwarded) {
BackendStore store = type != StoreType.ALL ? this.store(type) : null;
switch (action) {
case CLEAR:
boolean clearSpace = buffer.read() > 0;
store.clear(clearSpace);
this.context.clearCache();
break;
case TRUNCATE:
store.truncate();
this.context.clearCache();
break;
case SNAPSHOT:
assert store == null;
this.node().snapshot();
break;
case BEGIN_TX:
store.beginTx();
break;
case COMMIT_TX:
List<BackendMutation> ms = StoreSerializer.readMutations(buffer);
// RaftBackendStore doesn't write raft log for beginTx
store.beginTx();
for (BackendMutation mutation : ms) {
store.mutate(mutation);
this.updateCacheIfNeeded(mutation, forwarded);
}
store.commitTx();
break;
case ROLLBACK_TX:
在 COMMIT的时候，会调用
this.updateCacheIfNeeded(mutation, forwarded);负责每台机器上的更新
private void updateCacheIfNeeded(BackendMutation mutation,
boolean forwarded) {
// Update cache only when graph run in general mode
if (this.context.graphMode() != GraphMode.NONE) {
return;
}
/*
* 1. Follower need to update cache from store to tx
* 2. If request come from leader, cache will be updated by upper layer
* 3. If request is forwarded by follower, need to update cache
*/
if (!forwarded && this.node().selfIsLeader()) {
return;
}
for (HugeType type : mutation.types()) {
if (!type.isGraph() && !type.isSchema()) {
continue;
}
for (java.util.Iterator<BackendAction> it = mutation.mutation(type);
it.hasNext();) {
BackendEntry entry = it.next().entry();
this.context.notifyCache(ACTION_INVALID, type, entry.originId());
}
}
}
RAFT 协议 + rocket存储
官方推荐使用 Rocketdb，这本身是一个单机数据库。
而nebula的存储同样也是raft+rocketdb, 应该性能是比较有保证的。
其实，我们同样可以使用cassanda，mysql 这样的存储，这不过他们本身就有集群功能，把他们当作单节点来用，显得不伦不类。
那么Raft 协议是怎么来管理集群和partition的呢。是通过 group 来管理的。原则上一个group 为一个partion+replics。
假设有 9台，机器，我们想做三个副本。
那么可以分为 3个group， 每个group 3个raft 节点。 将数据将会被均匀的分布在在3个 group中，就可以达到partition+replics 的效果。
