總體架構
從下圖可見，Neo4j集群由兩個不同的角色Core Servers和Read Replicas組成，這兩個角色是任何生產部署中的基礎，但彼此之間的管理規模不同，並且在管理整個集群的容錯性和可伸縮性方面承擔着不同的角色。
Core Servers
核心服務器的主要責任是保護數據。 核心服務器通過使用Raft協議復制所有事務來做到這一點。 在確認向最終用戶應用程序提交事務之前，Raft確保數據安全持久。 在實際環境中，這意味着一旦集群（N / 2 + 1）中的大多數核心服務器都接受了事務，安全性要求會影響寫入延遲。 隱式寫入將以最快的多數Core Servers被確認，但是隨着群集中核心服務器數量的增加，確認一次寫入所需的Core Servers的數量也會增加。實際上，這意味着典型的Core Server集群中需要一定數量的服務器，足以為特定部署提供足夠的容錯能力。 這是使用公式M = 2F +1計算的，其中M是容忍F故障所需的核心服務器數量。 例如：
- 為了容忍兩個發生故障的核心服務器，我們需要部署五個核心的集群。
- 最小的容錯群集（一個可以容忍一個故障的群集）必須具有三個內核。
- 也可以創建僅包含兩個核心的因果集群。 但是，該群集不是容錯的。 如果兩個服務器之一發生故障，其余服務器將變為只讀。
請注意，如果Core Server集群遭受足夠的故障而無法處理寫入，則它將變為只讀狀態以保持安全。
Read Replicas
只讀副本的主要職責是擴展圖數據負載能力（密碼查詢，過程等）。 只讀副本的作用類似於Core Server保護的數據的緩存，但它們不是簡單的鍵值緩存。 實際上，只讀副本是功能齊全的Neo4j數據庫，能夠完成任意（只讀）圖數據查詢和過程。
只讀副本是通過事務日志傳送從Core Servers異步復制的。 只讀副本將定期（通常在ms范圍內）輪詢核心服務器以查找自上次輪詢以來已處理的任何新事務，並且核心服務器會將這些事務發送到只讀副本。 可以從相對較少的Core Server中饋送許多只讀副本數據，從而使查詢工作量大為增加，從而擴大規模。
但是，與核心服務器不同，只讀副本不參與有關群集拓撲的決策。 只讀副本通常應以相對較大的數量運行，並視為一次性使用。 丟失只讀副本不會影響群集的可用性，除了丟失其圖表查詢吞吐量的一部分。 它不會影響群集的容錯能力。
因果一致性
從應用程序的角度來看，集群的運行機制很有趣，但是考慮應用程序將如何使用數據庫完成工作也很有幫助。 在應用程序中，我們通常希望從圖中讀取並寫入圖中。 根據工作負載的性質，我們通常希望從圖中進行讀取以考慮先前的寫入，以確保因果一致性。
因果一致性使得可以寫入Core Server（數據是安全的）並從Read Replica（其中圖操作被擴展）中讀取這些寫入。 例如，因果一致性可確保當該用戶隨后嘗試登錄時，會出現創建該用戶帳戶的寫操作。
在執行事務時，客戶可以要求書簽，然后將其作為參數提供給后續事務。 使用該書簽，集群可以確保只有處理了該客戶已添加書簽的事務的服務器才能運行其下一個事務。 這提供了因果鏈，從客戶的角度確保了正確的寫后讀語義。
除了書簽之外，其他所有事情都由集群處理。 數據庫驅動程序與群集拓撲管理器一起使用，以選擇最合適的核心服務器和只讀副本，以提供高質量的服務。
Reference
https://neo4j.com/docs/operations-manual/3.5/clustering/introduction/