ELB监听器与目标组粘性配置差异及配置选型解答

两处粘性配置的核心功能差异 #

这俩配置根本不是管同一层逻辑的，作用范围完全不一样：

• 目标组维度的stickiness块（aws_lb_target_group资源内）：是作用在目标组内部后端实例选择层面的基础配置。只要流量被转发到当前目标组，就会按照这里的规则（基于cookie类型、粘性时长等），把同一客户端的请求持续转发到组内同一个后端目标（EC2、IP、Lambda等），这个配置和上层怎么把流量导进来无关，是目标组本身的流量转发规则。
• 监听器转发动作维度的stickiness块（aws_lb_listener/aws_lb_listener_rule的forward动作块内）：是作用在多目标组选择层面的配置，根本不干涉目标组内部选哪个后端。只有当你给一个forward转发动作配置了多个目标组、按权重分流的时候，这个配置才会生效：第一次请求按权重把客户端分配到某一个目标组后，在配置的粘性时长内，该客户端的所有请求会直接固定转发到这个目标组，跳过权重分流的选组逻辑。

举个直白的例子：你给转发规则配了A、B两个目标组，权重各50%，开了转发层粘性：用户第一次被分到A组后，粘性期内所有请求都直接进A组，不会再碰50%分去B组的逻辑；但进了A组之后，请求到底粘到A组里哪台EC2，完全看A组自己的粘性配置，和转发层的配置没关系。

实现会话粘性是否需要两处配置对齐规则 #

完全不需要，两者没有绑定关系，要不要配、配什么规则完全看你的流量架构：

• 如果你的转发动作只关联单个目标组（绝大多数常规业务都是这个模式），监听器层的stickiness配了也不会产生任何实际作用，因为不存在多目标组选组的步骤，只需要配置目标组维度的粘性，就能实现用户请求固定到同一后端实例的会话保持效果。
• 如果你确实用了单forward动作挂多目标组做灰度、蓝绿发布、流量拆分，且需要保证同一用户在会话周期内不跨目标组跳转，才需要开启监听器转发层的粘性。这一层的配置规则、时长不需要和目标组层的配置保持一致，两者独立生效：比如你可以把转发层粘性设为7天，保证用户整个活动周期都固定访问同一个版本的目标组；目标组层粘性设为1小时，平衡后端实例负载和会话保持需求，两者互不干扰。
• 如果多目标组分流场景下不需要固定用户到某一个目标组，完全可以不开转发层粘性，只保留目标组层的配置即可——只是用户每次请求可能按权重被分到不同目标组，进入对应目标组后还是会粘到组内固定的后端实例。

仅在目标组层面配置粘性是否为更优实践 #

没有绝对的最优，但对90%以上的常规业务场景来说，只在目标组层面配置粘性是标准的最佳实践：

• 配置逻辑收敛：粘性规则和目标组绑定，不管是哪个监听器、哪个转发规则把流量导到这个目标组，粘性行为都是一致的，不会出现不同入口流量粘性规则不统一的混乱问题，排查问题的时候也不用跨多层查配置。
• 无冗余配置：单目标组转发场景下，监听器层的粘性配置是完全冗余的，开了不仅不生效，还会增加后续配置维护、故障排查的复杂度。
  只有两类场景需要额外配置监听器转发层的粘性：
• 做基于权重的蓝绿/灰度发布时，需要避免用户请求在不同版本的目标组之间跳转，影响业务体验
• 做多目标组流量拆分测试时，需要固定客户端的分流归属，保证流量拆分的测试数据准确
  最后提个常见踩坑点：不要觉得两个地方都开粘性是双重保险，如果两层配置的粘性时长不一致，很容易出现用户请求突然跳转到其他后端实例的问题——本质是转发层粘性到期，用户被分配到了另一个目标组，和目标组本身的粘性配置没有关系。

内容的提问来源于stack exchange，提问作者Darren