网站有中文源码加英文怎么做温州网络网

当前位置： 首页 > news >正文

网站有中文源码加英文怎么做,温州网络网,城阳网站建设公司,江西网站设计电话在构建分布式系统时#xff0c;分布式协调是否总是必要选项#xff1f;本文通过一些实际的例子讨论了这一问题#xff0c;并通过把问题区分为是否具有单调性做为是否需要分布式协调的标准。原文: Avoiding Coordination Cost: Three Patterns for Building Efficient Distri… 在构建分布式系统时分布式协调是否总是必要选项本文通过一些实际的例子讨论了这一问题并通过把问题区分为是否具有单调性做为是否需要分布式协调的标准。原文: Avoiding Coordination Cost: Three Patterns for Building Efficient Distributed Systems 在这篇文章中我们将讨论一个在分布式系统经常会遇到的问题(需要协调协议实现程序一致性)探讨为什么这会成为一个问题(其对可伸缩性、性能和可用性的影响)什么样的系统不需要考虑这一问题其背后简单的直观属性(单调性)以及三个可以用来构建更高效分布式系统的简单模式。本文是基于我从Joseph M. Hellerstein和Peter Alvaro撰写的一篇题为Keeping CALM: When Distributed Consistency is Easy的论文中得出的结论。 准备好开始这段旅程了吗在正文之前我们先从一个现实世界的类比开始。 现实世界的类比: 在旅行中为了对徒步路线达成一致而进行的协调 有一次我和家人预定了一块露营地。就在旅行的前一天我的两个朋友想带着家人和我们一起旅行。我预定的露营地已经被订满了但他们在附近的两个露营地订到了位置。所以到了旅行的那天我们到达了各自的露营地(相隔几英里)。 到目前为止一切顺利。第二天早上我们意识到有个问题: 我们还没有讨论/同意当天的计划。 我们需要协调当天的计划这需要系统中所有参与者的投入。 我们需要决定去附近的哪个地方徒步。 要进行任何协调首先需要一个协调协议(co-ordination protocol) 。分布式系统需要协调协议的原因是为了实现程序的一致性(program consistency) 。在上述情况中我们使用的协调协议是通过电话提出并讨论徒步选项这里的程序一致性目标是对我们当天要进行哪一次徒步达成一致。 听起来很简单彼此打个电话决定地点对吧幸运的是我的露营地有很好的网络连接我的一个朋友(朋友#1)似乎在他的露营地也有很好的网络连接所以我打电话给他提出了徒步A的想法而他说服我应该去徒步B。但是我们都联系不上2号朋友也没有他的消息他的营地没有网络连接造成了网络分区。因此我们还不能决定徒步B作为最终计划因为来自朋友#2的输入可能会改变最终计划。 好吧欢迎来到非单调(non-monotonic)系统。 问题在于需要协调 以上就是需要协调的情况的一个例子而且是在关键路径(critical path) 上在这个例子中如果我们提前约定上午9点在徒步B的入口见面可能就没有问题了。 正如本文所描述的协调协议使自治、松散耦合的机器能够共同决定如何控制基本行为许多分布式系统利用这种协调协议来实现预期的程序结果有许多流行的协议如Paxos和两阶段提交。 然而这可能会带来很高的成本从而影响系统的可伸缩性(假设我们的朋友是10个而不是3个)、可用性(我们在等待朋友#2的时候被耽搁了)和性能(我们本可以把时间花在探索风景上)。 什么时候真正需要协调? CALM论文提出了一个基本问题: 哪些问题可以在不需要协调的情况下以分布式方式被一致的计算哪些问题位于该问题家族之外? 需要和想要之间是有区别的系统真的需要使用协调协议吗还是可以在设计时就不使用协调协议 本文描述了系统的一个非常简单和直观的性质: 单调性(monotonicity)它决定了是否需要协调。下面让我们看看这是什么意思。 关键思想: 逻辑单调性(Logical Monotonicity) 为了理解单调性让我们从反论开始: 什么时候一个系统不是单调的? 我们已经在上面的例子中看到了一个: 即使我和朋友#1已经同意了我们还是不能继续选择徒步路线因为来自朋友#2的输入可能会改变最终结果。这是一个非单调系统的例子其中系统不能基于部分或不完整的信息做出最终决策。 分布式垃圾收集: 非单调系统的另一个例子 CALM论文将分布式垃圾收集作为一个非单调系统的例子。每个节点上都有一组对象节点中有一个根对象根对象可以引用其他对象对象可以引用其他节点中的对象。在这样的系统中多个本地垃圾收集器应该如何协同工作以确定哪些对象不可访问 论文中的图2: 具有远程引用的分布式对象引用图(虚线箭头)。可以在没有来自机器3的任何信息的情况下建立对象O3可从Root访问的事实。只有在获得全局信息是才能知道对象O5和O6是垃圾。 节点需要交换关于边的信息。但是本地垃圾收集器不能自主做出决定必须进行协调最初机器3可能确定对象O4不可达。但稍后可以从机器1接收到新的信息证明其可达性: 通往O4的路径(Root - O1 - O3 - O4)。和上面露营的例子类似在做决定之前需要听取每个人的意见这是一个需要协调的例子。 该论文提出了非单调系统的另一个含义: 因为这样的系统基于新的信息改变他们的想法/决定他们对信息的顺序敏感也就是说接收信息的顺序很重要。 分布式死锁检测: 单调系统的一个例子 现在让我们看看单调是什么意思可以归结为: 基于部分或不完整信息做出的决定是否仍然稳定基于部分信息得出的结论是否仍然具有偶然性 论文以单调系统为例介绍了分布式死锁检测。假设在分布式数据库的不同节点上运行事务希望检测死锁: 例如在一个循环中事务T1持有锁L1正在等待另一个节点上事务T2持有的锁而该节点又在等待L1被释放。 论文中的图1: 具有复制节点和分区边界的分布式等待图。这里有两个循环:一个只在机器1局部({T1,T2})另一个跨越机器1和机器2({T1,T3})。 与垃圾收集示例类似这里的节点必须不断交换信息。但是一旦机器接收到帮助它确定有一个循环的信息即使还没有从其他节点接收到任何信息也可以自信的确定有一个循环这里就不需要协调如果它从更多节点接收到新的信息可以了解更多的循环但不会改变存在一个循环的事实。换句话说输出随输入单调增长。 这种单调系统的另一个重要好处是顺序并不重要每个参与者可以以任何顺序接收信息输出只取决于输入的内容。 单调性给我们提供了一种不需要协调实现一致性的方法 CALM论文的关键洞见在于如果一个系统在逻辑上是单调的我们可以通过不需要协调的方式实现一致性。论文将其描述为: 定理1。逻辑单调的一致性(Consistency As Logical Monotonicity, CALM)。当且仅当程序是单调的时它才具有一致的、无协调的分布式实现。 论文介绍了单调程序在信息缺失的情况下是如何安全的并且可以在没有任何协调的情况下继续执行。但在非单调程序中当接收到新信息时结果可能会发生变化这需要引入协调并导致参与者在等待此类信息时停机。 但是一致性在这里到底是什么意思呢让我们看看CALM论文是如何定义一致性的。 程序一致性 我们得到了期望的系统结果吗? CALM论文没有局限于存储级别一致性而是缩小了范围并关注程序一致性: 程序是否产生了期望的结果它提出了一个很实际的问题: 尽管系统在运行时存在不确定性但程序是否产生了确定性的结果? 它把这种程序一致性称为合流(Confluence)。在上面旅行的例子中这意味着所有朋友都对当天要去哪里徒步得出了相同的结论不管通过不可靠的电话网络交换信息的顺序和时间是否确定。 收获: 如何基于上述内容构建高效分布式系统? 就构建系统的实际模式而言上述内容有什么意义 1. 尽可能使用单调编程模式 单调模式并不是构建高效分布式系统的唯一方法但如果可以将系统建模为单调模式那么就可以在不需要协调的情况下获得程序一致性的好处。 论文中提到的一个简单例子是使用tombstone来删除存储系统中的数据项(直接删除将是非单调结构)。相反将一个项标记为已删除(tombstoning)将使其成为一个单调结构具有tombstone的数据项单调的从未定义转换为已定义值并最终被删除。 论文中介绍的另一个例子是Dynamo论文中的Amazon购物车。为了获得逻辑单调性将购物车状态建模为两个不同的集: 一个集是添加到购物车的商品集另一个集是从购物车中删除的商品集这使得购物部分是单调的而结帐部分是非单调的。 2. 能否在关键路径上保持协调 如果应用程序不能以单调的方式构建那么就需要协调。但是评估一下是否能让其远离关键路径。 例子: 在上面的徒步旅行例子中我们可以避免在关键路径上的协调(例如在前一天晚上协调好)。对于分布式垃圾收集器示例由于它可以在后台执行因此所需的协调不在关键路径中。在Amazon Dynamo论文中的购物车场景中协调仅限于结账(与向购物车中添加和删除物品相比结账具有不同的用户期望)。 3. 是否可以对不一致进行补偿(道歉) 能容忍系统不一致吗 如果可以的话就可以避免协调成本。 论文中的一个例子是关于在电商网站上订购商品: 当进行购买时库存中的商品数量应该立即减少从而确保显示为可购买的商品确实可用。但这需要各种系统之间的协调和集成如库存、供应链和购物。如果没有做到这一点购买可能就会失败。然而可以通过一封道歉电子邮件和优惠券进行补偿。这个建议也让我想起了Gregor Hohpe的著名文章星巴克不使用两阶段提交。 总结 CALM(Consistency As Logical Monotonicity)方法介绍了构建高效分布式系统的不同方法。通过利用单调性属性可以以不需要协调的方式实现程序一致性。此外还提出了一个很好的问题即一致性是否在所有情况下都是必须的目标(例如是否可以使用补偿行动)或者是否可以从关键路径上移除。 所以当下次我和朋友去露营的时候相信我会探索以上所有选择:) 你好我是俞凡在Motorola做过研发现在在Mavenir做技术工作对通信、网络、后端架构、云原生、DevOps、CICD、区块链、AI等技术始终保持着浓厚的兴趣平时喜欢阅读、思考相信持续学习、终身成长欢迎一起交流学习。 微信公众号DeepNoMind - END - 本文由 mdnice 多平台发布