吵闹邻居启示录的生存策略-CSDN博客

概括

Meenakshi Jindal 通过 Netflix 资产管理平台的案例研究讨论了他们如何检测并幸免于吵闹邻居的经验教训.

简介

Meenakshi Jindal 是一位经验丰富的软件工程师，在银行、保险、旅游和媒体等多个行业的软件设计和实施方面拥有超过 15 年的经验。她专注于设计高性能、可扩展且可靠的分布式系统，以促进 Netflix 工作室和内容生态系统内的无缝集成.

关于会议

软件正在改变世界。 QCon 通过促进开发人员社区中知识和创新的传播来增强软件开发能力。 QCon 是一个由从业者驱动的会议，专为影响团队创新的技术团队领导、架构师、工程总监和项目经理而设计.

信息活动

现场网络研讨会和问答
2024 年 4 月 11 日下午 1 点（美国东部时间）
构建用户元数据系统以实现弹性和可扩展性

主讲人：Sean Chittenden（DoorDash 前架构师）、Cockroach Labs 高级工程总监和 Chris Casano - Cockroach Labs 销售工程总监

由蟑螂实验室赞助

金达尔：十年前，我搬到了圣地亚哥。经过一段时间的寻找，我终于找到了一套干净、漂亮的公寓。我非常兴奋。它有很多共享设施，我认为我的家人和朋友来拜访我们时都可以使用这些设施。还有一位吵闹的邻居，名叫肖恩。他只是喜欢参加聚会。那个周末的大部分时间，他的朋友过来并拿走了所有共享设施。最后我们非常沮丧，最终决定搬出去。您一定在想我为什么要与大家分享这个故事。吵闹的邻居不仅仅局限于现实生活中，现在它已经成为我们多租户分布式架构中的一个常见问题。我在这里谈论一些生存策略，以避免我们的租户搬迁这一剧烈步骤，这对于我们的多租户平台非常重要。单租户，每个应用程序都有自己的计算、基础设施、数据库和满意的场景，但如果您准备好为此付费，它就会带来成本。多租户，又可以进一步分为两种类型。第 1 类，每个应用程序都有自己的计算和基础设施，但数据库不同，数据关注点分离。类型 2，应用程序共享计算、基础设施和存储。每个都有其自己的优点和挑战。我们将讨论多租户类型，这确实是我们将要讨论的嘈杂邻居问题的唯一变量。什么是吵闹的邻居？一个应用程序试图独占系统资源，从而为平台上的其他租户造成停机、性能下降、性能下降。可以为此做出什么贡献？请求阈值增加，负载消耗资源。我们最喜欢的一个，我们的一位客户的脚本错误，导致我们的平台陷入困境.

我将分享一些来自 Netflix 资产管理平台的吵闹邻居故事。它是一个集中式平台，被 80 多个工作室应用程序使用，用于存储、跟踪、组织、发现、分发您在制作或后期制作工作流程中可以想到的数百万数字资产。资产对于制作非常重要，因为它对最终内容有独特的贡献。一项资产可以由一个应用程序创建，但可以由许多其他应用程序发现以拼接最终内容。这就是我们刚刚看到的类型 2 的原因，它支持生产工作流程中多个应用程序对资产的全局发现。内容创作者是媒体行业的支柱。想象一下，如果这个平台无法访问，将会在生产世界中造成混乱和沮丧。他们花费数小时创建媒体并将其上传到系统，上传后，资产就无法被发现。想一想，他们迷路了。我应该怎么办？我应该再次尝试上传吗？我的资源是没有上传还是丢失了？如果这个平台不可靠，他们就会迷失。准备好踏上 Netflix 媒体资产管理工作幕后世界的激动人心之旅吧。什么是媒体资产？它可以是单个资产，如视频、音频、图像、多 3D 内容，也可以是复合资产的巨型树，如相机胶卷，它是一棵树中数百个资产的逻辑分组。你一定在想，我为什么要和你分享呢？我们稍后再讨论.

