(十八)—— 重试模式.pdf

（⼗⼋）—— 重试模式 云计算设计模式 （⼗⼋）——重试模式 启⽤应⽤程序来处理预期的，暂时的失败时，它会尝试连接到由透明的重试操作了以 失败的期望，失败的原因是瞬时的服务或⽹络资源。这种模式可以提⾼应⽤程序的 稳定性。 背景和问题 该通信的应⽤程序与在云中运⾏的元素必须是可能发⽣在这样的环境中的瞬时故障敏 感。这些故障包括⽹络连接的过程中出现时，⼀个服务是忙碌的瞬时损失的组件和服 务中，服务的临时不可⽤，或超时。 这些故障⼀般是⾃校正的，如果经过⼀个合适的延迟被重复触发⼀个故障的动作很可 能是成功的。例如，数据库服务，它正在处理⼤量并发请求可以实现节流策略，暂时 拒绝，直到它的⼯作量有所缓和任何进⼀步的请求。试图访问该数据库的应⽤程序可 能⽆法连接，但如果它经过⼀个合适的延迟再次尝试它可能会成功。 解决⽅案 在云中，瞬时故障的情况并不少见和应⽤应该被设计为优雅和透明地处理它们，减少 的影响，这种故障可能对应⽤程序正在执⾏业务任务。 如果⼀个应⽤程序检测到故障时，它试图将请求发送到远程服务，它可以通过使⽤以 下策略处理失败： 如果故障指⽰故障不是瞬时的或不太成功，如果重复 （例如，所造成的⽆效提 供凭据的认证失败是不可能成功的，⽆论是多少次未遂），应⽤程序应中⽌操 作和报告⼀个合适的异常。 如果报道的具体故障是不寻常的或罕见的，这可能是由于反常的情况，如⽹络 数据包成为损坏，同时它被发送。在这种情况下，应⽤程序可以再次⽴即重试 失败的请求，因为相同的故障是不可能被重复和请求将可能是成功的。 如果故障是由⼀种更加普遍的连接，或“忙”的失败，⽹络或服务可能需要在短 期内同时连接问题纠正或⼯作的积压被清除。应⽤程序应该等待请求重试 ⼀ 个合适的时间。 对于⽐较常见的短暂故障，重试期间，应选择以传播从应⽤程序中尽可能均匀的多个 实例的请求。这可以减少繁忙的业务持续过载的可能性。如果⼀个应⽤程序的多个实 例不断轰击与重试请求的服务，则可能需要该服务更长的时间来恢复。 如果请求仍然失败，应⽤程序可以等待进⼀步的时期，再次尝试。如果需要的话，这 个过程可以重复⽽增加重试的延迟，直到请求的某⼀最⼤数⽬已经尝试都失败了。延 迟时间可以逐步增加，或可使⽤的定时策略，如指数回退，取决于故障的性质和可能 性，这将在这段时间内被校正。 图1⽰出了这种模式。如果尝试后的预定数量的请求不成功，应⽤程序应将故障为异 常，并相应地处理它。 图1 - 使⽤重试模式中调⽤托管服务的操作 应⽤程序应该换所有试图访问远程服务，实现重试政策配套上⾯列出的策略之⼀的代 码。发送到不同的服务请求会受到不同的政策，有的供应商提供封装这种⽅法库。这 些库通常执⾏的政策是参数化的，⽽应⽤程序开发⼈员可以指定，如重试次数和重试 之间的时间项的值。 在检测故障和重试失败的操作都应该记录这些故障的详细信息的应⽤程序的代码。这 个信息可能是有⽤的运算符。如果⼀个服务被频繁报道为不可⽤或忙，往往是因为该 服务已耗尽其资源。则可以减少与这些故障发⽣时通过换算出该服务的频率。例如， 如果数据库服务正在不断超载，它可能是有利的分区数据库和负载分散到多个服务 器。 注意： 微软 Azure 提供了重试模式的⼴泛⽀持。该模式与实践瞬态故障 处理块允许应⽤程序通过⼀系列的重试策略来处理许多 Azure 服务瞬态 故障。微软实体框架版本6提供了⽤于重新尝试数据库操作。此外，许多 在 Azure Service Bus 和 Azure 存储的 API 透明地执⾏重试逻辑。 问题和注意事项 在决定如何实现这个模式时，您应考虑以下⼏点： 重试政策应进⾏调整，以满⾜应⽤和故障性质的业务需求。它可能是更好⼀些 ⾮关键操作失败快⽽不是重试⼏次，并影响应⽤程序的吞吐量。例如，在试图 访问远程服务的交互式Web应⽤程序，这可能是更好的重试之后⽤重试之间只 有⼀个短的延迟的数量较少失败，并显⽰⼀个适当的消息给⽤户 （例如，“请稍 后“ ），再次尝试阻⽌应⽤程序变得反应迟钝。对于批处理应⽤程序，它可以是 更合适的，以增加重试尝试的次数与尝试之间的指数增加的延迟。 与尝试之间最⼩的延迟和⼤量的重试的⾼攻击重试的政策，可能会进⼀步降低 正在接近运⾏或容量的占⽤。此重试策略也可能会影响应⽤程序的响应，如果