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

分布式系统中的消息幂等性与流量控制（一）

backend 2025/7/27 20:12:52

一、引言

${"key":"auto_image_0_0","image_type":"search","type":"load_by_key"}$

在当今数字化时代，分布式系统已成为现代互联网架构的中流砥柱。随着业务规模的不断扩张和用户数量的迅猛增长，传统的单体架构逐渐暴露出其局限性，如可扩展性差、性能瓶颈明显以及单点故障风险高等问题。而分布式系统通过将一个大型系统拆分为多个小型服务，这些服务可以独立部署、扩展和维护，从而有效提升了系统的性能、可用性和可扩展性。例如，电商平台在促销活动期间，订单处理、库存管理、支付结算等功能模块被设计为分布式服务，各自承担独立的业务逻辑，协同工作以应对海量的用户请求。

在分布式系统中，消息传递是各个服务之间进行通信和协作的重要方式。然而，由于网络的不可靠性、系统故障以及并发操作等因素，消息的处理可能会出现重复或失败的情况。这就引出了消息幂等性的概念，它确保了无论消息被重复处理多少次，对系统产生的影响和结果都是一致的，就如同数学中的幂等运算一样，多次操作结果不变。比如在支付场景中，确保支付操作的幂等性可以避免用户因网络波动导致的重复支付，保障用户和商家的利益。

另一方面，随着业务流量的动态变化，分布式系统可能会面临突发的高并发请求。若没有有效的流量控制机制，系统很容易因过载而导致性能急剧下降，甚至崩溃。流量控制就像是系统的 “阀门”，通过限制进入系统的请求数量或速率，保证系统在合理的负载范围内稳定运行。例如，在秒杀活动中，通过流量控制可以防止瞬间涌入的大量请求压垮服务器，确保部分用户能够顺利参与活动，同时也为系统的稳定运行提供保障。

消息幂等性和流量控制对于分布式系统而言，就如同基石和护盾，前者保证了数据的一致性和操作的准确性，后者则守护着系统的稳定性和可用性。接下来，我们将深入探讨这两个关键概念，分析它们的原理、实现方式以及在实际应用中的最佳实践。

二、消息幂等性

2.1 幂等性的概念

幂等性最初源于数学领域，若一个函数或操作满足无论执行多少次，其结果始终保持不变，即对于任意输入$x$，都有$f(x) = f(f(x))$ ，则称该函数或操作具有幂等性。例如，取绝对值函数$y = |x|$，对$x$多次取绝对值，结果都相同，$||-5|| = |-5| = 5$ 。

在分布式系统中，幂等性被定义为：对同一个系统，使用同样的条件，一次请求和重复的多次请求对系统资源产生的影响是一致的。这意味着，无论某个操作被执行一次还是多次，系统的最终状态和结果都不会改变。例如，在电商系统中，订单支付操作如果设计为幂等的，那么即使由于网络波动等原因导致支付请求被重复发送，用户也只会被扣除一次款项，订单状态也只会从 “未支付” 变为 “已支付” 一次，而不会出现多次扣款或订单状态混乱的情况。

2.2 幂等性在分布式系统中的重要性

在分布式系统复杂的运行环境中，存在诸多因素可能导致操作的重复执行，而幂等性对于保障系统的稳定运行和数据的一致性起着不可或缺的作用，以下是一些常见场景：

网络波动：网络传输过程中可能出现延迟、丢包等问题。当客户端发送请求后长时间未收到响应，可能会重新发送相同请求。例如，在文件上传场景中，若网络波动导致上传请求超时，客户端重试上传，若服务器端没有幂等性保障，可能会出现文件被重复上传并保存多份的情况。

消息重传：在使用消息队列进行通信时，为确保消息不丢失，消息队列通常会有重试机制。如果消费者处理消息失败，消息队列会重新投递消息。例如，在订单处理系统中，订单创建消息被发送到消息队列，若消费者处理过程中出现异常导致处理失败，消息队列重传消息，若订单创建操作不具备幂等性，可能会创建多个相同订单。

服务重试机制：为提高系统的可用性和容错性，分布式系统中的服务调用往往会设置重试策略。当服务调用失败时，会自动重试。例如，在微服务架构中，一个服务调用另一个服务进行用户信息更新，如果第一次调用因网络问题失败，服务框架会自动重试，若更新操作不幂等，可能会导致用户信息被多次重复更新。

如果在这些场景下操作不具备幂等性，将会引发一系列严重问题：