该平台采用分布式架构设计。该平台的顺利运行进一步依赖于 Netflix 的许多其他组件，例如存储、存档和许多其他媒体处理服务，例如编码、检查、镜头变化分析以及您可以想到的在视频上运行的许多其他分析。引入该平台的每项资产都会经过验证过程，然后将其引入不同的数据库，例如 Cassandra，这是我们的主要事实来源。 Elasticsearch支持实时资产发现。 Iceberg，或者你可以说分析数据库，它支持数据科学工程用例以获取仪表板内的资产，或者通过机器学习平台发现这些资产，以构建或训练他们的数据模型。每个资产操作都会创建一个资产更改事件，该事件将由该工作流管理服务侦听。根据资产状态的变化，触发各种技术和业务工作流程，这进一步引发了Netflix的许多其他微服务。您是否遇到过您的稳定平台突然变得缓慢、无响应的情况？调试后，您意识到有一个流量进入您的平台并在您的稳定平台中产生噪音？这发生在我们身上。去年，一个遗留应用程序开始将其资产从孤立的应用程序迁移到这个集中式平台，以便其他所有应用程序都可以发现这些资产。这导致到处都有很多警告。可以看到有些实例变成了警告状态，有些实例变成了红色状态。最终结果，启示录：到处都是警报。许多服务都受到了影响。正如您所看到的，我们开始从我们的服务和依赖的服务中获取警报，一些服务开始下降，一些服务变得缓慢.

寻呼机，谁喜欢寻呼机？我们希望通过我们的警报而不是受到影响的客户来寻呼。在本次演讲中，我们将分享如何避免来自客户的寻呼机以及我们应该自己寻呼。一种嘈杂的交通导致了共享基础设施的灾难。这可能会导致广泛的速度减慢、崩溃、中断、系统故障、性能下降、不可用。最终结果是应用程序不满意并失去信任。对于任何平台来说，最重要的是，您希望为所有租户提供一个可靠的平台，并再次避免租户从您的平台搬迁的剧烈步骤.

他们将这些策略分为三类：预防性策略、诊断性策略和纠正性策略。有哪些预防策略？这些是我们在设计应用程序期间采取的积极步骤，以确保我们为所有租户提供可靠且稳定的平台。首先也是最重要的，预测并提供资源。您需要深入了解您的架构以及租户的需求，才能配置资源。您必须配置应用层和基础设施层的资源。这一切看起来都很简单，我们称之为自动缩放。自动扩展为我们的基础设施提供了弹性，可以根据平台上的负载进行扩展和缩减。是什么导致设置这些自动扩展策略变得困难？资源不是无限的。您无法无限扩展，您需要知道自动扩展的限制。了解这些限制后，您需要了解依赖的基础设施限制和依赖的服务阈值。您想要进行扩展，但您希望以不损害整体系统运行状况的方式进行扩展。数据库。在我们现代的分布式架构中，大多数应用程序都尝试使用分布式数据库。我们尝试设计数据分区策略，使数据分布在分布式数据库的多个节点上。问题总会发生，尤其是当你想要扩大规模时。你们中有多少人经历过这样的情况：您想要扩展数据库，尝试水平扩展，但效果不佳？唯一增加的是您的成本，即基础设施的成本。没有得到改进的是您正在寻找的性能。调试之后，你发现了什么？你有热点。您的系统中有热点。你有墓碑。什么是热点？当您进行扩展时，有人遇到过数据库中的热点问题吗？数据库的一个子集经历高活动，大多数读写都将发送到数据库中的特定节点。无论您进行多少扩展，都不会提高或影响您所寻求的性能。墓碑。对于分布式数据库，有时当您尝试删除文档时，它们不会立即删除该文档，而是将其标记为要删除。如果您不仔细注意，并且在流程中以删除文档并创建文档的方式进行设计，那么它可能会增加您的墓碑。墓碑开始慢慢增加。它们对于性能和存储来说非常沉重。现在问题来了，您将如何检测设计中的这些问题。相信我，这些问题不会出现在您的正常流量中，只有当您的平台上出现流量高峰时，它们才会出现。检测此类情况的唯一方法是使用负载测试。您应该尝试使用预期的正常流量和高流量对系统进行负载测试，以便在设计中查明这些问题。如果您找到它，您就不会希望在您的生产中出现 oops 场景。你想提前修复它。您可能必须重新设计数据分区策略，或者可能必须重建框架。这是你必须做的。你必须避免最后的世界末日.

