重庆网站推广平台,网站链接安全检测,网站设计模板免费下载,wordpress获取文章链接地址我们在前面的文章中#xff0c;探索了多种可能的系统扩展方式#xff0c;以及每种扩展方式的优劣。
本篇文章将通过具体的架构设计方案来对每一种方案的设计、投入产出比、各项指标与功能#xff0c;以及孰优孰劣等进行评价。
在设计高性能、高可用图数据库的时候#xf…我们在前面的文章中探索了多种可能的系统扩展方式以及每种扩展方式的优劣。
本篇文章将通过具体的架构设计方案来对每一种方案的设计、投入产出比、各项指标与功能以及孰优孰劣等进行评价。
在设计高性能、高可用图数据库的时候从单实例、单节点出发一般有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另一条来表达已完成ACKDONE。但是我们是否需要让B也知道A已经收到回复了呢这个回复再回复的通信过程可以变成一种死循环依赖。下图1就形象地示意了造成两军无限通信同步问题的具体情形。 两军通信问题 两军通信问题是拜占庭将军问题的一个简化版本一种特例它表达了一种在任意通信失败前提下无法达成系统一致性的可能性。
在实际的工程实践中我们只能在一定程度上规避极端情况的发生例如TCP协议中的3次握手建立网络连接与4次握手终止网络连接的方案只能假设在大多数情况下网络是可靠的A、B实例上运行的程序是具有完整性的。两军通信问题告诉我们任何系统都存在不可靠性这也是为什么我们会用“几个9”的方式来衡量一个系统的稳定性例如5个999.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高性能计算与存储专家、大数据专家、数据库专家及学者