数据不一致：重复执行的操作可能导致数据被重复修改或插入，从而使数据库中的数据出现不一致的情况。例如，在库存管理系统中，若扣减库存操作不幂等，可能会导致库存数量被错误地多扣减，与实际库存情况不符。

重复操作的副作用：除了数据不一致，重复操作还可能带来其他副作用。在支付场景中，重复支付会导致用户账户被多次扣款，给用户带来经济损失；在订单系统中，重复创建订单可能会导致资源浪费和业务流程混乱。

2.3 实现消息幂等性的常见方法

2.3.1 使用唯一 ID 标识请求

为每个请求生成唯一 ID 是实现幂等性的一种简单而有效的方法。通常可以使用通用唯一识别码（UUID），它是一种由数字和字母组成的 128 位标识符，具有全球唯一性。在分布式系统中，也可以采用雪花算法（Snowflake Algorithm），它能生成一个 64 位的唯一 ID，由时间戳、机器 ID、数据中心 ID 和序列号组成，在分布式环境下保证 ID 的唯一性。

服务端在接收到请求时，首先检查该请求的唯一 ID 是否已经被处理过。这可以通过在数据库中创建一张记录已处理请求 ID 的表来实现，表中包含请求 ID 字段，并将其设置为主键或唯一索引，以确保 ID 的唯一性。当新请求到达时，查询该表中是否存在相同的请求 ID。如果存在，说明该请求已经被处理过，直接返回之前的处理结果，不再重复执行业务逻辑；如果不存在，则将该请求 ID 插入表中，并继续处理请求。

例如，在一个订单创建服务中，每次接收到创建订单请求时，客户端会生成一个唯一的订单 ID（可以是 UUID 或通过雪花算法生成）。服务端接收到请求后，查询 “已处理订单 ID 表”，若该订单 ID 已存在，表明订单已创建，直接返回订单创建成功的结果；若不存在，将订单 ID 插入表中，并执行订单创建的业务逻辑，然后返回结果。这样可以有效避免因重复请求导致的订单重复创建问题。

2.3.2 基于状态机模型

将业务流程建模为有限状态机（Finite - State Machine，FSM），利用状态转换的幂等性来保证操作幂等。有限状态机包含一组状态、初始状态、输入事件以及状态转换函数。每个状态代表系统的一个特定状态，而事件触发从一个状态到另一个状态的转换。

以订单处理流程为例，订单状态可以分为 “待支付”“已支付”“已发货”“已完成” 等。状态转换规则如下：只有当订单处于 “待支付” 状态时，接收到 “支付” 事件，才能转换到 “已支付” 状态；当订单处于 “已支付” 状态时，接收到 “发货” 事件，才能转换到 “已发货” 状态。当接收到一个操作请求时，首先检查当前订单状态是否允许执行该操作。如果当前订单状态为 “已支付”，再次接收到 “支付” 请求，由于状态机定义了在 “已支付” 状态下不允许再次执行 “支付” 操作，系统会直接返回之前的结果（提示订单已支付），从而保证了支付操作的幂等性。

在代码实现上，可以使用枚举类型来定义订单状态和操作事件，通过一个状态转换表来存储状态转换规则。当接收到请求时，根据当前状态和请求的操作事件，查询状态转换表，判断是否允许进行状态转换。如果允许，则执行状态转换并更新订单状态；如果不允许，则拒绝操作并返回相应提示。

2.3.3 数据库约束与锁机制

唯一约束：利用数据库的唯一约束来保证操作的幂等性。在数据库表中，为某个字段设置唯一约束，当插入数据时，如果该字段的值已经存在，数据库会抛出唯一约束冲突异常，从而阻止重复插入。例如，在用户注册场景中，将用户的手机号码字段设置为唯一约束。当用户注册时，若数据库中已存在该手机号码对应的记录，再次插入相同手机号码的注册信息时，数据库会报错，应用程序捕获该异常并提示用户该手机号码已注册，避免了重复注册的问题。

行级锁：在进行数据更新或删除操作时，可以使用行级锁来保证幂等性。行级锁是对表中的某一行数据进行加锁，防止其他事务同时对这行数据进行修改。例如，在库存扣减场景中，当要扣减某商品的库存时，先对该商品在库存表中的记录加上行级锁。在持有锁的期间，其他事务无法对该记录进行修改，从而保证了即使有多个相同的扣减库存请求同时到达，也只有一个请求能够成功执行扣减操作，其他请求需要等待锁释放后重试，避免了库存被错误多扣减的情况。

