产品展示

分布式系统的问题

  近几章次要引见系统若何处置错误。例如,我们会商了副本毛病转移,复制畅后和事务的并发节制。当我们理解现实系统中可能呈现的各类鸿沟环境时,我们就能更好地处置它们。

  前几章虽然谈论了良多关于错误的问题,可是仍是太乐不雅了。正在本章中,我们将最悲不雅地假设“任何可能出毛病的,最终城市出毛病”。

  分布式系统编程取正在单机上编写软件有素质区别次要区别正在于分布式系统中有良多别致的可能出毛病的体例。 本章中,我们将领会正在实践中呈现的问题,并领会哪些我们能够依赖,哪些不可。

  最初,做为工程师,我们的使命是建立可以或许完成工做的系统(即满脚用户所期望的包管),虽然各个部件都犯错了。 正在第9章中,我们将看看能够正在分布式系统中供给这种包管的算法的一些示例。 但起首,正在本章中,我们必需领会我们面对的挑和。

  本章是对分布式系统中可能呈现的问题的悲不雅和沮丧的概述。 我们将研究收集问题(第277页的“不靠得住的收集”); 时钟和时序问题(第287页上的“不靠得住的时钟”); 我们将会商它们能够避免的程度。 所有这些问题形成的后果城市让人利诱,因而我们将切磋若何思虑分布式系统的形态以及若何推理已发生的工作(第300页的“学问,本相和假话”)。

  当你正在单机上写法式时,它凡是会以一种可预测的体例运转:要么一般工做,要么无法工做。有bug的软件可能会让人感觉电脑出问题了(凡是从头启动就能处理问题),但大部门仍是软件写得欠好的后果。

  没有什么底子缘由能让单机上的软件表示得奇异:当硬件一般工做时,不异的操做老是发生不异的成果(这是确定性的)。若是存正在硬件问题(例如,内存损坏或毗连器松动),其后果凡是是整个系统失效(例如“蓝屏死机”,无法启动)。具有优良软件的单机凡是功能无缺或完全损坏,而不正在两者之间。

  这是计较机设想中的一个慎沉选择:若是发生内部毛病,我们甘愿计较机完全解体,而不是前往错误的成果,由于错误的成果很难处置,而且令人迷惑。因而,计较机躲藏了它们实现所依赖的恍惚物理现实,并提出了一个抱负化的系统模子,它能够取数学完满连系起来。CPU指令老是做同样的工作; 若是你将一些数据写入内存或磁盘,则该数据连结无缺而且不会随机损坏。 这种一直准确计较的设想方针能够逃溯到第一台数字计较机。

  当你编写运转正在多台计较机上并通过收集毗连的软件时,环境完全分歧。 正在分布式系统中,我们不再处于抱负系统模子中 - 我们别无选择,只能面临物理世界的紊乱现实。 而正在现实世界中,正如这个轶事所示,各类各样的工作可能会犯错:

  正在我无限的经验中,我处置过单个数据核心(DC)中的长时间收集分区,PDU(配电单位)毛病,互换机毛病,整个机架的不测电源毛病,全DC从干毛病,全DC 电力毛病和一位低血糖驾驶员将他的福特皮卡撞进空调系统。我以至不是一个运维人员。Coda Hale

  正在分布式系统中,可能呈现如许的环境,虽然系统的其他部门工做一般,但系统的某些部门可能会以某种不成预知的体例出毛病。这就叫做部门毛病。该问题的难点正在于部门毛病是不确定的:若是你试图做任何包含多个节点和收集的工作,它可能有时工做一般,有时呈现不成预知的毛病。正如我们将要看到的,你可能以至不晓得某件事能否成功,由于动静正在收集中传布所破费的时间也是不确定的!

  规模的一端是高机能计较(HPC)范畴。拥无数千个CPU的超等计较机凡是用于计较稠密型科学计较使命,如气候预告或分子动力学(模仿原子和分子的活动)。

  另一端是云计较,云计较没有很是明白的定义,但凡是取多租户数据核心,毗连IP收集的商品计较机(凡是是以太网),弹性/按需资本分派以及按时计费联系正在一路。

  有了这些哲学,处置错误的方式就很是分歧了。正在超等计较机中,功课凡是会对其计较形态不时地做查抄点到持久存储上。若是一个节点发生毛病,凡是的处理方案是简单地遏制整个集群工做负载。毛病节点修复后,从上一个查抄点从头起头计较。因而,超等计较机更像是一台单节点计较机而不是分布式系统:它通过升级为完全毛病来处置部门毛病 - 当系统的任何部门发生毛病,简单地让整个系统解体(就像单机上的内核发急一样)。

  正在本书中,我们沉点引见实现互联网办事的系统,这些系统凡是看起来取超等计较机有很大分歧:

  很多取互联网相关的使用法式都是正在线的,正在某种意义上它们需要可以或许随时为用户供给低延迟办事。办事不成用(例如,遏制群集以进行修复)是不成接管的。比拟之下,像气候模仿如许的离线(批处置)功课能够遏制并沉启,并且影响很小。

  超等计较机凡是由公用硬件建立,此中每个节点都很是靠得住,而且节点通过共享内存和近程间接内存拜候(RDMA)进行通信。另一方面,云办事中的节点是由通俗机械建立的,它们能以较低的成本供给不异的机能,但也具有较高的毛病率。

  大型数据核心收集凡是基于IP和以太网,以Clos拓扑陈列来供给高对分带宽。超等计较机凡是利用特地的收集拓扑布局,例如多维网格和toruses,这为具有已知通信模式的HPC工做负载供给了更好的机能。

  系统越大,系统中有组件出毛病的概率越高。跟着时间的推移,毛病被修复,新的组件又出毛病,可是正在一个无数千个节点的系统中,认为系统中老是正在发生毛病是一个合理的假设。当错误处置策略不敷无效时,一个大型系统最终会破费大量的时间从毛病中恢复,而不是做有用的工做。

  若是系统能够容忍失败的节点而且仍然做为一个全体继续工做,这对于操做和维护是一个很是有用的特征:例如,能够施行滚动升级(参阅第4章),一次沉启一个节点,系统继续为用户供给办事而不中缀。正在云情况中,若是一台虚拟机运转欠安,能够将其杀死并请求一台新的虚拟机(但愿新的虚拟机速度更快)。

  正在地舆分布式摆设中(连结数据正在地舆位置上接近用户以削减拜候延迟),通信很可能通过互联网进行,取当地收集比拟,速度慢且不靠得住。超等计较机凡是假设它们的所有节点都接近正在一路。

  若是我们想让分布式系统工做,就必需接管部门毛病的可能性,并正在软件中成立容错机制。换句话说,我们需要从不靠得住的组件中建立靠得住的系统。(正如正在第6页的“靠得住性”中所会商的那样,没有完满的靠得住性,所以我们需要领会我们能够现实许诺的极限。)

  即便正在只要少数节点的小型系统中,考虑部门毛病也很主要。正在一个小型系统中,很可能大部门组件正在大大都时间都一般工做。可是,迟早会有一部门系统呈现毛病,软件将不得不以某种体例处置它。毛病处置必需是软件设想的一部门,而且软件的操做员需要晓得发生毛病时软件会呈现什么行为。

  假定错误很少发生,并只往好的想是不明智的。考虑各类可能的错误(以至是不太可能的错误),并正在测试情况中报酬地建立这些环境以查看会发生什么长短常主要的。正在分布式系统中,抱着思疑,悲不雅和偏执的立场才能取得成功。

  你可能会思疑这能否有事理曲觉上,一个系统只能和其最不靠得住的组件(它最亏弱的环节)一样靠得住。现实并非如斯:现实上,从不太靠得住的根本建立更靠得住的系统,这正在计较中是一个陈旧的设法。 例如:

  纠错码答应数字数据正在通信信道上精确传输,偶尔会呈现某些位错误,例如因为无线收集上的无线电干扰。

  IP(互联网和谈)是不靠得住的:数据包可能丢失,延迟,反复或乱序。TCP(传输节制和谈)正在IP之上供给了一个更靠得住的传输层:它确保丢失的数据包被沉传,消弭反复,而且数据包被从头拆卸为它们的发送挨次。

  虽然系统可能比其根本部门更靠得住,但它的靠得住性老是无限的。例如,纠错码能够处置少量的单比特错误,可是若是信号被干扰所覆没,那么通过通信信道能够获得的数据量就有一个根基限制。TCP能够对我们躲藏数据包丢失,反复和乱序,但它不克不及正在收集中奇不雅般地消弭延迟。

  虽然更靠得住的更高级此外系统并不完满,但它仍然很有用,由于它能够处置一些棘手的初级毛病,因而凡是也能够更轻松地处理和处置其余的毛病。

  正如正在第二部门的引见中所会商的,我们正在本书中关心的分布式系统是shared-nothing系统:即一堆机械通过收集毗连。收集是这些机械能够通信的独一体例。我们假设每台机械有本人的内存和磁盘,一台机械无法拜候另一台机械的内存或磁盘(除了通过收集向办事发出请求外)。

  shared-nothing并不是建立系统的独一体例,但它曾经成为建立互联网办事的次要体例,缘由有几个:它相对廉价,由于它不需要特殊的硬件,能够操纵商品化的云计较办事, 能够通过跨多个地舆分布的数据核心进行冗余来实现高靠得住性。

  互联网和数据核心的大部门内部收集(凡是是以太网)都是异步分组收集。 正在这种收集中,一个节点能够向另一个节点发送一个动静(一个数据包),可是收集不克不及包管它何时达到,以至能否能达到。若是你发送请求并等候响应,良多工作可能会犯错(此中一些如图8-1所示):

  你的请求可能曾经丢失(可能是或人拔掉了网线)。 你的请求可能正正在队列中期待,稍后会被发送(也许收集或收件人过载)。 近程节点可能失败(可能解体或掉电)。 近程节点可能临时遏制了响应(可能正正在履历长时间的垃圾收受接管暂停;请参阅第295页上的“历程暂停”),但稍后它会再次起头响应。 近程节点可能处置了你的请求,但响应正在收集上丢失了(可能是收集互换机设置装备摆设错误)。 近程节点可能曾经处置了你的请求,但响应曾经延迟而且将稍后发送(可能是收集或你本人的机械过载)。

  发送方以至无法晓得数据包能否曾经被发送:独一的选择是让领受方发送响应动静,这可能会丢失或延迟。这些问题正在异步收集中难以区分:你具有的独一消息是你尚未收到响应。若是你向另一个节点发送请求而且未收到答复,也无法晓得是什么缘由。

  处置该问题凡是的方式是利用超时:一段时间后就放弃期待并假设响应不会送达。可是,当发生超不时,你仍然不晓得近程节点能否收到了你的请求(若是请求仍然正在某个处所列队,它仍然可能会被传送给领受方,即便发送方曾经放弃了)。

  几十年来我们一曲正在成立计较机收集人们可能但愿现正在我们曾经晓得了若何使它们变得靠得住。可是,似乎我们还没有成功。

  有一些系统的研究和大量的轶事证据表白,即便正在由公司运营的数据核心那样的受控情况中,收集问题也可能很是遍及。正在一家中等规模的数据核心进行的一项研究发觉,每个月大约发生12次收集毛病,此中一半单台机械断开毗连,一半整个机架断开毗连。另一项研究丈量了架顶式互换机,汇聚互换机和负载均衡器等组件的毛病率,发觉添加冗余收集设备不会像你所但愿的那样削减毛病,由于它不克不及防备报酬错误(例如,设置装备摆设错误的互换机),这是形成收集中缀的次要缘由。

  公共云办事(如EC2)因屡次呈现短暂的收集毛病而名誉扫地,办理优良的公用数据核心收集会比力不变。虽然如斯,没有人可以或许避免收集问题的干扰:例如,互换机软件升级期间的问题可能会触发收集拓扑从头设置装备摆设,正在此期间收集数据包可能会延迟跨越一分钟。鲨鱼可能咬住海底电缆并损坏它们。其他令人惊讶的毛病包罗收集接口有时会丢弃所有入坐数据包,但成功发送出坐数据包。因而,仅仅由于收集链接正在一个标的目的上一般工做并不克不及包管它也正在相反的标的目的也一般工做。

  收集分区当收集的一部门因为收集毛病而取其余部门断开时,有时称为收集分区或收集朋分。 正在本书中,我们利用更一般的术语收集毛病,以避免取如第6章所述的存储系统的分区(碎片)混合。

  即便你的情况中很少发生收集毛病,但可能发生毛病的现实意味着你的软件需要可以或许处置它们。收集上的通信总有可能会失败,这是没有法子的。

  若是收集毛病的错误处置未颠末定义和测试,则可能会发生朝四暮三的错误:例如,即便收集恢复,千龙国际群集也可能会死锁并永世无法为请求供给办事,以至可能会删除你的所无数据。若是软件不正在受控的环境下,可能会成心想不到的行为。

  处置收集毛病并不必然意味着容忍它们:若是你的收集凡是相当靠得住,则无效的方式可能是正在收集碰到问题时向用户简单显示错误动静。可是,你需要晓得你的软件会对收集问题做出什么反映,并确保系统可以或许从中恢复。锐意地触发收集问题并测试系统响应是成心义的(这是Chaos Monkey背后的设法;请参阅第6页的“靠得住性”)。

  负载均衡器需要遏制向死节点发送请求。 正在single-leader复制的分布式数据库中,若是leader发生毛病,需要提拔一个follower成为新的leader(参阅第152页的“处置节点毛病”)。

  倒霉的是,收集的不确定性使得判断一个节点能否一般工做变得很坚苦。正在某些特定环境下,你可能会收到一些反馈消息,以明白告诉你某些组件纷歧般工做:

  若是你能够达到运转节点的机械,但没有历程正正在监听方针端口(例如,由于历程解体),操做系统将通过发送RST或FIN数据包来帮帮封闭或拒绝TCP毗连。可是,若是节点正在处置请求过程中解体,你将无法晓得近程节点现实曾经处置了几多数据。

  若是节点历程解体(或被办理员杀死)但节点的操做系统仍正在运转,脚天性够通知其他节点相关解体的消息,以便另一个节点能够快速接管而无需期待超时。

  若是你有权限拜候数据核心收集互换机的办理界面,则能够查询它们以检测硬件级此外链路毛病(例如,近程机械能否封闭电源)。若是你通过互联网毗连,或者你处于共享数据核心但无权限无法拜候互换机,或者因为收集问题而无法拜候办理界面,则无法利用该选项。

  若是路由器确定你测验考试毗连的IP地址无法拜候,它可能会用ICMP方针无法拜候的数据包答复你。可是,路由器不具备奇异的毛病检测能力它遭到取收集其他构成部门不异的限制。

  近程节点宕机的快速反馈很有用,但你不克不及希望它。即便TCP确认数据包已发送,使用法式正在处置数据之前可能已解体。若是你想确认一个请求是成功的,需要正在使用法式本身积极响应。

  相反,若是呈现问题,你可能会正在某个条理上获得错误响应,但凡是你必需假设底子得不到响应。你能够沉试几回(TCP沉试是通明的,但您你能够正在使用法式级别沉试),期待超时过去,而且若是正在超时范畴内没有收到响应,才最终颁布发表节点失效。

  若是超时是检测毛病的独一靠得住方式,那么超不时间该当多长?倒霉的是没有简单的谜底。

  超不时间长意味着需要长时间期待才能宣布一个节点灭亡(而且正在此期间,用户可能不得不期待或看到错误动静)。超不时间短能够更快地检测到毛病,可是会带来更高的误判的风险,例如节点可能只是临时变慢(好比因为工做或收集负载高峰)就被误判为灭亡。

  过早地宣布一个节点曾经灭亡是有问题的:若是节点现实上处于勾当形态而且正正在施行一些操做(例如,发送电子邮件),然后另一个节点接管,那么该操做最终可能会施行两次。我们将正在第300页的“学问,线章中更细致地会商该问题。

  当一个节点被宣布灭亡时,其职责需要转移到其他节点,这会给其他节点和收集带来额外的承担。若是系统曾经处于高负载形态,过早宣布节点灭亡会使问题变得更糟。出格地,可能节点现实上并未灭亡,只是因为负载太高而响应迟缓。将其负载转移到其他节点可能会导致瀑布式的失败(正在极端环境下,所有节点都宣布对方灭亡,然后一切都遏制工做)。

  假设一个虚拟系统的收集能够包管数据包的最大延迟每个数据包要么正在一段时间内送达,要么丢失,但时间永久不会跨越d。此外,假设能够包管非毛病节点正在老是正在一段时间r内处置请求。正在这种环境下,能够包管每个成功的请求城市正在2d + r的时间内收到响应,而且若是正在此时间内没有收到响应,则晓得收集或近程节点不工做。若是环境线d + r将是一个合理的超不时间。

  倒霉的是,我们所利用的大大都系统都没有这些包管:异步收集具有无限的延迟(即它们尽可能快地发送数据包,但数据包达到所需的时间没有上限) ,而且大大都办事器实现不克不及包管它们能够正在特按时间内处置请求(请参阅“响应时间包管”(第298页))。对于毛病检测,大部门时间内快是不敷的:若是超不时间较短,则往返时间只需要霎时上升就会导致系统得到均衡。

  正在开车汽车时,因为交通堵塞,正在路上花的时间往往不尽不异。雷同的,计较机收集上的数据包延迟的可变性凡是也是因为列队:

  若是多个分歧的节点同时测验考试向不异的目标地发送数据包,则收集互换机必需将它们列队并将它们逐一送入方针收集链路(如图8-2所示)。正在忙碌的收集链路上,数据包可能需要期待一段时间才能获得一个槽(这称为收集堵塞)。若是传入的数据太多以致于互换机队列填满,数据包将被丢弃,因而需要从头发送数据包,即便收集运转优良。

  当数据包达到方针机械时,若是所有CPU内核当前都处于忙碌形态,则来自收集的传入请求将被操做系统列队,曲到使用法式预备益处理它为止。按照机械的负载环境,这可能需要一段肆意长度的时间。

  正在虚拟化情况中,当另一个虚拟机正正在利用CPU核的时候,正正在运转的操做系统凡是会暂停几十毫秒。正在此期间,虚拟机无法利用收集中的任何数据,因而输入数据被虚拟机监督器列队(缓冲),这进一步添加了收集延迟的可变性。

  TCP施行流量节制(也称为堵塞避免或背压),节点限制本人的发送速度以避免收集链路或领受节点过载。这意味着以至正在数据进入收集之前,发送者也会让数据列队。

  此外,若是TCP正在某个超不时间内未获得确认(按照察看的往返时间计较),则认为数据包丢失,而且丢失的数据包将从动从头发送。虽然使用法式没有看到数据包丢失和沉传,但它确实会看到由此发生的延迟(期待超时过时,然后期待沉传的数据包获得确认)。

  一些对延迟敏感的使用法式(如视频会议和IP语音(VoIP))利用UDP而不是TCP。这是延迟的靠得住性和可变性之间的折衷:因为UDP不施行流量节制而且不沉传丢失的数据包,所以它避免了一些可变收集延迟的缘由(虽然它仍然易受互换机队列和安排延迟的影响)。

  正在延迟数据毫无价值的环境下,UDP是一个不错的选择。例如,正在VoIP德律风呼叫中,可能没有脚够的时间正在其数据将正在扬声器上播放之前从头传输丢失的数据包。正在这种环境下,沉传数据包没成心义使用法式必需用无声填充丢失数据包的时隙(导致声音短暂中缀),然后正在数据流中继续。相反,沉试发生正在人类层面。(“你能再说一遍吗?方才没声音了。”)

  所有这些要素城市形成收集延迟的变化。当系统接近其最大容量时,列队延迟的范畴很大:具有大量备用容量的系统能够轻松消化队列,而正在高度利用的系统中,很快就会排起长队列。

  正在公有云和多租户数据核心中,资本被很多客户共享:收集链路和互换机,以至每台计较机的收集接口和CPU(正在虚拟机上运转时)都是共享的。批处置工做负载(如MapReduce)(请参阅第10章)能够轻松地使收集链接饱和。因为你无法节制或领会其他客户对共享资本的利用环境,若是你身边的某小我正正在利用大量资本,收集延迟可能会变化无常。

  正在如许的情况中,你只能通过尝试来选择超不时间:正在一个耽误的周期中测试和多台机械的收集往返时间分布,以确定延迟可变性的期望。然后,考虑使用法式的特征,你能够正在毛病检测延迟取过早超时风险之间确定一个恰当的折衷。

  更好的是,系统不是利用设置装备摆设的常量超时,而是可以或许持续丈量响应时间及其变化(发抖),并按照察看到的响应时间分布从动调整超时。这能够用Phi Accrual毛病检测器完成,该检测器正在Akka和Cassandra中被利用。TCP沉传超时运转道理雷同。

  若是我们能够依赖收集来传送具有固定最大延迟的数据包,而不是丢弃数据包,那么分布式系统就会简单得多。为什么我们不克不及正在硬件级别处理这个问题,并使收集靠得住,千龙国际娱乐以便软件不必考虑这些问题?

  为了回覆这个问题,将数据核心收集取很是靠得住的保守固定德律风收集(非蜂窝,非VoIP)进行比力是很风趣的:延迟音频帧和掉话长短常稀有的。德律风呼叫需要一直较低的端到端延迟和脚够的带宽来传输语音的音频样本。正在计较机收集中具有雷同的靠得住性和可预测性不是很好吗?

  当你通过德律风收集拨打德律风时,它会成立一条线路:沿着两个呼叫者之间的整个路由为呼叫分派固定的有包管的带宽量。该线路连结占用,曲到通话竣事。例如,ISDN收集以每秒4000帧的固定速度运转。呼叫成立后,每个帧内(每个标的目的)分派16位空间。因而,正在通话期间,每一方都包管可以或许每250微秒发送一个切确的16位音频数据。

  这种收集是同步的:即便数据通过多个路由器,也不会遭到列队的影响,由于呼叫的16位空间曾经正在收集的下一跳中保留下来了。并且因为没有列队,收集的最大端到端延迟是固定的。我们称之为无限的延迟。

  请留意,德律风收集中的线路取TCP毗连很是分歧:线路是固定命量的预留带宽,正在线路成立时没有人能够利用,而TCP毗连的数据包无机会利用任何可用的收集带宽。你可认为TCP供给可变大小的数据块(例如电子邮件或网页),TCP会尽可能正在最短的时间内传输它。当TCP毗连空闲时,晦气用任何带宽。若是数据核心收集和互联网是线路互换收集,那么成立线路后能够确保最大往返时间。然而,它们并不是:以太网和IP是分组互换和谈,它们遭到列队的影响,从而导致收集无限延迟。这些和谈没有线路的概念。

  为什么数据核心收集和互联网利用分组互换?谜底是,它们针对突发流量进行了优化。一个电路合用于音频或视频通话,正在通话期间需要每秒传送相当恒定的比特数。另一方面,请求网页,发送电子邮件或传输文件没有任何特定的带宽需求,我们只是但愿它尽快完成。

  若是你想通过线路传输文件,则必需猜测带宽分派。若是你猜的太低,传输速度会不需要的太慢,导致收集容量没有利用。若是你猜得太高,线路就无法成立(由于若是无法包管其带宽分派,收集不克不及成立线路)。因而,利用线路进行突发数据传输会华侈收集容量,并导致传输不需要的迟缓。比拟之下,TCP会动态调整数据传输速度以顺应可用的收集容量。

  曾经有一些测验考试建立支撑线路互换和分组互换的夹杂收集,例如ATM。例如InfiniBand:它实现了链路层的端到端流量节制,削减了收集列队的概率,虽然它仍然可能因链路堵塞而蒙受延迟。通过隆重利用办事质量(QoS,数据包的优先级和安排)和准入节制(限速发送器),能够仿实分组收集上的线路互换,或供给统计上有界的延迟。

  假设两台电线个呼叫。通过此线路切换的每个电路都占用此中一个呼叫插槽。因而,你能够将线个并发用户共享的资本。资本以静态体例分派:即便你现正在是线路上独一的电线个插槽都未利用,你的线路仍将分派跟线路被充实操纵时不异的固定命量的带宽。

  比拟之下,互联网动态分享收集带宽。发送者合作以尽可能快地通过收集获得它们的分组,而且收集互换机决定发送哪个分组(即,带宽分派)。这种方式有列队的错误谬误,但长处是它最大限度地操纵了线路。线路成本固定,所以若是你更充实地操纵它,通过该线路发送的每个字节都更廉价。

  CPU也会呈现雷同的环境:若是你正在多个线程之间动态共享每个CPU核,则有时候一个线程必需正在另一个线程运转时期待操做系统的运转队列,因而线程可能被暂停分歧的时间长度。可是,取为每个线程分派静态数量的CPU周期比拟,这会更充实地操纵硬件(请参阅第298页的“响应时间包管”)。更高的硬件操纵率也是利用虚拟机的主要动机。

  若是资本是静态分区的(例如,公用硬件和公用带宽分派),则正在某些情况中可实现延迟包管。可是,这是以降低操纵率为价格的。换句话说,它是更高贵的。另一方面,动态资本分派下的多租户供给了更好的操纵率,所以它更廉价,但它具有可变延迟的错误谬误。

  可是,此类办事质量目前尚未正在多租户数据核心和公有云或通过互联网进行通信时可用。当前摆设的手艺无法让我们对收集的延迟或靠得住性做出任何包管:我们必需假定收集堵塞,列队和无限延迟可能发生。因而,超不时间没有“准确”的值,需要通过尝试确定。