线程是计算的关键资源之一，它帮助我们进行并行处理，使我们能够用更少的资源获得更好的性能。当我们开始设计应用程序时，我们只使用一个资源池。会发生什么？慢慢地，我们开始注意到某些操作存在延迟。我们更多的是一个读取繁重的应用程序，写入也很繁重，但它们更多的是尖峰流量，因为想一想，镜头来自相机胶卷，并且它们试图一次性创建大量资产，然后安定下来。我们不希望写入流量激增而导致正在进行的读取产生延迟。它应该为读取客户端提供预期的延迟。然后，我们做了什么？我们开始按照服务层中的操作以这种方式划分线程池，以便操作中的一个峰值不会为同一实例上的其他操作造成资源争用。如前所述，请求可以作为一项资产提出，也可以批量提出。我们不希望用户一次创建一项资产，因此我们为他们提供了批量 API。他们可以选择将资产批量加载到我们的系统中。这可能会导致其他小块请求的资源争用。例如，如果我的系统收到在一项操作中创建 500 个资产的请求，同时又收到创建 50 个资产或 5 个资产的请求，如果您没有对它们进行分块，那么就必须等待在处理 50 或 5 项资产之前，先处理 500 项资产。我们做什么？我们将批量请求分成小块，然后单独处理它们，这样无论您的操作流量有多大，我们都会给出预期的延迟。这有助于我们避免再次垄断系统上一个租户的资源并为其他租户造成资源争用.

使用发现服务管理依赖关系。对于分布式数据库，我们应该始终尝试使用发现服务来连接整个平台中的不同微服务。它帮助我们分配负载并实现服务之间的无缝通信。你们中有多少人正在使用发现服务来连接到您的数据库？或者您正在使用节点连接到数据库。这发生在我们身上。我们直接使用节点，因为以前版本的 Elasticsearch 支持连接到数据库。流量出现尖峰，为该特定客户端提供服务的主节点之一重新启动。然后负载转到副本，但连接到该特定节点的实例向用户提供超时。在该副本上，已经从 x 到 10x 的请求现在变成了 30x。该副本也随着 CPU 峰值而重新启动。该副本出现故障，另一个副本开始为客户端提供服务。将会发生什么？这个重启链将持续下去，直到流量稳定下来，或者客户端的重试稳定下来。您希望如何避免它，通过使用发现服务和正确的套接字超时设置集，以便您的客户端不会看到这些超时并且不会重试，这已经是峰值了。您希望流量留在那里。通过超时设置，发现服务应将流量从故障转移节点重定向到正常节点。现在我们开始进行这种练习，同时如果可能的话连接到大多数数据库.

重试是好的，但并不总是如此。如果您不遵循良好的重试实践，您实际上可以创建重试雷暴。重试有时会放大系统和下游服务的问题。当您已经处于这种尖峰负载流量之下时，如果您只是重试，那么服务实际上可能会崩溃或哭泣。如何解决这个多级重试的问题呢？在您的服务中，我们可以有一个集中的位置来处理异常，而不是将逻辑散布到各处，该位置将接受调用，我应该重试此异常还是应该停止？或者，如果您要重试，我们应该在重试时尝试使用随机指数退避，这样我们就不会以类似的模式使下游服务过载。尽管如此，尤其是在交通繁忙和邻居吵闹的情况下，情况可能会变得更糟。您的服务可能能够在嘈杂的流量中幸存下来，但其中一项依赖的服务陷入了某种糟糕的状态。重试只会让事情变得更糟。不仅是该服务，现在因为您的服务资源因对该服务进行 I/O 调用而被占用，并且您正在重试，您的服务也会缓慢地看到资源争用，并开始为正在调用的服务提供超时你，一连串的失败。那时你怎么能给予你想要的东西呢？你想要深呼吸，你希望下游服务也深呼吸。你会怎么做？断路器。让您的服务和下游服务有机会深呼吸并恢复。在此模式中，当您的服务在调用下游服务时注意到请求或错误数量时，如果达到错误阈值，它只会打开电路。这意味着不会调用下游服务。在定义的重置时间后，它会尝试将少量调用传递回下游服务。如果它是健康的，那么它就会关闭断路器并允许拨打电话。如果它仍在尝试恢复，则它会将断路器保持在打开状态，并且不会进一步调用下游服务.