版本号：在数据表中增加一个版本号字段，每次更新数据时，版本号递增。当接收到更新请求时，在更新语句中加入版本号条件，只有当前版本号与请求中的版本号匹配时，才允许更新数据，并在更新后将版本号加 1。例如，在用户信息更新场景中，假设用户信息表中有一个 “version” 字段。当用户第一次请求更新信息时，版本号为 1，请求中携带版本号 1。数据库检查当前记录的版本号也是 1，允许更新操作，并将版本号更新为 2。如果此时另一个相同的更新请求到达，由于数据库中版本号已变为 2，与请求中的版本号 1 不匹配，更新操作被拒绝，从而保证了更新操作的幂等性。

2.3.4 幂等 API 设计

在设计 API 时，遵循一定的设计原则可以使其具备幂等性。常见的 HTTP 方法中，GET、PUT、DELETE 通常被设计为幂等操作，而 POST 则不是幂等操作。

GET 方法：GET 方法用于获取资源，其设计初衷是不对资源进行修改，只是从服务器获取数据。无论对同一个 URL 执行多少次 GET 请求，只要资源没有被其他操作修改，返回的结果都应该是相同的，所以 GET 方法天然具有幂等性。例如，通过 GET 请求获取某个商品的信息，多次请求返回的商品信息不会因为请求次数的增加而改变。

PUT 方法：PUT 方法用于更新资源，当使用 PUT 方法更新资源时，如果每次请求的内容相同，且更新操作是基于资源的唯一标识进行全量替换，那么 PUT 操作是幂等的。例如，使用 PUT 请求更新用户的邮箱地址，请求中包含用户 ID 和新的邮箱地址。只要每次请求的用户 ID 和新邮箱地址不变，无论执行多少次 PUT 请求，最终用户的邮箱地址只会被更新为指定的新地址，不会出现多次更新导致不同结果的情况。

DELETE 方法：DELETE 方法用于删除资源，当根据唯一标识删除资源时，DELETE 操作是幂等的。例如，根据订单 ID 删除订单，无论执行多少次 DELETE 请求，只要订单 ID 对应的订单存在，最终结果都是该订单被删除，再次执行删除操作时，虽然可能返回 “资源不存在” 的提示，但不会对系统状态产生额外影响，所以 DELETE 操作在这种情况下是幂等的。

POST 方法：POST 方法通常用于创建新资源，每次执行 POST 请求都会创建一个新的资源实例，所以 POST 方法不是幂等的。例如，使用 POST 请求创建一个新的订单，每执行一次 POST 请求，都会在数据库中插入一条新的订单记录，多次执行会创建多个不同的订单，结果与请求次数相关。

2.3.5 消息队列中的幂等消费

在消息队列中，实现幂等消费可以确保即使同一条消息被多次投递，对系统产生的影响也只相当于消费一次。

消息去重：消息队列可以在消息进入队列时，对消息进行去重处理。一种常见的做法是为每条消息生成一个唯一的标识（如消息 ID），消息队列在接收消息时，检查该消息 ID 是否已经存在于队列中。如果存在，则丢弃该消息，不再进行后续的投递和处理；如果不存在，则将消息加入队列并进行正常处理。例如，Kafka 可以通过自定义拦截器实现消息去重功能。在消息发送端，生成消息时为每条消息添加唯一的消息 ID。在 Kafka Broker 端，通过拦截器检查消息 ID，若已存在则丢弃消息。

持久化确认：消费者在处理完消息后，向消息队列发送确认信息，表明该消息已被成功处理。消息队列在收到确认信息后，才将该消息标记为已消费。如果消费者处理消息失败或者超时未确认，消息队列会重新投递消息。为了保证幂等性，消费者在处理消息时，需要确保即使多次处理同一条消息，对业务系统的影响也是一致的。例如，RabbitMQ 中，消费者在处理完消息后，可以通过 basicAck 方法向 RabbitMQ 服务器发送确认消息。RabbitMQ 接收到确认后，会从队列中删除该消息。如果消费者在处理消息过程中崩溃，未发送确认消息，RabbitMQ 会重新将该消息投递给其他消费者或者在原消费者恢复后重新投递。

2.3.6 补偿事务中的幂等性

以 TCC（Try - Confirm - Cancel）模式为例，这是一种补偿性事务模式，在分布式事务处理中被广泛应用，其中每个阶段都需要保证幂等性。

