图形数据库neo4j 社区版数据同步构思

背景:

neo4j 社区版不支持集群，故存在单点故障问题。在使用过程中，发现neo4j 单节点运算处理能力大概在一亿范围内性能还是比较客观的。所以在生产环境中，假如数据量不是特别大的话可以使用社区版，前提是解决单点故障问题。

构思：
每部署一个neo4j服务就是一个单节点。假如在写数据的时候采用多写（或者数据同步）的方式，单其中一个节点挂了，其他节点及时顶上也是一种个不错的方案。那么如何进行多写或者数据同步呢?
同时，社区版最高只能使用4核CPU。如何抗住并发量比较高的使用场景，假如有多个实例组成集群，通过负载均衡一起并提供服务，岂不是可以扛起高并发？
以下是我在考虑neo4j 社区版数据同步的一些构思: 有多写的方式，有通过运维部署的方法，还有通过程序上数据同步的方式。

1. 多写的方案

应用程序配置多数据源。在CRUD时进行多数据源处理，一个完整的操作使用事务。
这种方案特别low，原因入下：

1. 多数据源处理，增加了处理的复杂性。多个节点同步时是不是得配置多个数据源？
2. 多个节点性能不一，一个CRUD操作事务在多个节点处理万一其中一个操作失败或者网络堵塞，如何操作岂不是失败了？处理效率不客观，且容易失败。

2. 数据同步方案

2.1 采用部署的方式解决
方案一： neo4j 数据文件（data）保存在oss上，只有数据变更及时能够同步到oss,其他节点通过感知目录的变化进行同步文件
（未实现，好像同步不了oss）
方案二： neo4j 数据文件（data）保存在NAS上，只有数据变更及时能够同步到NAS,其他节点通过感知目录的变化进行同步文件
（待运维实验） 结果: 方案被驳回，原因是NAS保存数据文件，假如网络抖不满足则数据库的要求。
方案三： Neo4j+DRBD+Keepalived高可用架构
(这种架构属于