拥抱最终一致性。 Lily提到了他们如何从同步工作流程转向异步工作流程，非常关键。并非所有其他请求都被设计为同步的。尝试将可用性置于一致性之上。我们还注意到，如果资产是由 UI 应用程序创建的，则有一个用户坐在屏幕后面，他们希望立即看到资产已上传。如果资产是通过批量工作室协调器管道上传的，他们不想立即看到它，并且可以异步。我们将该流量分为两部分：同步流量和异步流量。它使我们能够在不影响依赖组件的情况下扩展系统。它还可以帮助我们优雅地康复。这意味着您的消息会被缓冲，以便在依赖组件可用时可以重试。您的最终用户正在寻找的是我上传了一些资产，并且应该在最后上传。他们不想立即看到它，但他们正在寻找应该完成的保证.

通过正确的预防策略，我们可以避免吵闹的邻居带来的连锁影响，但现实世界中仍然会出现问题。我们都在从中学习。那时我们需要的是诊断策略。这是一套可观察性的技术、一套流程，帮助我们快速发现问题并及时采取纠正措施。想象一下你自己坐在作战室里，此时你到底在寻找什么？我的系统发生了什么？当问题在我的系统中出现时，为什么会出现此问题？或者这个问题对我的整个系统有多大影响，因为只有你才能接听这个电话，那时我应该做什么？可观察性可帮助您实时了解系统健康状况和性能。您需要将监控、警报和发现完美结合起来。监控是收集来自系统的不同指标集。警报是在违反特定阈值时通知您，因为您希望及时收到警报，以便采取纠正措施。发现是追踪请求，以及它如何在分布式架构中流经系统。因为问题可能不是由其他客户端引起的，可能是由于您的配置本身引起的，您推出了一些部署，但它是不正确的，并且可能会影响整个流量。您想要发现在系统请求流程中问题到底发生在哪里.

我们想要收集不同类型的指标。有些是已知的，有些是由我们的云提供的，例如 CPU 利用率、磁盘使用率、网络、磁盘空间，但有些是特定于您的应用程序的。因为您知道特定操作的预期延迟是多少。您知道您正在寻找哪些依赖服务，以及什么类型的错误消息可以，什么类型不可以。您还想设置一些自定义指标，以及云中开箱即用的默认指标。数据库。数据存储指标非常重要。它包括集群健康状况、节点健康状况、索引RPS、查询RPS。我们为什么要在这里寻找数据存储指标？原因是，应用程序可以扩展，但数据库却不能。扩展数据库是一个非常耗时的过程。当您最需要它时，它不会在几秒钟或几分钟内发生。你必须做好准备。如果您仔细监控您的数据存储，因为您的应用程序、系统在不断发展，它们的要求也在不断发展。您可能会注意到，数据存储已经处于高峰使用状态，如果您会观察数据库状态并提前收到警报，那么您可以徒手扩展它，而不必等待该问题在生产中发生，因为如果你试图在生产中解决这些问题，成本将会非常高。如何识别热点？如果您尝试查看数据存储的指标，您可以立即识别出有一些特定节点正在注意到 CPU 峰值，但总体 CPU 使用率却非常低。非常仔细地检查数据存储的运行状况指标.

日志至关重要，非常重要。你们中有多少人记录了上下文？每当我开始寻找任何遗留应用程序时，我总是会抛出一堆文件，查看这些文件，系统中发生了什么？你真的能从这些日志中找出任何东西吗？这非常耗时。如何提高速度来弄清楚系统中发生了什么？通过添加正确的上下文。现在，对于所有应用程序，我们不仅记录来自应用程序的事件，还记录每个事件的上下文。它来自哪个租户。什么是分布式追踪ID？请求 ID 是什么？仅当您在这些事件中放置正确的上下文时，这些日志才有用，以便您可以立即弄清楚系统上哪个租户正在发生什么情况。同时，日志很昂贵，但它们对于调试至关重要。我们怎样才能解决这个问题呢？我并不是说您应该启用系统中的所有日志，因为在流量高峰期间，您的磁盘使用率将会出现峰值，并且您的节点将会崩溃。我们如何解决正确的日志集之间的平衡问题？您需要系统具有在运行时启用或禁用日志的功能。有些人正在进行动态调试。动态调试是什么意思？动态调试意味着您可以控制系统，当您意识到存在流量并且该特定服务出现峰值时，我想知道发生了什么。我只想打开该特定服务的信息日志。 Java 世界和不同的语言对它的称呼不同，但它们为您提供了在运行时启用这些日志的灵活性.