Try 阶段：Try 阶段主要是对业务资源进行预留或锁定，为后续的 Confirm 或 Cancel 操作做准备。Try 阶段的操作需要设计成幂等的，即无论调用多少次，其结果应该是相同的。例如，在一个分布式转账场景中，Try 阶段需要冻结转出账户的资金。当接收到转账请求时，首先检查转出账户的资金是否已经被冻结（可以通过数据库记录或状态标识来判断）。如果已经被冻结，直接返回冻结成功的结果，不再重复冻结资金；如果未被冻结，则执行冻结操作，并记录冻结状态。

Confirm 阶段：Confirm 阶段用于真正提交事务，执行实际的业务操作。在这个阶段，也需要保证幂等性。继续以上述转账场景为例，Confirm 阶段需要将冻结的资金从转出账户扣除，并转入到转入账户。在执行扣除和转入操作前，检查该转账操作是否已经完成（同样可以通过数据库记录或状态标识判断）。如果已经完成，直接返回转账成功的结果，不再重复执行转账操作；如果未完成，则执行转账操作，并更新转账状态。

Cancel 阶段：Cancel 阶段用于在事务执行失败时，对 Try 阶段预留的资源进行释放或回滚。Cancel 阶段同样要保证幂等性。例如，在转账失败需要回滚时，Cancel 阶段需要解冻转出账户被冻结的资金。在执行解冻操作前，检查资金是否已经被解冻。如果已经被解冻，直接返回解冻成功的结果；如果未被解冻，则执行解冻操作，并更新解冻状态。

三、流量控制

3.1 流量控制的概念

流量控制是分布式系统中至关重要的一环，它旨在对进入系统的请求速率和流量大小进行有效的限制与管理。在分布式系统中，各个服务通过网络相互通信协作，共同处理来自不同客户端的大量请求。然而，系统的资源（如 CPU、内存、网络带宽等）是有限的，若在某一时刻，大量请求毫无节制地涌入系统，就可能导致系统资源被迅速耗尽，从而引发一系列严重问题。

流量控制就像是系统的 “调节阀”，通过设定合理的规则和阈值，确保系统在可承受的负载范围内稳定运行。它可以根据系统的实际情况，动态地调整对请求的处理方式，如限制每秒的请求数量、限制并发请求数或者根据系统资源的使用情况来动态调整流量限制等。例如，在一个电商平台的秒杀活动中，通过流量控制可以限制每秒进入秒杀系统的请求数量，避免瞬间大量的请求将服务器压垮，保证部分用户能够正常参与秒杀活动，同时也为系统的稳定运行提供了保障。

3.2 流量控制的重要性

在高并发场景下，系统面临着巨大的流量压力，如果没有有效的流量控制机制，很容易陷入困境，出现一系列严重问题：

资源耗尽：高并发请求会迅速消耗系统的各类资源。大量的请求可能导致 CPU 使用率飙升，达到 100%，使系统无法及时处理其他任务；内存也可能被快速占用，导致内存溢出错误（OOM），使系统崩溃。在数据库层面，高并发的数据库查询和写入操作可能会耗尽数据库连接池资源，导致后续请求无法获取数据库连接，进而无法完成数据操作。

响应缓慢：随着请求数量的不断增加，系统的处理能力逐渐达到极限，新的请求需要等待更长时间才能被处理。这会导致系统的响应时间大幅延长，从原本的几十毫秒增加到几秒甚至几十秒。对于用户来说，这意味着在访问应用时需要长时间等待页面加载或操作响应，极大地降低了用户体验，可能导致用户流失。例如，在一个在线购票系统中，若在高峰期没有流量控制，用户可能需要等待数分钟才能完成购票操作，这很可能会让用户选择放弃购票，转而寻找其他替代方案。

服务不可用：当流量持续超过系统的承受能力，系统可能会因为资源耗尽和响应缓慢而最终无法提供正常服务，出现服务中断或不可用的情况。这对于企业来说，不仅会导致业务损失，还会损害企业的声誉。比如，在一次重要的线上促销活动中，如果电商平台因为流量过大而无法正常提供服务，用户无法下单购买商品，这将直接导致销售额的损失，同时也会让用户对该平台的信任度降低，影响未来的业务发展。

流量控制对于保障系统的稳定性和可用性起着关键作用：

保护系统资源：通过限制请求速率和流量大小，流量控制可以确保系统资源不会被过度消耗，使系统能够在合理的负载范围内运行。它可以避免 CPU、内存等资源的过度占用，防止数据库连接池被耗尽，从而保证系统各个组件的正常运行。

