分布式系统的复杂性是工程师和开发人员面临的重大挑战。复杂性随着系统的增长而增加，积极主动地管理至关重要。本文探讨分布式系统的复杂类型以及应对其影响的有效策略，如：网络不可靠性：超时、重试、幂等性、熔断器等策略可以减轻风险。并发和丢失写入：快照隔离、比较和设置、租约等技术可以解决这些问题。双写问题：事务发件箱、日志尾随等解决方案可以保持数据一致性。不可靠的时钟：时间对齐至关重要，ntp同步和精确时间协议提供了解决方案。可用性和一致性：cap定理强调可用性和一致性之间的权衡，分布式共识算法（如raft）在保持一致性方面至关重要。通过掌握这些策略和策略，工程师和开发人员可以自信地应对分布式系统的复杂性，确保系统的可靠性、可扩展性和可维护性。
分布式系统的复杂性是工程师和开发人员面临的重要挑战。复杂性往往会随着系统的发展而增加，因此积极主动非常重要。让我们来谈谈您可能会遇到哪些类型的复杂性以及在工作中应对它的有效策略。
分布式系统和复杂性
在开发过程中，分布式系统是相互连接并处理单个任务的计算机网络。每台计算机或节点都有自己的本地内存和处理器，并运行自己的进程。然而，他们使用一个共同的网络来进行协调和集中化。分布式系统非常可靠；一个组件的故障不会破坏整个网络。
在集中式计算系统中，一台计算机具有一个处理器和一个内存来解决问题。在中心化系统中，有节点，但它们访问中心节点，这会导致网络拥塞和缓慢。集中式系统存在单点故障——这是它的一个重要缺点。
复杂
复杂性可以从不同的角度和方面来定义。有两个重要的主要定义。
在系统理论中，复杂性描述了系统的不同独立部分如何相互作用和相互通信：它们如何定义彼此之间的相互作用，它们如何相互依赖，它们有多少依赖关系，以及它们在整体中如何相互作用。
从软件和技术的角度来看，复杂性是指软件架构的细节，例如组件的数量。
整体架构
单体架构是集中式系统的一个很好的例子。它被表示为单个可部署且单个可执行的组件。例如，此类组件可能包含用户界面和位于一处的不同模块。
尽管这种架构是构建软件的传统架构，但它有几个重要的缺点：
无法独立扩展模块
越来越难以控制日益增长的复杂性
缺乏模块独立部署
维护庞大的代码数据库具有挑战性
技术和供应商的耦合
微服务架构
微服务架构是一种架构风格，也是面向服务的架构的一种变体，它将系统构建为松散耦合服务的集合。例如，公司、帐户、客户和 UI 表示为部署在多个节点上的单独进程。
所有这些服务都有自己的时时共享数据库，但这可能是一种不好的做法或反模式。
这种架构有一些优点。
水平可扩展性是游戏规则的改变者！您可以水平扩展数据库，也可以水平扩展服务。从技术上讲，任何基础设施组件都可以通过克隆进行水平扩展，但必须解决许多挑战。
高可用性和容忍度：每当您有多个克隆时，您都可以组织一些技术来帮助您避免因崩溃、内存泄漏或断电而导致的任何停机。
地理分布：如果我们在美国、欧洲或亚洲都有客户，并且我们也希望为客户带来最好的体验，那么我们需要将这些服务分布在世界各地，并组织更复杂的数据复制技术。
技术选择：您可以自由选择您的解决方案。
质量属性
任何系统在某种程度上都具有三个主要质量属性：
1、可靠性：尽管面临挑战，仍能继续正常运行，这意味着具有容错性或弹性；即使系统现在可靠运行，也不能保证未来的可靠性。性能下降的一个常见原因是负载增加：例如，系统可能已从 10,000 个并发用户扩展到 100,000 个并发用户，或者从 100 万个扩展到 1000 万个。
2、可扩展性是我们用来描述系统处理增加的负载的能力的术语。值得注意的是，整个系统的可扩展性弱点是由其最薄弱的组件决定的。
3、可维护性是为了让需要使用系统的工程和运营团队的生活变得更好。良好且稳定的抽象有助于降低复杂性，并使系统更容易修改和适应新的使用功能。
主要问题是什么？
“任何可能出错的事情都会出错，而且是在最糟糕的时候出错。”
— 墨菲定律
不可靠的网络
网络不可靠的原因有很多，例如：
您的请求可能已丢失。
您的请求可能正在队列中等待，稍后会发送。
远程节点可能发生故障（可能崩溃或断电）。
远程节点可能暂时停止响应。
远程节点可能已经处理了您的请求，但是响应已在网络上丢失。
远程节点可能已经处理了您的请求，但响应已延迟，将稍后传送。
策略：暂停
该问题最简单的解决方案是在调用方应用超时逻辑。例如，如果调用者在超时后没有收到响应，它只会抛出错误并向用户显示错误。
策略：重试
在规模化的情况下，我们不能为每个网络问题抛出异常，从而让用户感到不快或延迟系统执行。因此，如果响应表明出现问题，只需重试即可。但如果服务器处理了请求，但只有响应丢失了怎么办？在这种情况下，重试可能会导致严重后果，例如多个订单、付款、交易等。
策略：幂等性
为了避免这种情况，我们可以利用一种名为幂等性的技术。
幂等性的概念涉及多次执行相同操作与仅执行一次具有相同效果的概念。为了实现一次语义的属性，可以采用将幂等密钥附加到请求的解决方案。使用相同的幂等密钥重试相同的请求时，服务器将验证具有此类密钥的请求是否已被处理，并且将简单地返回先前的响应。因此，使用相同密钥进行任意次数的重试不会对系统的行为产生有害影响。
策略：熔断
另一种可能有助于防止过载并在发生故障时完全破坏服务器的模式是断路器。
断路器充当代理，以防止正在维护的呼叫系统可能会出现故障，或者现在严重故障。出错的原因有很多：内存泄漏、代码中的错误或出现故障的外部依赖项。在这种情况下，最好是快速失败，而不是冒着级联失败的风险。
并发和丢失写入
并发性是分布式系统中最复杂的挑战之一。并发意味着多个计算同时发生。
因此，当尝试通过不同的操作同时更新帐户余额时会发生什么？如果没有防御机制，很可能会出现竞争条件，这将不可避免地导致写入丢失和数据不一致。在此示例中，两个操作试图同时更新帐户余额。由于它们是并行运行的，因此最后一个完成的操作将获胜，从而导致一个重大问题。为了解决这个问题，可以采用各种技术。
策略：快照隔离
ACID 缩写代表原子性、一致性、隔离性和持久性。所有流行的 SQL 数据库都实现了这些属性。
原子性指定操作要么完全执行，要么失败，无论发生在哪个阶段。它可以让我们确保另一个线程无法看到操作的半完成结果。
一致性意味着所有不变量都已定义，并且在成功提交事务和更改状态之前都将得到满足。
ACID 意义上的隔离意味着并发执行的事务彼此隔离。有一个可序列化的隔离级别，它是顺序处理所有事务的最严格的级别，但主要使用流行数据库中称为快照隔离的另一种级别。
持久性承诺一旦事务提交，所有数据都会被安全地存储。
此级别的关键思想是数据库跟踪记录的版本，并且无法提交已在当前事务之外修改的版本的事务。
策略：比较并设定
大多数 NoSQL 数据库不提供 ACID 属性，而是选择 BASE，此类数据库会进行比较并使用集合。此操作的目的是避免丢失更新，方法是仅当值自上次读取后未发生更改时才允许更新。如果当前值与您之前读取的值不匹配，则更新无效，必须重试读取-修改-写入循环。
例如，Cassandra 提供轻量级事务，允许您利用各种IF、IF NOT EXISTS和IF EXISTS条件来防止并发问题。
策略：租赁
另一个潜在的解决方案是租赁模式。为了说明这一点，请考虑必须以独占方式更新资源的场景。租赁模式需要首先获取具有资源到期期限的租约，然后更新它，最后返回租约。
如果发生故障，租约将自动到期，从而允许另一个线程访问该资源。尽管此技术非常有益，但存在进程暂停和时钟不同步的风险，这可能会导致并行资源访问出现问题。
双写问题
双写问题是分布式系统中出现的一个挑战，特别是当多个数据源或数据库必须保持同步时。为了说明这一点，请考虑一个场景，其中新数据必须存储在数据库中并将消息发送到 Kafka。由于这两个操作不是原子的，因此在发布新消息的过程中存在失败的可能性。
如果在发送消息时尝试进行事务处理，则会出现更成问题的情况。如果事务无法提交，外部系统可能已经被告知实际上没有发生的更改。
策略：交易发件箱
一种潜在的解决方案是实施事务发件箱。这涉及将事件存储在与操作本身相同的事务内的“OutboxEvents”表中。由于该过程的原子性，如果事务失败，则不会存储任何数据。
另一个必要的组件是 Relay，它会定期轮询 OutboxEvents 表并将消息发送到目的地。这种方法可以实现至少一次交付保证。不过，这并不是问题，因为由于网络不可靠，所有消费者都必须是幂等的。
策略：日志尾随
构建自定义事务发件箱的替代解决方案是利用数据库事务日志和自定义连接器直接从此日志读取并将更改发送到目的地。
这种方法有其自身的优点和缺点。例如，它需要与数据库解决方案耦合，但允许在应用程序中编写更少的代码。
不可靠的时钟
时间跟踪是任何软件或基础设施的一个基本方面，因为它可以强制执行超时、到期和指标收集。然而，时钟的可靠性在分布式系统中是一个重大挑战，因为时间的准确性取决于单个计算机的性能，而单个计算机的时钟可能比其他计算机更快或更慢。
计算机使用的时钟有两种主要类型：时钟和单调时钟。时钟根据特定日历返回日期和时间，并且它们通常与网络时间协议 (NTP) 同步。然而，延迟和网络问题可能会影响同步过程，导致时钟不同步。单调时钟不断前进，使它们适合测量持续时间。
然而，单调增加的值对于每台计算机都是唯一的，限制了它们在多服务器日期和时间比较中的使用。实现高精度时钟同步是一项具有挑战性的任务。在大多数情况下，这种解决方案的必要性并不明显。然而，在需要遵守法规的情况下，可以使用精确时间协议，尽管这将需要大量投资。
可用性和一致性
CAP定理 假定任何分布式数据存储只能满足三个保证中的两个。然而，由于网络不可靠性不是一个可以显着影响的因素，因此在网络分区的情况下，唯一可行的选择是在可用性或一致性之间进行选择。
考虑这样的场景：两个客户端从不同的节点读取数据：一个从主节点，另一个从从节点。复制配置为在领导者更改后更新追随者。但是，如果领导者出于某种原因停止响应，会发生什么情况？
这可能是崩溃、网络分区或其他问题。在高可用系统中，必须分配一个新的领导者，但我们如何在现有的追随者之间进行选择？为了解决这个问题，必须采用分布式共识算法。然而，在深入研究该算法的细节之前，有必要全面了解各种类型的一致性。
一致性类型
用于描述保证的一致性主要有两类。
弱一致性，或者最终是弱一致性，意味着如果您停止对领导者进行更改，在一段时间后所有追随者的数据将同步。
强一致性是一种确保系统中的所有节点同时看到相同数据的属性，无论它们访问哪个节点。
策略：分布式共识算法（例如Raft）
回到leader崩溃时的问题，需要选举一个新的leader。这个问题乍一看似乎很简单，但实际上，在选择适当的方法时必须考虑很多条件和权衡。
根据 Raft 协议，如果追随者在指定的时间内没有从领导者那里收到数据或心跳，则开始新的领导者选举过程。每个复制单元（整体写入节点或多个分片）都与一组 Raft 日志和操作系统进程相关联，这些进程维护日志并将更改从领导者复制到追随者。
Raft 协议保证跟随者按照领导者生成的顺序接收日志记录。一旦一半的关注者确认收到提交记录并将其写入 Raft 日志，用户事务就会在领导者上提交。
策略：从领导者那里读出
一种可能有效且简单的策略是由刚刚保存新数据的用户从关注者那里读取数据以避免复制滞后。
结论
从整体架构到微服务，每种方法都有自己的优势和挑战。虽然整体架构提供了简单性，但它们经常在可扩展性和可维护性方面遇到困难，迫使开发人员转向更加模块化和可扩展的微服务架构。
讨论的核心是复杂性的管理，复杂性表现为各种形式，从网络不可靠性到并发问题和双重写入问题。超时、重试、幂等性和断路器等策略提供了有效的工具来减轻与不可靠网络相关的风险，而快照隔离、比较和设置以及租约等技术则解决了并发和丢失写入的挑战。
此外，时钟不可靠这一关键问题凸显了分布式系统中精确时间同步的重要性，解决方案包括从 NTP 同步到精确时间协议。此外，CAP 定理提醒我们可用性和一致性之间的固有权衡，因此需要彻底了解 Raft 等分布式共识算法。
总之，掌握分布式系统的复杂性需要采取多方面的方法，将理论知识与实践策略相结合。通过采用这些策略并不断适应分布式计算不断发展的格局，工程师和开发人员可以自信地应对复杂性，确保系统在面对不断变化的挑战时的可靠性、可扩展性和可维护性。
以上就是分布式系统：常见陷阱和复杂性的详细内容，更多请关注小编网其它相关文章！
