从《金融信息系统多活技术规范》看Neo4j企业版集群技术

1. 背景

2021年2月7日，中国人民银行发布了《金融信息系统多活技术规范》（以下简称《规范》），首次将多活作为指导金融信息系统灾难恢复的标准。《规范》开篇给出了指导“多活技术”的驱动因素：

——更高的灾难恢复要求，对于主备方式，当灾难事件发生后，灾难备份系统接管业务往往需要经过较长的时间，而当前金融业务的特点对业务连续性提出了更高的要求。

——接管能力难以把控，对于主备方式，灾难备份系统在正常情况下并不承载真实业务，其真实接管能力难以有效评估，因对其接管能力的评估主要依赖于灾难恢复预案的制定、管理及演练效果，故一旦灾难发生，灾难备份系统是否可接管真实业务难以保证。

    ——单数据中心扩展受限，由于各方面的限制，单数据中心的扩展能力往往存在瓶颈，或者持续扩展能力的经济效益降低。

——资源利用率低，灾难备份系统在正常情况下不承载业务，资源浪费严重。

——技术提升，主备方式是在传统技术架构的背景下提出的，而云计算、分布式等先进技术的成熟和应用推广，为信息系统灾难恢复能力的升级提供了技术支撑。

——业务覆盖需要，对于覆盖地理范围较广的业务系统，部分用户业务接入的距离过长，可能由于处理延迟带来用户体验的下降。

简单来说，对于上述驱动因素，可以归纳为这样几个重点：多活（Active-Active)，自冗余，故障自切换，负载自均衡，流量自管理。

《规范》进一步给出了多活的内涵，及其定义：

1、多地理节点部署信息系统。 信息系统部署在多个地理节点，各地理节点的位置选择宜综合考虑电力、网络、供水等基础设施的容灾因素，包括独立的空调、电力设施、计算、网络、存储等物理资源。

2、 布局模式。 根据地理节点的相对位置不同，多活信息系统的布局模式可分为同城多活（布局模式）和异地多活（布局模式）。

3、 业务并行多点接入。 各多活子信息系统同时支持业务接入，并支持灵活调整业务接入的多活子信息系统，部分地理节点的灾难和故障不影响其他地理节点上多活子信息系统的业务接入。

4、 业务并行多点处理。各多活子信息系统同时支持处理业务逻辑，并支持灵活调整处理业务逻辑的多活子信息系统，部分地理节点的灾难和故障不影响其他地理节点上多活子信息系统的业务处理。

5、 数据并行多点存储。 各多活子信息系统同时提供数据存储，且保证其他多活子信息系统存在与业务处理结果一致、可用的数据副本。部分地理节点的灾难和故障不影响其他地理节点上多活子信息系统的数据存储。

6、 部分业务影响和及时完成业务接管。当某个多活子信息系统发生灾难或故障时，只有部分业务受到影响并需要分配到其他多活子信息系统进行处理。当发生非区域性灾难时，同城多活子信息系统可及时接管业务；当发生区域性灾难时，异地多活子信息系统可在较短时间内接管业务。

2. Neo4j 企业版发展回顾

在Neo4j企业版2.x的时候，实现的是主-从的集群模式。后来随着企业应用的增加，预见到未来双活/多活模式的技术趋势，Neo4j在众多数据库产品厂商中率先采纳并实现了Raft分布式数据处理协议，并在2016年的3.2版本中推出“因果集群”。

随后的几年中，集群技术不断完善、特性逐渐丰富，形成了完整的、面向企业级应用的集群能力。