维持系统性能：合理的流量控制可以使系统在高并发情况下保持较好的响应性能。通过控制请求的进入速度，系统能够有足够的时间和资源来处理每个请求，避免因为请求堆积而导致响应时间过长。这样可以为用户提供更流畅的使用体验，提高用户满意度。

提高系统可用性：有效的流量控制能够降低系统因过载而崩溃的风险，确保系统在各种情况下都能持续提供服务。即使在流量高峰时期，通过流量控制策略，如限流、熔断和降级等，可以保证系统的核心功能仍然可用，避免服务中断给用户和企业带来的损失。

3.3 常见的流量控制策略

3.3.1 限流

限流是一种常见且重要的流量控制策略，它通过限制单位时间内进入系统的请求数量或并发请求数，防止系统因过载而无法正常工作。常见的限流算法包括令牌桶算法、漏桶算法、固定窗口算法和滑动窗口算法等。

令牌桶算法：令牌桶算法的核心思想是系统以固定的速率生成令牌，并将令牌放入一个容量有限的桶中。当桶满时，新生成的令牌会被丢弃。每个请求在进入系统前，需要从桶中获取一个令牌，如果桶中有足够的令牌，则请求被允许通过并消耗一个令牌；如果桶中没有令牌，请求将被拒绝或等待。例如，假设令牌桶的容量为 100 个令牌，生成令牌的速率为每秒 10 个。在某一时刻，桶中有 50 个令牌，此时有一个请求到来，请求获取一个令牌后，桶中剩余 49 个令牌。如果接下来有 10 个请求同时到来，由于桶中有足够的令牌，这 10 个请求都可以被处理并消耗相应数量的令牌；但如果有 100 个请求同时到来，桶中只有 49 个令牌，那么只有 49 个请求可以被处理，剩余 51 个请求将被拒绝或等待令牌生成。

漏桶算法：漏桶算法的原理是将请求想象成水，先进入一个固定容量的桶中，桶以固定的速率将水流出（即处理请求）。当水流入的速度过快，超过桶的处理能力时，多余的水（请求）会溢出（被丢弃）。漏桶算法能强行限制数据的传输速率，使请求以均匀的速率被处理。比如，一个漏桶的容量为 10，出水速率为每秒 2。当请求以每秒 5 的速率进入漏桶时，漏桶会按照每秒 2 的速率处理请求，多余的每秒 3 个请求会被丢弃，从而保证系统不会因为请求过多而无法处理。

固定窗口算法：固定窗口算法是将时间划分为一个个固定大小的窗口，在每个窗口内维护一个计数器。每当有新的请求进入系统，计数器就加一。当计数器的值超过设定的阈值时，在当前窗口内的后续请求将被拒绝。例如，设定时间窗口为 1 秒，阈值为 100。在第 1 秒内，前 100 个请求可以正常通过，当第 101 个请求在第 1 秒内到达时，由于计数器已达到阈值 100，该请求将被拒绝，直到下一个时间窗口开始，计数器重置为 0，新的请求才可以再次被处理。

滑动窗口算法：滑动窗口算法是对固定窗口算法的改进，它将固定的时间窗口划分为多个小的子窗口，每个子窗口都有自己的计数器。随着时间的推移，窗口会按照固定的时间间隔向右滑动，每次滑动时，最老的子窗口的计数将被移除，同时统计当前所有子窗口内的请求数量来判断是否触发限流。例如，将 1 分钟的时间窗口划分为 60 个 1 秒的子窗口，每个子窗口有一个计数器。在第 10 秒时，窗口向右滑动 1 秒，移除第 1 秒的计数器，并统计第 2 - 10 秒这 9 个子窗口的计数器之和来判断是否超过限流阈值。这样可以更精确地控制流量，减少固定窗口算法在窗口边界处可能出现的突发流量问题。

不同的限流算法具有各自的优缺点和适用场景：

令牌桶算法：优点是能够允许一定程度的突发流量，在流量低峰时可以积累令牌，当有突发请求时，能够利用积累的令牌快速处理请求，提高系统的响应能力；缺点是实现相对复杂，并且在系统上线初期如果没有预热，桶中可能没有足够的令牌，导致请求被误杀。适用于需要应对突发流量的场景，如电商平台的秒杀活动、API 接口调用等。

