函数计算Cookie亲和性是将携带相同Cookie信息的请求路由到同一个函数计算实例。当服务端收到Cookie函数的HTTP请求后，解析HTTP请求头中不含Cookie字段或者Cookie字段中不含所提供的cookie-name时，服务端会主动生成SessionID，并添加到响应请求的set-cookie字段，后续Client请求需携带服务端生成的Cookie信息。
协议剖析
在HTTP协议中，Cookie和Set-Cookie是用于管理客户端和服务器之间状态的两种重要机制。
Set-Cookie: 由服务器发送给客户端，用于设置 Cookie 的键值对和属性。Cookie: 由客户端发送给服务端，携带之前服务器设置的 Cookie 信息。
客户端发起首次请求时，若未设置Cookie，则Cookie为null。在服务端响应请求时，服务端会在响应请求头中加入Set-Cookie字段，来告诉客户端后续发送的Cookie信息。
Set-Cookie 格式
当函数计算收到HTTP请求后，解析HTTP请求发现请求头中不含cookie字段，服务端会在响应请求中增加Set-Cookie字段。其中Set-Cookie 格式为Set-Cookie: <cookie-name>=<cookie-value>; [属性]，如下：
当前属性仅支持
Max-Age：Cookie的最大存活时间（秒）。<cookie-name> 为固定值：x-fc-cookie-session-id。
Set-Cookie: x-fc-cookie-session-id=xxx; Max-Age=3600实现原理
Cookie生命周期
函数计算为Cookie生命周期定义双阈值机制，满足一个即触发Cookie过期条件：
单个 Session 生命周期：指从 Session 创建、使用到最终销毁的全过程。 超过生命周期，函数计算将会自动销毁Session， 不再保证亲和性。
Session idle 时长：用户在一段时间内没有进行任何操作，导致会话进入空闲状态，最大时长为单个 Session 生命周期上限。
您需根据业务场景配置合理值：
持续活跃：频繁请求重置闲置计时器，永不触发回收。
闲置回收：请求间隔>n秒时触发Session idle 时长条件。
强制回收：实例存活时间>Session 生命周期触发Session 生命周期条件。
Session并发管理
您需结合实际业务场景需求配置合理的限制项：
非亲和模式场景可根据业务需求调整单实例并发度。
亲和模式场景仅限制实例最大并发Session数，单实例下所有session并发请求数最大200。
并发参数类型 | 含义 | 是否可调 | 限制 | 消耗规则 | 并发回收机制 |
单实例最大并发度 | 单实例最多同时处理的最大并发请求数，超出并发上限的请求将路由到其他实例或拒绝限流。 | 不可调整 | 200 | 每个请求占用1个并发 | 请求处理完成后异步释放 |
单实例并发Session数 | 单实例在同一个时间内能同时处理的最大 Session 数，多Session下的请求共享 200 并发度 | 可调整 | [1,200] | 每个cookie的生命周期内占用1个Session数 | cookie 过期后释放 |
亲和调度行为（亲和/限流/调度到新实例）
场景1：Session和实例绑定规则及Session触发实例扩容机制
函数计算引入单实例并发Session数策略，限制每个实例最多绑定n个Session。如下流程所示：
假设函数配置了可绑定2个Session，Client1发起未携带Cookie的请求时，系统生成set-cookie值，分配了Instance1实例，并占用1个Session并发。
Client2发起未携带Cookie的请求时，Scheduler计算Instance1 仍有1个可用Session，成功和Instance1再次完成绑定。
Client3发起未携带Cookie的请求时，Scheduler计算Instance1的2个并发 Session 数已被2个Cookie占用，无法再次绑定，则调度到新实例Instance2，完成实例绑定。
场景2：单实例下多Session共享资源限流机制
假设函数配置了可绑定2个Session，Client1发起Cookie首请求时，分配了Instance1实例，实例消耗
1个并发Session+1个请求并发度。Client2发起Cookie首请求时，Scheduler计算Instance1 仍有1个可用并发Session，成功和Instance1再次完成绑定，此时实例消耗
2个并发Session+2个请求并发度。Client1 和 Client2 携带首请求返回的 cookie，并发198个请求，此时实例消耗
2个并发Session+200个请求并发度。当发起第199个请求时，单实例200请求并发度已耗尽，请求限流返回 429。
函数平滑更新
在Cookie亲和场景下，数据请求从请求级无状态变为会话级绑定，在UpdateFunction后，存量Cookie仍路由至UpdateFunction前绑定的实例，增量Cookie路由至UpdateFunction后新生成的实例。如下图所示：
平滑过渡
当函数计算服务进行版本更新（UpdateFunction）时，系统将自动启用双版本共存机制，确保服务平滑过渡：
存量Cookie请求：携带已有Cookie（如CookieA）的请求会自动路由至更新前的InstanceV1实例。
增量Cookie请求：新增请求（如CookieB）将绑定到新创建的InstanceV2实例。
销毁时机
存量实例InstanceV1：每次请求处理都会重置闲置计时器任一条件触发即回收：
连续无请求时间 > idleTimeout
实例存活时间 > sessionTTL
增量实例InstanceV2：回收机制同存量实例。
计费说明
会话亲和费用 = 处理请求的弹性实例（活跃）费用 + 实例保活期间的弹性实例（闲置）费用
关于弹性实例（活跃）和弹性实例（闲置）费用计算说明，请参见计费概述。