第五十一章 进程亲和性和状态感知模式（保留模式 1）
Web 的架构是无状态的。为了在性能、可维护性和可扩展性方面充分利用 Web 架构，Web 应用程序应该采用无状态范例。
默认情况下，Web 应用程序在相对于托管 IRIS 服务器的无状态环境中运行。 Web 网关维护与 IRIS 的连接池，并在它们之间分配工作负载，并在配置的限制内增加（或减小）连接池的大小。每个连接都与一个 IRIS 进程相关联（由 $Job 变量标识）。
对于在无状态模式下运行的普通 Web 应用程序，请考虑用于服务客户端会话的每个请求的后端 IRIS 进程的选择是随机的。 Web 网关选择恰好空闲的连接/进程。
然而，为了提高效率，Web Gateway 确实实现了一种形式的 IRIS 进程亲和力。换句话说，它会在可能的情况下尝试将对会话的请求路由到用于为该会话的先前请求提供服务的同一 IRIS 进程。
除了基于会话 ID 的进程关联性度量之外，Web Gateway 还尝试实现基于命名空间的进程关联性。 Web 网关跟踪每个连接所指向的命名空间，并在可能的情况下将请求传递到已指向处理请求所需的命名空间的连接。这有助于避免在接收每个 Web 请求时在不同名称空间之间移动资源所产生的开销。
就优先级而言，会话关联性始终优先于选择连接时的所有其他考虑因素。如果传入请求无法分配给先前用于服务客户端会话的同一连接，则使用命名空间关联来影响最终选择。
CSP 包括一种模式，Web Gateway 通过该模式将会话的所有请求路由到保留的（或专用的 IRIS 连接/进程。这种操作模式提供了一个关于 Web 会话及其相应 IRIS 进程之间关系的状态感知环境。
状态感知模式作为 CSP 保留模式 1 实现
提供状态感知操作模式（保留模式 1）的最初动机是为了使将遗留应用程序代码从固定的客户端-服务器环境（例如终端应用程序）迁移到 Web 变得相对容易。对跨越多个 HTTP 请求的事务的支持也是其引入时考虑的一个因素。但是，在创建状态感知应用程序时，应牢记以下段落中概述的限制。
状态感知应用程序的扩展性不如无状态应用程序，因此建议新应用程序（以及对现有应用程序的修改）尽可能设计为无状态的。建议在主要无状态的应用程序中谨慎应用状态感知模式（如果确实使用）。
不建议编写完整的应用程序以在状态感知模式下运行。除了因需要为每个会话保留 IRIS 进程而产生的可扩展性问题之外，由于路由的非常具体的要求，状态感知应用程序无法充分利用现代负载平衡和故障转移解决方案要求。此外，状态感知应用程序的容错能力不如无状态应用程序。例如，Web 服务器工作进程的回收可以在无状态应用程序下透明地发生，但会导致所有关联的状态感知会话关闭。当然，可以通过使用 Web Gateway 的 NSD 组件将 Web Gateway 进程池的管理与托管 Web 服务器分开来避免后一种限制。
创建成功的状态感知应用程序（或主要无状态应用程序中的状态感知部分）需要一定的纪律。
由于会话的所有请求必须由同一 IRIS 进程处理，因此必须维护一个队列，以便在客户端同时分派多个请求的情况下串行化对专用 IRIS 进程的访问。最初的 HTTP v1.1 标准要求客户端同时打开到每个服务器的连接不得超过 2 个 (RFC2616)。然而，这个限制是可配置的，事实上，最新一代的 Web 浏览器默认支持每个服务器最多 8 个连接。不用说，增加每个服务器的最大连接数会对状态感知 Web 应用程序产生深远的影响：应用程序最多可以同时触发 8 个请求，并随后将其保留在负责控制访问的队列中。单一私有 IRIS 进程。
状态感知模式中的另一个潜在缺陷是 Web Gateway 和 IRIS 之间运行的服务器响应超时的影响。当 Web 网关在响应超时规定的时间限制内未收到响应时，它别无选择，只能关闭连接，从而导致状态感知会话丢失。
最后，客户端中断的影响可能会导致在状态感知模式下运行的应用程序出现问题。当客户端在 IRIS 生成响应的点（或超出该点）中断请求时，Web Gateway 会尝试吸收（现在不需要的）响应负载以保留连接。如果无法及时完成此操作，它也别无选择，只能通过关闭连接来中断 IRIS 进程正在执行的任何操作，并且会话会丢失。请记住，当 Web 网关尝试吸收中断请求的有效负载时，同一会话的更多请求可能会到达并放入队列中。
总之，在创建状态感知应用程序时请遵循以下设计目标。
- 尽可能避免（或谨慎使用）生成许多同时请求的客户端构造（例如：
HTML框架集文档）。 - 确保快速生成响应。这减少了与超时和/或客户端中断事件相关的问题的范围。它还减轻了会话队列的压力。如果
IRIS中的某项任务可能需要较长时间才能完成，请考虑在另一个进程中执行该任务，以便主专用进程可以快速将响应返回到Web网关（和客户端）。
