通过配置负载均衡，可以合理的达到将请求分配到集群中的服务器上。但是如果单纯只有这一个概念的话会带来了一个新的问题：连续性的请求可能被分配给不同的服务器上，所带来的问题是缓存、数据库连接等资源不能共享。所以CognosBI通过密切性（affinity）将请求分类，目的是将不同的请求类型在负载均衡基础上优化路由。
事实上，负载均衡带来了硬件上的最大资源利用，而密切性请求将保证软件资源的高效重用。举例来说，如果一个报表分为若然页，如果查看“下一页”时路由到原始处理请求的服务器的话那么使用的系统资源将最低，因为路由到一个新的服务器去处理会增加数据库连接的成本。CognosBI将密切性分为：绝对（absolute）、控制（control）、高（high）、低（low）、会话（session）和服务器（server）这几种类型。
Tips：CognosBI密切性请求的路由优先级要高于负载均衡的优先级
绝对（absolute）密切性
绝对密切性指将请求发回原处理服务器进行处理，这种类型的密切性将保持客户端到执行服务器的联系，如果请求一直持续，那么将不会超时。但是如果保持过程中该服务器不可用，例如我们可能会碰见错误代码：“RSV-BBP-0022- The absolute affinity request 'asynchWait_Request' failed, the requestedsession does not exist.”
绝对密切性响应Cognos BI中getOutput 、release对应的操作。
控制（control）密切性
控制密切性也将请求发回原处理服务器进行处理，这点与绝对密切性一致。只不过控制密切性响应控制操作类型的请求，例如对CognosBI进行配置。
控制密切性响应Cognos BI中wait 、cancel对应的操作。
高（high）密切性
高密切性请求可以被路由到任意服务器，分派器会根据这次请求的conversation context node ID路由，如果目标服务器不可用，那么将继续路由至下一个可用服务器（并不是错误，也没有报错信息）。这里依然举刚才的例子，点击“下一页”那么分派器将根据conversationcontext node ID找到原始处理服务器，但是如果这台机器不可用“下一页”的结果依然能够返回，只不过效率上会低一些。
Tips：高密切性路由优先级依旧高于负载均衡，当目标服务器不可用才转为负载均衡控制。
高密切性响应Cognos BI中back、email、firstPage、forward、lastPage、nextPage、previousPage、print、render、save 、saveAs等对应的操作。
低（low）密切性
低密切性的请求与特定服务器无关，例如报表查询（query）就是这类的操作请求，这些请求会被路由至分派器指定的服务器。
高制密切性响应Cognos BI中add、collectParameterValues、execute、getMetadata、getParameters、query、testDataSourceConnection、update、 validate等对应的操作。
会话（session）密切性
会话密切性与一种与缓存重用相关的密切性。可以将其理解为高密切性与低密切性的组合。举例来说，报表在运行过程中产生的缓存保存在某台服务器中，如果下一个请求包含conversationcontext node ID那么将按照高密切性寻找服务器从而达到缓存重用；但是如果不包含conversationcontext node ID或者缓存不存在，一样可以根据低密切性路由。
服务器（server）密切性
服务器密切性与数据源管理有关，Cognos BI使用与绝对密切性相同的方式路由请求，例如用于测试数据源连接。
由于Cognos BI的密切性是内部定义，并不能留给用户更改的能力，但是可以通过设置高/低密切性连接进行调优的设置。设置的位置依旧在IBM Cognos Administration。
