我们在前面的文章中，探索了多种可能的系统扩展方式，以及每种扩展方式的优劣。

本篇文章将通过具体的架构设计方案来对每一种方案的设计、投入产出比、各项指标与功能，以及孰优孰劣等进行评价。

在设计高性能、高可用图数据库的时候，从单实例、单节点出发，一般有3种架构演进选项：主备高可用、分布式共识和大规模水平分布式。我们都知道这3套系统的实现复杂度是从低到高渐进的，但这并不意味着复杂度更高的系统在不同的应用场景、用户需求、查询模式、查询复杂度、数据特征条件下就能获得更好的效果。

作为未来的图数据库架构师、用户或爱好者，我们希望每一位读者都能在架构选型时冷静、清醒地分析自己所面临的挑战，找到最适合的解决方案。

一、主备高可用

最简单的高可用数据库是从单实例扩增为双实例的，仅两个实例又可以分化出多种角色扮演：
·单实例（A）负责读写，另一实例（B）负责备份；
·单实例（A_）负责读写，另一实例可以参与读操作负载；
·双实例都支持读写，互为备份。
在以上的第一种角色扮演中，实例A负责承载全部的客户请求，而实例B在一般情况下并不与客户端发生直接互动，它只负责被动接受实例A的备份请求。
只有当实例A因故下线的时候，实例B才转为上线，开始承载客户负载。
事实上，即便是这样看似简单的主备模式，还有很多细节值得考虑，例如：
·A、B实例之间的通信如何保证可靠？
·当一个实例下线的时候，如何使得另一实例转为上线？
对上面两个问题，答案的探寻会引出网络化、分布式系统架构设计的“潘多拉之盒”——除非我们能确定网络是100%可靠的，且A和B上运行的程序和数据是100%安全可靠的，否则，确定A到B或B到A通信可靠及数据可靠就是一件颇为复杂的事情。
因为当A向B发送备份信息后，如何确定B收到信息并完成了备份操作呢？
我们希望B向A发送一条回执，甚至两条回执，其中一条来表达收到（ACK）​，另一条来表达已完成（ACK+DONE）​。但是，我们是否需要让B也知道A已经收到回复了呢？这个回复再回复的通信过程可以变成一种死循环依赖。下图1就形象地示意了造成两军无限通信（同步）问题的具体情形。

 两军通信问题是拜占庭将军问题的一个简化版本（一种特例）​，它表达了一种在任意通信失败前提下无法达成系统一致性的可能性。

在实际的工程实践中，我们只能在一定程度上规避极端情况的发生，例如TCP协议中的3次握手建立网络连接与4次握手终止网络连接的方案，只能假设在大多数情况下网络是可靠的，A、B实例上运行的程序是具有完整性的。两军通信问题告诉我们任何系统都存在不可靠性，这也是为什么我们会用“几个9”的方式来衡量一个系统的稳定性，例如5个9（99.999%）的在线率，我们也见过一些公有云服务对外称有11个9的稳定性（相当于3 000年才会出现一次离线1s的故障）​，然而只要拔掉1到2根网线或者终止一两个进程就可以让整个系统下线。笔者不确定人类创建的任何计算机系统是否能够50年无故障，毕竟还没有任何系统用满了50年。
 

如果把双实例继续演化，则可以构造至少3个实例的集群，如下图2所示：

当主备系统有3个实例（A、B、C）的时候，它们之间的通信就变得更复杂了，有至少8种（2×2×2）可能的互动方式。通常，我们会从最简单的主备实现方式开始，即仅从A向B与C单向同步数据，当A下线后，在B与C中选择（手工或自动切换）一个实例作为新的主节点承担客户端发送请求。

但是，当A再次上线后，依然存在需要从B或C中反向输出、同步数据的问题。在B成为主实例的期间，若C下线，则集群中仅B在线，依然可以提供服务，但这种情况下已经不再是高可用的系统。

另一种较为常见的，在一定程度上负载均衡的主备系统实现如图5-13b所示，即主实例承载全部的读写操作，其他实例负载均衡所有来自客户端的读操作，以及同步来自主实例的备份操作。

在主备模式的系统架构中，一个大的假设前提是在任意一个时间切片中至少有一个实例存有全量的、最新的数据。如果这个前提不能被保证，则当前系统的数据一致性已经受到破坏（另一种可能是该系统并非以主备模式运行，后续会进行探讨）​。

主备系统的架构还可以演化出同城灾备、异地灾备等模式。异地灾备模式如图3所示，在这种模式中，通常只有一个集群在线工作，另一个集群则整体被动地接受同步数据。从某种程度上看，这样的系统进行了高度的冗余化设计，至少在写入操作的时候，只有1/6的节点在工作，而其他5/6的节点进行数据同步，并且是分为两个阶段的数据同步，即2/6主集群内的实例与1/6副集群内的主实例进行第一阶段同步，副集群内的另外2/6实例进行第二阶段同步。在第一阶段的同步过程中，副集群的主实例的同步完成时间因为网络距离、网络带宽的限制而存在更大的延迟，很多时候我们会忽略这种延迟。在实际的30公里同城双数据中心中，光线路传播就耗时0.0001s，即0.1ms，如果是一个折返操作，则会耗时0.2ms，两个折返通信，则在通信线路上就至少耗时0.4ms，这在真正的高性能系统设计中已经是一个不可忽略的时耗了。

这也是为什么在很多交易场景中消费者会明显感受到秒级的延迟，因为在较长通信线路上，光折返通信就可能存在零点几秒的延迟，外加多套业务系统，例如反欺诈系统的多个规则的运行以及事务型交易处理的完全提交，约2s的延迟是极为正常的。也正是因为这些通信延迟，图数据库线上化（低延迟）​、高并发（高负载）地处理海量数据的能力就显得尤为可贵，毕竟高维数关联、聚合、深度穿透计算的复杂度要显著高于传统数据库的低维、浅层计算的复杂度。

下篇继续聊关于分布式共识系统的文章。最近很忙，不过老夫会尽快更文。

· END ·

（文/Ricky - HPC高性能计算与存储专家、大数据专家、数据库专家及学者）