漏桶算法：优点是可以使请求以均匀的速率被处理，能够有效削峰填谷，保证系统的稳定性；缺点是无法应对突发流量，因为无论请求的速率如何变化，漏桶始终以固定的速率处理请求，可能导致在突发流量时大量请求被丢弃。适用于对流量整形要求较高，需要保证请求匀速处理的场景，如视频流传输、数据同步等。

固定窗口算法：优点是实现简单，易于理解和部署；缺点是存在临界问题，即在时间窗口的边界处，可能会出现突发流量超过限流阈值的情况，导致系统在短时间内过载。适用于对实时性要求不高，流量较为平稳的场景，如一些内部系统的接口调用限流。

滑动窗口算法：优点是能够更精确地控制流量，解决了固定窗口算法在边界处的问题；缺点是实现相对复杂，需要更多的存储空间来记录每个子窗口的计数器。适用于对流量控制精度要求较高的场景，如互联网业务中的高并发接口限流。

3.3.2 熔断

熔断机制最初源于电路中的保险丝原理，当电路中的电流过大时，保险丝会熔断，从而切断电路，防止电器设备因过载而损坏。在分布式系统中，熔断机制被引入用于处理服务之间的调用故障，其原理是当服务出现异常（如频繁超时、大量错误返回等）或长时间未响应时，熔断器会自动断开服务之间的连接，不再将请求发送到故障服务，而是直接返回一个预设的错误提示或备用数据。这样可以避免故障服务的问题扩散到整个系统，防止因单个服务的故障导致级联反应，进而引发整个系统的雪崩。

以一个电商系统为例，该系统中的订单服务依赖于库存服务来获取商品库存信息。在正常情况下，订单服务向库存服务发送请求，获取库存数据并进行订单处理。然而，当库存服务由于某种原因（如数据库故障、网络异常等）出现大量超时或错误响应时，订单服务如果继续向库存服务发送请求，不仅无法得到有效的响应，还会占用大量的系统资源（如线程、连接等），导致订单服务自身的性能下降，甚至影响到其他依赖订单服务的业务模块。此时，熔断机制就会发挥作用，当库存服务的错误率或超时率达到一定阈值（例如错误率超过 50%，或连续 10 次请求中有 8 次超时），熔断器会熔断，订单服务不再向库存服务发送请求，而是直接返回一个提示信息，告知用户库存查询暂时不可用，请稍后重试，或者返回一个预设的库存数据（如默认显示商品有货，但实际下单时进行库存校验）。

在熔断状态下，系统会定期尝试探测故障服务是否恢复正常。当故障服务恢复正常后，熔断器会进入半熔断状态。在半熔断状态下，系统会允许部分请求发送到故障服务进行试探性调用，如果这些试探性调用都能正常返回，说明故障服务已完全恢复，熔断器将恢复到正常状态，请求可以正常发送到该服务；如果试探性调用仍然出现故障，熔断器会再次进入熔断状态，继续断开连接。

熔断机制的引入可以有效地提高分布式系统的容错性和稳定性，避免因单个服务的故障而导致整个系统的崩溃，保障了系统的核心业务能够持续运行。同时，熔断机制也为系统的故障排查和修复提供了时间和空间，使得运维人员能够有足够的时间定位和解决故障服务的问题。

3.3.3 降级

降级策略是在分布式系统面临资源紧张（如 CPU 使用率过高、内存不足等）或服务故障（如某个非核心服务不可用）时，为了保证系统核心功能的稳定运行，而采取的降低服务复杂度或性能要求的一种措施。其核心思想是在系统出现异常情况时，通过牺牲部分非关键功能或服务的质量，来确保核心业务的正常运转。

例如，在一个综合新闻资讯平台中，系统的核心功能是新闻内容的展示和推荐。当系统在高并发访问或服务器资源紧张的情况下，一些非核心功能，如新闻图片的高清展示、视频的自动播放等，可能会被降级处理。原本提供高清图片展示的功能，在降级时可能会切换为提供标清图片展示，以减少图片加载所需的带宽和服务器资源；视频自动播放功能可能会被关闭，改为用户手动点击播放，从而降低系统的负载。

在电商系统中，当订单服务出现故障时，为了保证用户仍然能够浏览商品和进行购物车操作，系统可以对订单服务进行降级。例如，暂时取消订单的实时库存校验功能，改为在订单提交后进行异步库存校验。这样，用户在添加商品到购物车和浏览商品详情时不会受到影响，虽然订单的准确性可能会在短期内受到一定影响，但保证了用户能够继续进行核心的购物操作，提高了用户体验和系统的可用性。

降级策略通常包括以下几种方式：