🔗 功能：服务过载处理（ICAP 最大连接数等）

• 目标：使 Squid 在 [适配] 服务过载时行为可配置
• 状态：进行中；目前只计划了第一阶段的工作
• 预计完成时间：2011 年 5 月
• 版本：Squid 3.2
• 开发者：AlexRousskov ChristosTsantilas
• 更多信息：bug 2055

🔗 概述

Squid 应该支持 ICAP 最大连接数（Max-Connections）功能，因为它允许 Squid 绕过或等待过载的 ICAP 服务器，而不是用更多的流量压垮这些服务器。类似的过载处理功能对于一些缓慢的 eCAP 服务（尤其是可选服务）也很有用。

正确处理最大连接数很困难，因为接口规范不明确（最大值是指服务器、服务还是客户端/服务器对的限制？管道化请求是否计入？），因为最佳操作取决于服务，而且从 SMP Squid 的角度来看，可用连接槽的数量可能是一个共享资源。首次尝试提供可靠的最大连接数支持已经停滞，部分原因是上述的复杂性。本项目将重启并扩展这项原始工作。

为加快功能可用性和跟踪进度，项目分为多个阶段

🔗 第一阶段：ICAP 基础

实现 ICAP 最大连接数功能，以限制 Squid 连接到 ICAP 服务的连接数。如果在早期 OPTIONS 响应中，服务指示了最大连接数阈值且该阈值已达到，Squid 可以配置为执行以下操作之一：

• 阻塞 (Block)：向订阅者发送 HTTP 错误响应
• 绕过 (Bypass)：忽略“连接过多”的 ICAP 服务
• 等待 (Wait)：等待（在 FIFO 队列中）一个 ICAP 连接槽
• 强制 (Force)：继续，忽略最大连接数限制

配置通过 `icap_service` 的 `on-overload` 参数完成，该参数可设置为 `block`|`bypass`|`wait`|`force`。

目前，Squid 会忽略最大连接数限制，本质上执行“强制”行为。对于必需的服务，“等待”选项将成为新的默认行为；对于可选服务，“绕过”选项将成为新的行为。

当服务首次过载时，Squid 会发出警告，指示所选择的 Squid 行为。

SMP Squid 假定所有工作进程共享相同的适配服务，并将服务提供的最大连接数除以工作进程数量，以得出每个工作进程的限制。

开发者备注：尽可能使用通用的适配服务类，因为稍后会为 eCAP 添加类似的支持。在将连接描述符从 `ICAP ServiceRep` 类传递给等待的 ICAP 事务时要格外小心，因为在包含描述符的消息挂起时，事务作业可能会终止。我们可能需要一个自定义的拨号器，如果事务已不存在（或者如果服务和事务都已不存在，则关闭它），则将描述符返回给 `ServiceRep` 对象。

🔗 第二阶段：ICAP 扩展

添加对 `max-conn` 服务选项的支持，以指定最大连接数限制，无论服务是否自行响应其对限制的看法。

在 SMP 工作进程之间共享当前服务连接数。

Squid 在服务过载时发出警告，使用某种智能算法来防止过于频繁的通知（待定）。

🔗 第三阶段：eCAP

支持 eCAP 最大连接数元头（meta header），以及 `max-conn` 和 `on-overload` `ecap_service` 参数，将每个并发的 eCAP 事务视为“连接”。

🔗 第四阶段：负载均衡

在为必需服务做出与绕过相关的决定时，要考虑服务是否位于 `adaptation_service_set` 中。当集合中的第一个服务过载时，我们应该使用第二个服务，而不是阻塞消息或绕过服务。换句话说，过载应该被视为可恢复的事务错误，前提是集合中有更多的服务可供尝试。这种方法对其他适配错误也很有用。

我们还可以添加一个 `adaptation_service_set` 参数，以指示集合中的所有服务是否应以轮循（round-robin）、最少负载（least-loaded）、故障后下一个（next-on-failure）或故障后重排（reshuffle-on-failure）的方式使用。

类别：功能

导航：站点搜索，站点页面，类别，🔼 向上