对于生产环境中的关键应用，高可用性（High Availability, HA）和可扩展性是必不可少的要求。Neo4j企业版提供了强大的集群功能，以满足这些需求。本章将详细介绍Neo4j的集群架构、配置、管理和监控，帮助读者构建健壮、可靠的Neo4j部署。
9.1 集群架构概述
理解Neo4j的集群架构是配置和管理集群的基础。Neo4j企业版主要提供因果集群（Causal Clustering）架构。
因果集群（Causal Clustering）
因果集群是Neo4j 3.1版本引入的默认集群架构，旨在提供高可用性、数据安全性和读取扩展性。
核心概念
因果集群的核心架构包括四个关键组成部分。
核心服务器是集群的中坚力量，负责处理所有写操作，并可参与读操作。它们通过Raft共识协议协同工作，确保数据的一致性和高可用性。通常需要至少3个核心服务器，以便在单个节点故障时仍能维持集群的正常运行。核心服务器共同组成高可用的核心集群，保证写入操作的持久性和一致性。每个核心服务器都保存完整的数据副本，并参与领导者选举、日志复制和事务提交等关键流程。
只读副本专门用于处理读操作，通过异步方式从核心服务器复制数据。它们不参与Raft共识，因此其故障不会影响集群的写入能力。只读副本的主要作用是扩展集群的读取能力，通过增加副本数量，可以水平扩展集群的读取吞吐量，有效分担核心服务器的读负载。只读副本适合部署在靠近用户的地理位置，以降低读取延迟，提升用户体验。
Raft协议是核心服务器之间实现一致性和高可用性的基础。它负责领导者选举、写操作日志的复制和故障恢复等任务。每次写操作都会先由领导者节点记录到日志，并通过Raft协议复制到大多数核心服务器。当大多数（N/2 + 1）核心服务器确认写入后，操作才会被正式提交。只要大多数核心服务器可用，集群就能继续处理写操作，保障服务的连续性和数据安全。
Neo4j集群支持因果一致性，允许客户端始终读取到自己之前的写入结果（Read-Your-Writes），即使读请求被路由到不同的服务器。这一特性通过书签（Bookmarks）机制实现：每次写操作完成后，服务器会返回一个书签，后续读操作携带该书签，确保读取的数据至少包含该书签之前的所有写入。因果一致性为分布式应用提供了更强的数据一致性保障，同时兼顾了性能和可扩展性。
集群拓扑
一个典型的因果集群通常由3个或5个核心服务器（Core Servers）组成，建议选择奇数个以避免脑裂（Split-Brain）现象。核心服务器负责处理所有写操作，并通过Raft协议协同工作，确保数据一致性和高可用性。为了提升读取能力，可以根据实际业务需求灵活添加任意数量的只读副本（Read Replicas）。只读副本异步从核心服务器同步数据，专门用于处理只读查询，从而分担核心服务器的读取压力。
所有核心服务器和只读副本都存储完整的数据副本，这意味着即使部分节点发生故障，数据依然安全可靠。集群的拓扑结构如下所示：
+-------------------+
| Core Server 1 |
+-------------------+
|
+-------------------+
| Core Server 2 |
+-------------------+
|
+-------------------+
| Core Server 3 |
+-------------------+
|
+----------------+----------------+
| |
+-------------------+ +-------------------+
| Read Replica 1 | | Read Replica 2 |
+-------------------+ +-------------------+
| |
+-------------------+ +-------------------+
| Read Replica ... | | Read Replica N |
+-------------------+ +-------------------+
在实际部署中，核心服务器建议分布在不同的物理主机或数据中心，以增强容灾能力。只读副本可以部署在靠近主要用户群的地理位置，进一步降低读取延迟，提升整体系统的可扩展性和用户体验。
工作流程
写操作时，客户端通常通过驱动程序将写请求发送到集群，该请求会被路由到当前的核心领导者（Leader）。领导者首先将写操作记录到日志，并通过Raft协议将该操作复制到大多数核心追随者（Followers）。当大多数核心服务器确认写入后，领导者才会将操作应用到状态机（即数据库），并向客户端返回确认信息以及一个书签，标记此次写操作的完成。
读操作时，客户端将读请求发送到集群，驱动程序会将请求路由到任意核心服务器或只读副本。如果客户端在请求中携带了书签，服务器会等待自身状态至少达到该书签所代表的时间点后再执行读取操作，从而确保因果一致性。这样，客户端始终能够读取到自己之前写入的数据，即使读请求被路由到不同的服务器。
高可用性与容错
因果集群通过冗余和共识协议提供高可用性。
核心服务器故障
当核心服务器中的追随者（Follower）发生故障时，集群能够继续正常运行，不会影响写操作的进行。如果核心领导者（Leader）出现故障，剩余的核心服务器会通过Raft协议自动选举出新的领导者，写操作在短暂中断后即可恢复。整体而言，集群可以容忍最多 (N-1)/2 个核心服务器的故障（其中N为核心服务器总数）。例如，3个核心服务器的集群可以容忍1个节点故障，5个核心服务器的集群可以容忍2个节点故障，从而保证高可用性和数据安全性。
只读副本故障
只读副本发生故障时，并不会影响核心集群的写操作能力。此时，集群会自动停止将读请求路由到故障的副本，确保读写操作的正常进行。只读副本的主要作用是扩展读取能力，其故障仅会导致可用的读取节点减少，可能增加其他节点的读负载，但不会影响数据一致性和写入可用性。
数据冗余
在因果集群架构中，每个核心服务器和只读副本都会保存完整的数据副本。这种数据冗余机制确保了即使部分节点发生故障或丢失，集群中的数据依然能够得到有效保护和恢复，从而保障了数据的安全性和高可用性。
网络分区（脑裂）
当发生网络分区（脑裂）时，Raft协议会确保只有包含大多数核心服务器的分区能够选举出领导者并继续处理写操作。处于少数派的分区将无法选举领导者，也无法进行写操作，从而有效防止数据不一致的情况发生。这种机制保证了即使部分节点因网络故障无法通信，集群整体的数据一致性和高可用性依然能够得到保障。
扩展性考量
因果集群主要提供读取扩展性。
读取扩展
通过增加只读副本的数量，Neo4j集群能够实现近乎线性的读取吞吐量扩展，非常适合应对读密集型的工作负载。只读副本专门用于处理查询请求，能够有效分担核心服务器的压力，从而提升整体系统的并发读取能力和响应速度。
在实际应用中，随着只读副本数量的增加，集群可以同时处理更多的并发查询，极大地提升了整体的读取性能。每个只读副本都维护着完整的数据副本，客户端驱动程序会自动将读请求分发到可用的副本和核心服务器，实现读写分离和负载均衡。这样不仅提升了查询的吞吐量，还能降低核心服务器的负载，使其能够更专注于写操作和事务一致性维护。
此外，只读副本的灵活部署也为跨地域访问提供了便利。可以将副本部署在靠近主要用户群体的地理位置，减少网络延迟，提升用户体验。即使某些副本发生故障，集群也会自动将读请求路由到其他可用节点，保证服务的高可用性和连续性。
需要注意的是，虽然只读副本能够极大扩展读取能力，但由于其采用异步复制机制，副本上的数据可能会有短暂的延迟。对于需要强一致性的场景，可以通过书签（Bookmarks）机制确保读取到最新的数据。合理配置和监控只读副本的同步状态，是保障数据一致性和系统性能的关键。
写入扩展
在因果集群架构下，写入操作的扩展性存在一定的限制。写入性能主要受限于当前核心领导者（Leader）的处理能力以及Raft协议带来的复制开销。每一次写操作都需要由领导者节点发起，并同步复制到大多数核心服务器，只有在大多数节点确认后才能完成提交。这种机制虽然保证了一致性和高可用性，但也意味着写入吞吐量无法通过简单增加核心服务器数量来线性扩展。实际上，随着核心服务器数量的增加，Raft协议的复制和协调成本也会相应上升，反而可能导致写入性能的边际提升有限。
因此，对于写密集型应用或需要处理超大规模数据集的场景，单一因果集群可能无法满足持续增长的写入需求。此时，建议结合Neo4j Fabric等分布式技术，将数据按业务维度进行分片（Sharding），将写入压力分散到多个独立的Neo4j集群或数据库实例上。通过Fabric统一查询和管理多个分片，可以在保证数据一致性和高可用性的同时，实现更高的整体写入扩展能力。关于Fabric的详细用法和分片策略，可参考第8.4节的相关内容。
地理分布
在实际生产环境中，Neo4j集群的成员可以灵活地分布在不同的数据中心或地理区域，以提升系统的容灾能力和服务的可用性。对于跨地域部署的集群，必须重点关注网络延迟对Raft协议性能的影响。由于Raft协议要求写操作在大多数核心服务器之间达成共识，高延迟网络会显著增加写操作的确认时间，进而影响整体写入性能。因此，在进行地理分布式部署时，建议将核心服务器优先部署在网络延迟较低、互联带宽充足的区域，确保写操作的高效性和一致性。
与此同时，只读副本的部署则更加灵活。可以根据主要用户群体的分布，将只读副本部署在靠近用户的地理位置。这样，用户的读请求能够被路由到最近的副本节点，显著降低读取延迟，提升访问速度和用户体验。只读副本采用异步复制机制，即使与核心服务器之间存在一定的网络延迟，也不会影响集群的写入能力和一致性要求。通过合理规划核心服务器和只读副本的地理分布，Neo4j集群能够兼顾高可用性、数据安全性和全球范围内的高性能访问需求。
理解因果集群的架构、一致性模型和扩展特性，是成功部署和运维高可用Neo4j环境的基础。
9.2 核心服务器配置
正确配置核心服务器是构建稳定、高性能因果集群的关键。
集群成员与发现
核心服务器需要知道彼此的存在才能形成集群。
配置参数 (neo4j.conf)：
server.mode：设置服务器角色。server.mode=COREcausal_clustering.expected_core_cluster_size：指定预期的核心服务器数量。集群需要达到这个数量才能选举领导者。causal_clustering.expected_core_cluster_size=3causal_clustering.initial_discovery_members：提供一个初始的核心服务器地址列表，用于集群发现。格式为host:port，端口通常是发现端口（默认5000）。# 提供所有核心成员的地址和发现端口 causal_clustering.initial_discovery_members=core1:5000,core2:5000,core3:5000server.discovery.advertised_address：指定当前服务器用于集群发现的地址和端口。# core1的配置 server.discovery.advertised_address=core1:5000server.bolt.advertised_address：指定当前服务器用于Bolt连接（客户端连接）的地址和端口。# core1的配置 server.bolt.advertised_address=core1:7687server.cluster.advertised_address：指定当前服务器用于集群内部通信（Raft协议）的地址和端口（默认6000）。# core1的配置 server.cluster.advertised_address=core1:6000
发现过程
当服务器启动时，它会首先尝试与initial_discovery_members参数中指定的其他核心服务器建立连接。通过这些初始地址，服务器能够发现并联系到集群中的其他成员。连接建立后，各个服务器会相互交换自身的成员信息，协同完成集群的组建过程。随着集群的正常运行，成员信息会被动态维护和同步，集群能够自动检测新成员的加入或现有成员的离线状态。此时，集群的成员发现机制不再完全依赖于最初配置的地址列表，而是通过内部的通信协议持续更新和管理集群成员信息。这种机制确保了集群的灵活性和可扩展性，即使部分节点发生变更或网络环境波动，集群依然能够保持成员信息的准确和一致。
Raft协议参数调优
Raft协议有一些参数可以调整，以适应不同的网络环境和性能需求，但这通常只在特定情况下需要。
配置参数 (neo4j.conf)：
Raft协议的核心参数主要包括选举超时、心跳间隔、日志复制超时和批处理大小等。合理配置这些参数有助于提升集群在不同网络环境下的稳定性和性能。
首先，causal_clustering.raft.election_timeout 控制领导者选举的超时时间。该参数指定了追随者在多长时间内未收到领导者的心跳信号时，会主动发起新的领导者选举。默认值为1000毫秒。在网络延迟较高或跨地域部署的场景下，建议适当增加此超时时间，以避免因网络抖动导致频繁的领导者切换，从而影响集群的可用性。
其次，causal_clustering.raft.heartbeat_interval 用于设置领导者向追随者发送心跳信号的时间间隔，默认值为200毫秒。心跳间隔应远小于选举超时时间，以确保追随者能够及时感知领导者的存活状态。过短的心跳间隔会增加网络负载，过长则可能导致选举延迟。
causal_clustering.raft.replication_timeout 参数定义了日志复制的超时时间，默认值为10000毫秒。该参数决定了领导者在等待追随者确认日志复制时的最长等待时间。如果复制超时，可能会触发重试或导致追随者被视为失联。对于网络波动较大的环境，可以适当增加该值，以减少不必要的重试和节点切换。
此外，causal_clustering.raft.min_batch_size 和 causal_clustering.raft.max_batch_size 用于控制Raft日志复制时的批处理大小。合理设置批处理参数可以提升日志复制的效率，减少网络开销。较大的批处理有助于提升吞吐量，但也可能增加单次复制的延迟。应根据实际负载和网络状况进行调整。
综合来看，Raft协议参数的优化需要结合实际部署环境进行测试和调整。对于大多数本地或低延迟网络，默认参数通常已足够。如果集群跨地域部署或网络状况复杂，建议逐步调整上述参数，并通过监控集群的稳定性和性能指标，找到最适合自身业务场景的配置方案。
在实际生产环境中，Raft协议参数的调优需要结合具体的网络状况和业务需求进行权衡。一般情况下，Neo4j默认的Raft参数已经能够满足大多数本地或低延迟网络环境的需求，无需额外调整即可保证集群的稳定性和性能。然而，在跨地域、跨数据中心等高延迟网络环境下，建议适当增加election_timeout和replication_timeout等参数，以减少因网络抖动导致的频繁领导者切换和日志复制超时，从而提升集群的容错能力和稳定性。需要注意的是，增加这些超时时间虽然有助于提升容错性，但也会相应延长故障恢复和领导者选举的时间，可能影响业务的实时性。因此，在进行参数调整前，务必通过充分的性能测试和压力测试，评估不同参数设置对集群性能和可用性的实际影响，确保调整能够带来预期的优化效果。此外，Raft协议参数的配置需谨慎操作，不合理的设置可能导致集群不稳定、选举频繁或数据同步异常。建议在变更参数前备份相关配置，并在测试环境中验证调整方案，逐步推广到生产环境，确保集群的高可用性和数据安全性。
事务与一致性配置
因果集群提供可配置的一致性级别。
配置参数 (neo4j.conf)：
在Neo4j集群中，可以通过以下参数配置事务和读取的一致性行为：
dbms.read_consistency用于设置默认的读取一致性级别（针对未指定书签的读取）。当设置为STRONG（默认值）时，所有读取请求都会被路由到领导者节点，以确保读取到最新提交的数据。如果设置为CAUSAL，读取请求可以被路由到任何核心成员或只读副本，并通过书签机制保证因果一致性，适合对读取性能有更高要求且能容忍轻微延迟的场景。causal_clustering.cluster_allow_reads_on_followers控制是否允许将读请求路由到核心追随者（Follower），默认值为true。启用后，集群可以更好地分担领导者的读取压力，提高整体读取吞吐量。causal_clustering.cluster_allow_reads_on_leader控制是否允许将读请求路由到核心领导者（Leader），默认值为true。通常建议保持启用，以便在需要强一致性读取时能够直接访问领导者节点。
合理配置这些参数，可以根据业务需求在一致性和性能之间取得平衡。
书签（Bookmarks）
书签（Bookmarks）机制是实现因果一致性（Causal Consistency）的核心手段。在Neo4j集群环境中，每当客户端执行一次写事务并成功提交后，驱动程序会自动生成并返回一个书签。这个书签实际上是一个标记，记录了当前写操作在集群中的最新提交进度。客户端可以在后续的读事务中，将该书签作为参数传递给数据库。这样，Neo4j会确保本次读取操作所返回的数据，至少包含了该书签所代表的所有已提交写入，从而保证了“读到自己写”的一致性体验。即使读请求被路由到不同的核心服务器或只读副本，只要这些节点已经同步到对应的书签位置，读取结果就能反映出之前的写入操作。通过显式管理和传递书签，应用程序能够在分布式环境下实现更强的数据一致性保障，同时兼顾高性能和可扩展性，非常适合需要跨节点读写的业务场景。
# Python驱动程序示例
with driver.session(database="neo4j") as session:
# 写事务
result = session.execute_write(create_node_tx)
bookmark = session.last_bookmark()
# 使用书签进行读事务
result = session.execute_read(read_node_tx, bookmark=bookmark)
事务超时
在Neo4j集群环境中，事务的执行时间可能受到网络延迟、Raft协议复制以及节点间同步等因素的影响。为避免长时间运行的事务占用资源或因超时导致事务失败，可以通过配置参数 dbms.transaction.timeout 设置事务的最大允许执行时间（默认值为60秒）。如果事务在规定时间内未能完成，将被自动终止并回滚。在生产环境中，建议根据实际的网络状况、数据量和业务需求，适当调整该超时时间。例如，在跨地域部署或高负载场景下，适当延长超时时间有助于减少因偶发延迟导致的事务失败；而在对响应速度要求较高的场景下，可以缩短超时时间以快速释放资源。合理设置事务超时参数，有助于提升集群的稳定性和整体性能，同时保障数据一致性和业务连续性。
配置建议
在配置核心服务器的一致性和事务参数时，建议优先在应用程序中显式管理和使用书签（Bookmarks）。通过书签机制，客户端能够确保读取到自己之前写入的数据，实现因果一致性（Read-Your-Writes），在保证数据一致性的同时获得更好的性能和扩展性。对于读取一致性级别的选择，应根据实际业务需求进行权衡。如果应用场景要求每次读取都返回绝对最新的数据，可以将dbms.read_consistency参数设置为STRONG，此时所有读取请求会被路由到领导者节点，确保读取到最新提交的数据；如果业务能够容忍轻微的数据延迟，并希望提升读取吞吐量，则可以选择CAUSAL级别，并结合书签机制，允许读取请求被分发到核心追随者或只读副本，从而实现更好的读扩展能力。此外，建议根据实际事务的执行时间合理调整dbms.transaction.timeout参数，既要避免因超时导致事务失败，也要防止长时间运行的事务占用过多资源。通过综合考虑一致性需求、性能目标和业务特性，合理配置这些参数，可以在高可用性、数据一致性和系统性能之间取得最佳平衡。
通过仔细配置核心服务器的网络发现、Raft参数和事务一致性设置，可以构建一个满足特定需求的稳定、可靠的Neo4j核心集群。
9.3 只读副本设置
只读副本（Read Replicas）是扩展Neo4j因果集群读取能力的关键组件。它们异步复制核心集群的数据，并处理只读查询。
添加与配置副本
将一个Neo4j实例配置为只读副本相对简单。
配置参数 (neo4j.conf)：
server.mode：设置服务器角色为只读副本。server.mode=READ_REPLICAcausal_clustering.discovery_listen_address：副本监听集群发现信息的地址（可选，如果需要被其他副本发现）。server.discovery.advertised_address：副本向集群广播的发现地址。# replica1的配置 server.discovery.advertised_address=replica1:5000server.bolt.advertised_address：副本用于Bolt连接的地址。# replica1的配置 server.bolt.advertised_address=replica1:7687causal_clustering.initial_discovery_members：提供核心服务器的地址列表，以便副本找到并加入集群。# 副本需要知道核心成员的地址 causal_clustering.initial_discovery_members=core1:5000,core2:5000,core3:5000
启动副本
配置完成后，启动Neo4j实例。副本会自动连接到initial_discovery_members参数中指定的核心服务器，加入集群并开始同步数据。初始同步过程可能需要一定时间，具体取决于数据库的大小和网络速度。
添加多个副本
要添加多个只读副本，只需按照上述配置方法为每个副本单独准备一份 neo4j.conf 配置文件，并将其 server.mode 设置为 READ_REPLICA，同时确保 causal_clustering.initial_discovery_members 指向核心服务器的地址。每个只读副本实例可以部署在不同的物理主机或虚拟机上，启动后会自动加入集群并开始从核心集群同步数据。所有副本彼此独立运行，互不影响，即使某个副本出现故障，其他副本仍可正常提供读取服务。通过灵活增加或减少只读副本的数量，可以根据实际的读取压力动态扩展集群的读取能力。此外，将只读副本部署在靠近主要用户或应用服务器的地理位置，有助于降低读取延迟，提升整体访问性能。合理规划副本的数量和部署位置，是实现高并发、低延迟读取的关键手段。
只读副本通过异步方式从核心集群同步数据，这意味着副本上的数据可能略微滞后于核心领导者。
同步机制
只读副本通过异步复制机制与核心服务器保持数据同步。具体流程如下：副本会定期向核心服务器请求最新的事务日志，将这些日志拉取到本地后，依次应用到自身的数据库实例中。这样可以确保副本的数据不断接近核心集群的最新状态。整个同步过程是自动进行的，副本会持续检测自身与核心服务器之间的进度差异，并在发现有新的事务提交时主动发起同步请求。由于采用异步复制，副本上的数据可能会与核心领导者存在短暂的延迟，但通常能够在毫秒到秒级别内完成同步。该机制不仅保证了数据的一致性和完整性，还能在副本发生故障或重启后自动恢复到最新的可用状态，无需人工干预。这种高效的同步方式为集群的读取扩展和高可用性提供了坚实基础。
复制延迟
只读副本的数据同步采用异步复制机制，因此副本上的数据与核心领导者之间通常会存在一定的复制延迟。这种延迟的具体时长受多种因素影响，包括网络带宽和稳定性、核心服务器的事务提交频率、当前的系统负载以及副本自身的处理能力。在大多数本地或网络状况良好的环境下，复制延迟通常能够控制在毫秒到几秒的范围内，能够满足绝大多数读请求的实时性需求。然而，在高并发写入、网络波动或副本资源紧张的情况下，延迟可能会有所增加。需要注意的是，虽然只读副本的数据可能略微滞后于核心领导者，但通过合理配置书签机制和监控同步状态，可以有效保障数据一致性和读取体验。因此，在实际部署和运维过程中，应持续关注复制延迟指标，及时优化网络和系统资源，确保副本能够高效、稳定地同步最新数据。
监控同步状态
可以使用JMX指标或系统过程监控副本的同步状态：
// 查看集群成员及其角色和状态
CALL dbms.cluster.overview()
// 查看特定副本的复制延迟（需要连接到副本实例）
// JMX指标: causal_clustering.core.replication_status.<member_id>.lag
处理延迟
在实际生产环境中，处理只读副本的复制延迟需要采取多方面的措施。首先，可以通过在读事务中显式传递书签（Bookmarks），确保从副本读取的数据至少包含了特定的写入操作。这样，即使副本存在一定的同步延迟，依然能够保证因果一致性，确保客户端读取到自己之前写入的数据。这对于需要强一致性保障的业务场景尤为重要。其次，应持续监控只读副本的复制延迟指标。可以利用Neo4j的JMX监控、系统过程或第三方监控工具，实时跟踪副本与核心服务器之间的同步进度。如果发现延迟持续升高，需及时排查网络带宽、核心服务器负载、磁盘I/O瓶颈或副本本身的资源消耗等潜在问题。针对高延迟场景，可以考虑优化网络环境、提升硬件配置，或适当增加副本数量以分散读取压力。此外，合理规划副本的部署位置，将其靠近主要用户群体，也有助于降低访问延迟和提升整体读取性能。通过结合书签机制、延迟监控和系统优化，可以有效应对只读副本的复制延迟，保障Neo4j集群的高可用性和一致性。
副本的负载均衡
Neo4j驱动程序支持自动的读写分离和负载均衡。
驱动程序路由
当驱动程序连接到Neo4j集群时，它会自动发现并获取当前集群的拓扑结构，包括所有核心服务器和只读副本的地址与角色信息。驱动程序根据每次事务的类型（读或写）以及指定的访问模式（READ 或 WRITE），智能地将请求路由到最合适的服务器节点。对于写事务，驱动程序始终将请求发送到当前的核心领导者节点，以确保数据的一致性和正确的事务提交流程。对于读事务，驱动程序则可以将请求分发到任意一个核心服务器或只读副本，从而充分利用集群的读取扩展能力。为了实现高效的负载均衡，驱动程序内置了多种分发策略（如轮询、最少连接数等），能够自动将大量并发的读请求均匀分配到所有可用的副本和核心服务器上。这不仅提升了整体的查询吞吐量，还能有效降低单个节点的压力，提升系统的可用性和响应速度。通过这种自动化的路由与负载均衡机制，应用程序无需关心底层集群结构的变化，即可实现高效、可靠的读写分离和弹性扩展。
配置驱动程序
# Python驱动程序连接到集群
driver = GraphDatabase.driver(
"neo4j://core1:7687,core2:7687,core3:7687", # 提供部分集群成员地址
auth=("neo4j", "password")
)
# 使用默认访问模式（WRITE）
with driver.session(database="neo4j") as session:
# 写操作路由到Leader
session.write_transaction(...)
# 读操作也可能路由到Leader
session.read_transaction(...)
# 显式指定READ访问模式
with driver.session(database="neo4j", default_access_mode=neo4j.READ) as session:
# 读操作可以路由到副本或核心
result = session.read_transaction(...)
负载均衡策略
Neo4j驱动程序在处理集群中的读请求时，默认采用轮询（Round Robin）策略，将并发的读操作均匀分配到所有可用的核心服务器和只读副本上。这种策略能够有效平衡各节点的负载，避免单点压力过大，从而提升整体查询吞吐量和系统响应速度。对于大多数应用场景，轮询策略已经能够满足高并发读取的需求。
此外，Neo4j驱动程序还支持通过配置自定义负载均衡策略。例如，可以根据节点的地理位置、当前负载、响应延迟等因素，优先将读请求路由到距离客户端更近或负载较低的服务器节点。这对于跨地域部署或对延迟敏感的应用尤为有用。部分驱动程序还允许开发者集成自定义的负载均衡逻辑，以实现更精细的流量分配和容灾策略。
在实际部署中，建议结合业务特点和集群规模，合理选择和调整负载均衡策略。对于读密集型应用，可以通过增加只读副本数量并优化驱动程序配置，进一步提升系统的并发处理能力和用户体验。同时，持续监控各节点的负载和响应时间，及时优化负载均衡参数，有助于保障Neo4j集群的高可用性和稳定性。
副本的最佳实践
在实际生产环境中，合理使用只读副本能够极大提升Neo4j集群的读取能力和系统弹性。首先，应根据实际的读负载动态调整只读副本的数量。当应用的读取请求量增加时，可以灵活地添加更多副本以分担核心服务器的压力，反之则可减少副本以节省资源。其次，建议将只读副本部署在靠近主要用户或应用服务器的地理位置，这样可以显著降低网络延迟，提升用户的访问速度和体验。为了保障数据的及时性和一致性，必须持续监控每个副本的运行状态和数据同步延迟，确保副本能够及时从核心服务器同步最新的数据，避免因延迟过高导致读取到过时信息。Neo4j官方驱动程序支持自动的读写分离和负载均衡，开发者无需手动指定节点，驱动会根据集群拓扑和节点角色智能路由请求，实现高效的资源利用和弹性扩展。此外，在对一致性有较高要求的场景下，建议在读操作中显式使用书签（Bookmarks）机制，确保客户端能够读取到自己之前写入的数据，实现因果一致性。通过结合副本数量的灵活扩展、地理分布优化、实时监控、驱动程序自动路由以及书签机制，能够充分发挥只读副本的优势，满足高并发、低延迟和高一致性等多样化业务需求。
通过合理配置和使用只读副本，可以有效扩展Neo4j集群的读取能力，满足高并发读取需求。
9.4 集群管理与监控
有效的集群管理和监控是确保Neo4j高可用环境稳定运行的关键。
集群状态查看
了解集群的当前状态、成员和角色对于管理至关重要。
使用Cypher过程
Neo4j提供了多个内置的Cypher过程来查看集群信息：
dbms.cluster.overview()：显示集群中所有已知成员及其角色、数据库、地址和状态。CALL dbms.cluster.overview()dbms.cluster.status()：显示当前连接服务器的集群状态信息。CALL dbms.cluster.status()dbms.cluster.role()：显示当前连接服务器的角色（LEADER, FOLLOWER, READ_REPLICA）。CALL dbms.cluster.role()
使用neo4j-admin命令行工具
# 查看集群状态（需要连接到一个集群成员）
neo4j-admin cluster status --database=neo4j
监控工具
除了Cypher过程和命令行工具外，Neo4j还通过JMX指标和Metrics Endpoint提供了丰富的集群状态信息，便于集成到企业级监控系统中。通过JMX接口，可以实时获取集群成员的角色、数量、健康状况等关键指标。例如，causal_clustering.core.members 用于显示当前核心服务器的成员列表和状态，causal_clustering.read_replica.members 则反映所有只读副本的分布和运行情况。此外，Metrics Endpoint（通常以HTTP接口暴露）同样支持导出集群相关的运行数据，方便与Prometheus、Grafana等主流监控平台对接。通过这些指标，运维人员能够持续跟踪集群的拓扑变化、节点健康、复制延迟等重要参数，及时发现潜在风险并进行预警，从而保障Neo4j集群的高可用性和稳定性。
成员管理
在集群生命周期中，可能需要添加或移除成员。
添加核心服务器
要添加新的核心服务器，首先需要将新服务器配置为CORE模式，并确保其initial_discovery_members参数包含所有现有和新加入的核心成员地址。接下来，需在所有现有核心服务器上更新expected_core_cluster_size参数，以反映新的核心成员总数。完成配置后，逐个重启现有核心服务器，使其应用新的期望大小设置。最后，启动新核心服务器，它会自动加入集群并开始同步数据。整个过程中，建议逐步操作并监控集群状态，确保新成员顺利加入且数据同步正常。
移除核心服务器
移除核心服务器时，首先需要在剩余的核心服务器上更新expected_core_cluster_size参数，确保其反映移除后的核心成员总数。然后，依次重启这些核心服务器以应用新的配置。接下来，停止需要移除的核心服务器。最后（可选），可以从其他服务器的initial_discovery_members参数中删除该服务器的地址，以保持配置的整洁和准确。
添加只读副本
要添加新的只读副本，首先需要将目标服务器的 neo4j.conf 配置文件中的 server.mode 参数设置为 READ_REPLICA，并确保 causal_clustering.initial_discovery_members 参数包含所有核心服务器的地址。完成配置后，启动该服务器，Neo4j 实例会自动作为只读副本加入现有集群，并开始从核心服务器异步同步数据。整个过程无需对核心集群进行重启或其他干预，副本的加入和数据同步均由系统自动完成。通过这种方式，可以根据实际业务需求灵活扩展只读副本的数量，从而提升集群的读取能力和系统的弹性。
移除只读副本
要移除只读副本，首先需要在目标副本服务器上停止Neo4j服务。只读副本停止后，集群会自动检测到该节点已离线，并立即停止将读请求路由到该副本，无需对核心集群或其他副本进行任何额外操作。此过程不会影响集群的写入能力和整体可用性，只会减少可用的读取节点数量，可能会导致其他副本或核心服务器的读负载略有增加。建议在移除副本前，评估当前的读取压力，确保剩余节点能够满足业务需求。如果需要彻底清理配置，可以在相关服务器的neo4j.conf文件和集群的发现成员列表中移除该副本的地址信息，以保持配置的整洁和准确。整个移除过程简单高效，适合根据实际业务变化灵活调整副本数量，实现资源的动态优化和弹性扩展。
动态成员变更
Neo4j 4.x版本引入了更动态的集群成员管理命令，允许在运行时添加和移除成员，而无需完全重启集群（具体命令和过程请参考相应版本的官方文档）。
故障排查与恢复
集群环境下的故障排查需要考虑分布式系统的复杂性。
常见故障场景
当单个核心服务器发生故障时，通常表现为该节点无响应，集群日志中会显示该成员处于离线状态。此时，只要剩余的核心服务器数量仍然达到多数派（即超过一半），集群能够继续正常运行，写操作不会中断，并且会自动选举新的领导者（如果故障节点原本是领导者）。这种情况下，集群的高可用性机制能够有效保障业务连续性。对于故障节点的恢复，首先需要排查并修复导致服务器不可用的根本原因，例如硬件故障、网络中断或配置错误等。修复完成后，重启该核心服务器，Neo4j会自动将其重新加入集群，并通过Raft协议将最新的数据同步到该节点，无需手动干预。整个恢复过程对业务影响较小，能够确保数据一致性和集群的稳定性。建议在节点恢复后，持续监控其同步进度和运行状态，确保其完全恢复到正常服务水平。
当多个核心服务器同时发生故障，导致集群失去多数派时，Neo4j集群将无法选举出新的领导者，所有写操作会被阻断，集群进入只读模式或完全不可用状态。这种情况下，集群的高可用性机制无法正常发挥作用，业务连续性受到严重影响。为恢复集群的正常运行，必须尽快修复并重启足够数量的故障核心服务器，使在线核心成员重新达到多数派要求。一旦多数派恢复，集群会自动选举新的领导者，恢复写操作能力。如果部分核心服务器无法及时修复，且业务对可用性有紧急需求，可以考虑从最近的备份进行数据恢复，或在极端情况下执行强制性集群重组（如移除永久故障节点并重新配置集群）。需要注意，强制重组属于高级操作，存在数据丢失和一致性风险，务必在充分评估和备份的前提下谨慎操作。建议在日常运维中定期备份数据，并监控核心服务器的健康状态，以降低因多数派丢失导致的业务中断风险。
当只读副本发生故障时，通常表现为该副本节点无响应或无法正常提供读取服务。此时，Neo4j集群会自动检测到该副本的离线状态，并立即停止将读请求路由到该节点，从而保障整体服务的可用性。虽然只读副本的故障不会影响集群的写入能力和数据一致性，但会导致可用的读取节点数量减少，进而可能增加其他核心服务器或副本的读负载，影响整体的读取性能。为恢复服务，需要首先排查并修复导致副本故障的根本原因，例如网络中断、硬件故障或资源耗尽等。修复完成后，重启该只读副本，Neo4j会自动将其重新加入集群，并通过异步复制机制同步最新的数据。整个恢复过程无需对核心集群进行干预，能够实现快速恢复和弹性扩展。建议在副本恢复后，持续监控其同步进度和运行状态，确保其能够及时跟上核心服务器的数据变更，保障集群的高可用性和读取能力。
在分布式系统中，网络分区（又称脑裂）是指集群成员因网络故障被分割成两个或多个无法相互通信的子集。在Neo4j因果集群中，发生网络分区时，只有包含多数派（即超过一半核心服务器）的分区能够继续选举领导者并处理写操作，而少数派分区则无法进行写入，只能提供只读服务或完全不可用。这种机制有效防止了数据不一致的风险。网络分区通常表现为部分节点突然无法与其他节点通信，集群日志中会显示成员失联或领导者频繁切换。为恢复集群的正常运行，必须尽快排查并解决网络故障，确保所有核心服务器能够重新建立通信连接。网络恢复后，Neo4j集群会自动完成成员信息同步和领导者选举，所有节点的数据状态将重新保持一致，无需手动干预。建议在生产环境中定期测试网络容灾能力，并通过监控及时发现和处理网络分区问题，以保障集群的高可用性和数据一致性。
故障排查步骤
在进行集群故障排查时，建议按照以下步骤系统性地定位和解决问题。首先，全面检查所有集群成员的日志文件（如neo4j.log和debug.log），重点关注错误信息、警告和与集群事件相关的日志条目，这些内容通常能够揭示节点失联、选举异常、复制失败等根本原因。其次，利用内置的Cypher过程（如CALL dbms.cluster.overview()）或命令行工具（如neo4j-admin cluster status）实时查看集群的整体状态，包括各成员的角色、在线情况以及当前领导者节点，判断是否存在成员离线、角色切换频繁或丢失多数派等异常现象。第三，排查网络连接问题，确保所有核心服务器和只读副本之间的网络通信畅通无阻，同时验证客户端与集群的连接是否正常。此步骤应包括检查防火墙策略、网络路由、DNS解析以及端口开放情况，避免因网络隔离或配置错误导致节点无法互通。第四，监控各节点的资源使用情况，包括CPU、内存（堆和页缓存）、磁盘I/O等关键指标，及时发现资源瓶颈或异常消耗，这些问题可能导致节点响应缓慢、超时或频繁重启。最后，尝试隔离问题的影响范围，判断是单个节点故障还是涉及整个集群。如果仅有个别节点异常，可优先针对该节点进行修复和重启；若发现多数派丢失或集群整体不可用，则需重点关注网络、配置和集群规模等系统性因素。通过上述分步排查和定位，可以高效地识别并解决Neo4j集群中的常见故障，保障系统的高可用性和数据一致性。
集群监控最佳实践
持续监控是维护集群健康的关键。
关键监控指标
集群成员状态是Neo4j集群监控的首要关注点。应持续关注每个集群成员的角色分布，包括领导者（Leader）、追随者（Follower）以及只读副本（Read Replica），以确保集群结构的健康和写入能力的正常。监控每个成员的在线状态至关重要，及时发现节点离线或失联有助于快速响应潜在故障。此外，需要对比预期的核心成员数量与实际在线的核心成员数量，确保集群始终具备多数派，能够正常进行领导者选举和写操作。如果实际在线的核心成员数低于预期，可能导致集群无法选举领导者，影响写入可用性。通过定期检查这些指标，可以及时发现集群拓扑变化、节点故障或配置异常，保障Neo4j集群的高可用性和数据一致性。
在Neo4j因果集群中，Raft协议是实现核心服务器一致性和高可用性的基础。监控Raft协议的关键指标有助于及时发现集群中的一致性风险和潜在故障。首先，需要关注当前集群的领导者（Leader）节点，确保始终有一个明确的领导者负责协调写操作和日志复制。其次，Raft任期（Term）编号反映了领导者选举的历史和频率，频繁变更任期可能意味着网络抖动、节点不稳定或配置不当，应引起警惕。最后，监控最后提交的Raft日志索引，可以了解集群中各节点的数据同步进度，及时发现日志复制延迟或落后节点。通过持续跟踪这些Raft协议指标，能够有效保障集群的一致性、稳定性和写入可用性，为高可用环境提供坚实支撑。
复制延迟是衡量只读副本与核心领导者之间数据同步时效性的关键指标。在Neo4j因果集群中，核心服务器负责处理所有写操作，而只读副本通过异步方式从核心服务器拉取并应用最新的事务日志。由于网络带宽、系统负载、事务提交频率等多种因素的影响，副本上的数据可能会与核心领导者存在一定的延迟。持续监控每个只读副本的复制延迟，有助于及时发现同步瓶颈或异常，防止因副本数据滞后导致读取到过时信息。建议结合JMX指标、系统过程或监控平台，定期采集和分析复制延迟数据，确保副本能够及时跟进核心服务器的最新变更，满足高并发、低延迟读取的业务需求。对于对一致性要求较高的场景，还可以结合书签（Bookmarks）机制，确保读取操作能够反映最近的写入结果。
资源使用情况直接影响Neo4j集群的稳定性和性能。应重点关注每个集群成员的CPU利用率、内存消耗（包括堆内存和页缓存）、磁盘I/O负载等关键资源指标。高CPU占用可能导致查询响应变慢或节点无法及时参与Raft协议通信；内存不足会引发频繁的垃圾回收（GC）或OOM错误，影响数据库的可用性；磁盘I/O瓶颈则可能导致事务提交和数据同步延迟，影响整体吞吐量。此外，页缓存命中率是衡量数据库查询效率的重要参数，命中率过低通常意味着大量磁盘读取，需考虑增加内存或优化数据访问模式。建议通过JMX、Metrics Endpoint等方式，持续采集和分析资源使用数据，及时发现异常趋势，提前进行容量规划和性能调优。合理的资源监控和管理，是保障Neo4j集群高可用性和高性能运行的基础。
事务和查询性能是衡量Neo4j集群运行效率的重要指标。首先，应关注事务的吞吐量和延迟，定期统计单位时间内成功提交的事务数量，以及每个事务从发起到完成所需的平均时间。高吞吐量和低延迟表明集群能够高效处理并发请求，满足业务需求；而事务延迟升高或吞吐量下降，可能预示着系统资源瓶颈、网络拥塞或集群内部同步延迟等问题，需要及时排查和优化。
其次，慢查询的数量和执行时间也是关键监控点。通过分析执行时间较长的查询，可以发现潜在的索引缺失、数据模型设计不合理或查询语句本身存在性能问题。建议定期收集和分析慢查询日志，定位热点查询和性能瓶颈，针对性地进行索引优化、查询重写或数据结构调整，从而提升整体查询效率。
此外，Bolt连接数反映了当前集群对外服务的并发连接情况。持续监控Bolt连接的总数和活跃连接数，有助于及时发现连接泄漏、客户端异常或连接池配置不合理等问题。连接数异常增长可能导致服务器资源耗尽，影响正常服务。通过合理配置连接池参数、优化客户端连接管理，并结合实时监控，可以保障集群的稳定性和高并发处理能力。
综合监控事务吞吐量、延迟、慢查询和Bolt连接数等性能指标，能够全面掌握Neo4j集群的运行状况，及时发现和解决性能瓶颈，确保数据库系统的高效、稳定运行。
监控工具集成
在生产环境中，建议将Neo4j集群的监控数据集成到企业级监控平台，实现统一的可视化和告警管理。可以通过Prometheus、Grafana、Datadog等主流监控工具，自动采集Neo4j暴露的JMX指标和Metrics Endpoint数据，并以图表、仪表盘等形式直观展示集群的运行状态、资源使用、复制延迟、事务性能等关键指标。通过灵活配置告警规则，当检测到如核心成员失去多数派、只读副本复制延迟过高、节点资源耗尽等异常情况时，系统能够第一时间自动通知运维人员，便于及时响应和处理潜在故障。结合自动化监控与告警机制，不仅可以提升集群的可观测性和运维效率，还能有效降低因故障导致的业务中断风险，保障Neo4j集群的高可用性和稳定运行。
定期检查
定期检查是保障Neo4j集群长期健康运行的重要措施。建议运维团队制定周期性的健康检查计划，定期对集群的各项关键功能进行全面测试。例如，可以定期模拟单个或多个节点的故障，观察集群的自动故障转移和恢复机制是否能够按预期工作，确保在实际发生故障时系统能够快速响应并保持高可用性。此外，建议定期审查和分析集群的日志文件，包括neo4j.log、debug.log等，主动查找潜在的异常、警告或性能瓶颈，及时发现并解决隐患问题。通过自动化脚本或监控平台，定期采集和比对集群成员状态、资源使用、复制延迟、事务性能等核心指标，能够帮助团队及时掌握集群的运行趋势，提前预警可能影响业务的风险。结合定期的健康检查、日志审查和自动化监控，可以有效提升Neo4j集群的稳定性和可靠性，为关键业务系统提供坚实的数据支撑。
通过有效的集群管理和全面的监控，可以最大限度地提高Neo4j因果集群的可用性和性能，确保关键业务应用的连续运行。
9.5 小结
Neo4j因果集群提供了强大的高可用性和扩展性，适用于需要高并发读取和写入的应用场景。通过合理配置核心服务器、只读副本以及监控机制，可以构建一个稳定可靠的分布式数据库系统。
在本章中，我们详细介绍了Neo4j因果集群的配置和管理，包括核心服务器的设置、只读副本的添加与配置、集群状态监控以及故障排查与恢复等关键内容。通过这些实践，用户可以有效地构建和维护一个高可用、高性能的Neo4j集群环境，满足复杂业务场景下的数据存储和查询需求。