分布式跟踪对于分布式架构非常重要，正如我们注意到的，问题可能发生在请求处理流程的任何地方。您想要查明确切的故障点或处理延迟的位置，以便您可以检查服务中的特定点。特别是在多租户架构中，当您收集或检测指标时，您是否曾经尝试过使用租户 ID 来检测它？这是非常关键的。您可以感受到我在说什么，因为当您尝试解决问题时，您想知道谁在影响我的系统。流量峰值可能并未突破您的系统阈值，但有一个沉默的租户坐在那里，正在受到影响，因为他们的请求模式与进入您平台的峰值流量一致。如果您有租户 ID 和指标，您可以立即说该特定租户的响应时间有所延迟，尽管只有 4.1% 并且只有一个客户端，但所有其他客户端对您的平台都同样重要。你必须尊重它。通过查看此内容，如果您注意到一个租户出现响应时间缓慢的情况，您应该能够修复它。错误率和请求率相同.

我们讨论了很多关于指标、不同类型的指标，我们注意到，并且我们收集了不同类型的指标。如果您坐在作战室中，打开多个指标选项卡，您会思考您正在做什么。我正在寻找什么，实际上，我打开了 10 个选项卡、20 个选项卡，然后我来回切换，哪个操作看到了延迟？错误率看起来是多少？我要找哪个租户？打开这么多标签后，您会迷失方向，您会失去连接，失去您想要建立的东西。你可以弄清楚，但这需要时间。你想要的是快速行动。快速确定哪个租户在我的系统中造成了问题，以及谁在我的系统中受到了影响？您希望在仪表板上的聚合视图（称为仪表板）上拥有一组正确的过滤器，其中包含许多过滤器，例如什么是集群？有什么应用？延迟是多少？可能是p99，说我是正确的，但有1%说我不正确。您想找出您系统中不正确的那 1% 是什么。有了这组正确的过滤器，我们就可以找出哪些操作受到噪音流量的影响以及如何修复它.

警报。我确信您一定在系统中设置了很多警报。非常关键。警报必须及时设置并根据上下文进行操作。去年，我拥有一个遗留应用程序。我收到警报，午夜寻呼机。我醒了，我试着环顾四周。我打开笔记本电脑，检查系统的运行状况，看起来很好。我检查了系统日志，没有问题。我回去睡觉，30分钟后我再次收到警报。我再次打开笔记本电脑，试图去喝咖啡，好吧，这是我缺少的东西。我没有找到正确的上下文。试着环顾四周，我什么也没弄清楚。我应该怎么办？我只是暂停闹钟，我想睡觉。我暂停了警报，然后又回去睡觉了。第二天早上，每个人都在看着我，你推迟警报了吗？好吧，我该怎么办？第二天早上，我深入研究了系统，我们发现，该警报是很久以前设置的。错误警报中设置的阈值不再相关，因为平台上的流量已经是 20 倍，并且错误百分比非常低。这里有什么学问？警报很好，但是您在系统中设置的所有其他警报都不要指望您的值班人员知道您系统的进出情况。您应该在警报中添加正确的上下文，该警报是关于什么的，如果您收到该警报，可操作的项目是什么。另外，如果可能的话，尝试将一些链接放入您的警报、仪表板链接或一些文档链接中。因为当您坐在作战室时，当您收到警报时，寻呼机对您来说意义重大。你想快速解决它。其步骤、策略是什么？将正确的操作、正确的上下文和正确的链接放入您的警报中，以便任何获得寻呼机的人在 5 分钟内应该能够知道我的系统中发生了什么.

通过我们讨论的诊断和预防策略，希望我们的系统能够对所有租户保持可靠和稳定，但生活会发生变化。在现实世界中，这并不是一个令人愉快的场景。我们需要什么？纠正策略。纠正策略，使我们的平台可靠。我们需要在我的系统中实施优雅的降级措施。在此过程中，您需要深入了解您的系统架构。我记得其中一位实习生加入了我们，他收到一条警报，称发生处理延迟并且任务队列深度正在增长。第一件事，你做了什么？扩展您的系统。他扩展了我们的系统。它做了什么？它最终给我们的系统带来了更多的负载峰值。该峰值是由我们系统上产生的 10,000 个图像请求造成的。对于引入我们系统的每个其他图像资产，我们根据工作流程为每个图像创建 4 个缩略图。通过扩大这 10,000 个请求，他最终在平台上创建了 40,000 个以上的资产创建请求，而这 10,000 个请求最终成为我们平台上的 40,000 个请求，到处都是更多的级联故障。在采取任何行动之前，请确保您对系统架构有深入的了解。通过采取任何纠正措施，您的行为不会对您的平台产生任何连锁影响.

