图数据库 | 17、高可用分布式设计（上）

我们在前面的文章中，探索了多种可能的系统扩展方式，以及每种扩展方式的优劣。
本篇文章将通过详细的架构设计方案来对每一种方案的设计、投入产出比、各项指标与功能，以及孰优孰劣等进行评价。
在设计高性能、高可用图数据库的时候，从单实例、单节点出发，一样平常有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所示：
   

     图2： 主从备份系统示意图 a）一样平常情势 b）负载均衡情势   
当主备系统有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，这在真正的高性能系统设计中已经是一个不可忽略的时耗了。
   

     图3：异地（灾备）主从备份系统示意图   
这也是为什么在很多交易场景中消费者会显着感受到秒级的耽误，由于在较长通信线路上，光折返通信就可能存在零点几秒的耽误，外加多套业务系统，例如反敲诈系统的多个规则的运行以及事件型交易处置惩罚的完全提交，约2s的耽误是极为正常的。也正是由于这些通信耽误，图数据库线上化（低耽误）​、高并发（高负载）地处置惩罚海量数据的能力就显得尤为可贵，毕竟高维数关联、聚合、深度穿透计算的复杂度要显著高于传统数据库的低维、浅层计算的复杂度。
下篇继承聊关于分布式共识系统的文章。近来很忙，不过老夫会尽快更文。

· END ·

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

 

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。