减速。如果您发现存在特定的租户请求，这会在您的系统上产生负载，您希望减慢速度。如果您使用异步消息处理，一种方法是，您可以将来自该特定租户的流量从主堆栈引导到辅助堆栈，然后慢慢开始处理它。它还会影响来自该租户的合法流量。您希望向您的客户传达我们将减慢对您的请求的处理速度。这发生在我们的案例中。当我们将此问题反馈给客户时，他们立即发现他们这边存在一些配置问题。他们修复了配置设置并减慢了我们系统中的 RPS，并且我们将流量从租户的备份步骤移回到主要步骤。仅当异步处理该特定请求时，这才有可能。如果您尝试同步处理请求，则必须采取严厉措施来限制请求。这是你最不想做的事，但我们必须这么做，别无他法。您想要定义租户资源配额，限制来自该租户的请求处理速率，并限制来自该租户的并发数。减速。您想再次与用户沟通。确保在限制请求时将正确的异常消息发送回客户端。因为有可能，他们不知道到底发生了什么。您真的限制了他们的请求还是您的服务器超时了？他们可能会将其视为某些服务器错误，对于这 30 个请求，他们将重试并为您提供 60 倍。发回正确的消息组，以便他们应该明白他们不应该重试，他们应该安定下来，放慢速度.

我们通过这些策略学到的可靠架构有哪些收获？定期评估您的系统要求。事情在变化，系统在变化。我们的要求在变化，同时我们的客户要求也在变化。确保定期评估您的系统要求并更新您的资源配置：服务器端、数据库端的资源配置。提高可观察性。这是分布式架构的一个关键方面。从第一天起你就应该考虑你的可观察性。问题总会发生，你无法拒绝。通过提高可观察性，您可以快速识别这些问题并及时修复。分析临时警报。永远不要忽视任何临时发生的事情。它们是你未来潜在失败的指标。他们试图给你一个信号，如果你的系统中出现尖峰，它会哭泣，会流血。确保明智地分析传入系统的任何警报。它不一定是立即发生的，但您可以进行一些事件响应并检查，例如，过去一周我的系统中发生了什么？花一些时间担任待命支持人员，以提高平台的可靠性。自动优雅地恢复。每次手动干预都需要时间。这将减慢问题的解决速度。如果您可以自动化这些事情，那么您就可以在更短的时间内解决这些问题，而无需寻呼待命人员。与租户应用程序的协作和知识共享非常重要。我们还提到了合作。这是我们忽略的最大关键点。我们正在构建一个平台，但为谁构建？对于我们的租户申请。如果我们不了解我的租户正在寻找什么，他们对我的平台的预期 SLO 是什么，那么我就无法构建一个可靠的平台。事情可能会改变。如果您进行沟通，如果您与他们合作，那么您就知道我的路上有预期的流量，并且您将相应地配置资源。当您尝试构建供客户端应用程序使用的任何平台应用程序时，协作和知识共享非常重要.

话虽如此，可靠的架构不仅仅是一个一次性的过程。这是一个持续的旅程。我们都在学习。我看到很多曲目，其中我们大多数人都在谈论可靠性、可观察性。每个人都在谈论他们的学习并分享他们的知识。很好，从中吸取教训，从你的事件中吸取教训。每一种嘈杂的交通都会带来其独特的挑战和学习。确保你从每一次发生的事件中锻炼自己的力量。它将帮助您为未来发展您的平台。通过诊断策略，如果您试图找出根本原因，如果您发现有一些可以改进的地方，请确保当时或稍后执行。不要将其保留在积压工作中以供以后完成。以后都会这样，别人又会看你的，你为什么不做呢？为什么你刚刚在上面创建了一个积压项目？如果您正在采取任何短期解决方案来解决问题，并且您将采取这种解决方案，因为流量的影响是如此之长，以至于您想要采取一些短期解决方案，请确保将其移至长期解决方案长期解决方案。想一想，从长远来看，我怎样才能避免类似的情况，并尝试设计你的解决方案。尽量避免客户端应用程序出现这种情况。您想为他们提供一个可靠且稳定的平台，您可以做到。学习并将其纳入预防策略中，以便您的系统可以自动执行这些故障并优雅地自行恢复，而不是尝试寻呼某人并花时间来修复它.