如何确保同一用户的分片上传请求由同一Kubernetes Pod处理？

一、确保同一用户的分片请求落到同一个Kubernetes Pod的方案 #

1. Ingress层面配置Cookie会话粘性 #

这是最常用的落地方案，通过Kubernetes Ingress（比如NGINX Ingress）配置会话亲和性，让同一用户的请求携带固定Cookie，从而被路由到同一个Pod。

配置示例（NGINX Ingress）：

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: upload-ingress
  annotations:
    nginx.ingress.kubernetes.io/affinity: "cookie"
    nginx.ingress.kubernetes.io/session-cookie-name: "upload_session"
    nginx.ingress.kubernetes.io/session-cookie-expires: "172800"  # 2天有效期，可根据上传时长调整
    nginx.ingress.kubernetes.io/session-cookie-max-age: "172800"
    nginx.ingress.kubernetes.io/session-cookie-path: "/api/uploads"  # 仅对上传接口生效
spec:
  rules:
  - host: your-domain.com
    http:
      paths:
      - path: /api/uploads
        pathType: Prefix
        backend:
          service:
            name: upload-service
            port:
              number: 80

这种方式无需修改前端和服务代码，仅通过Ingress配置就能实现。但要注意：如果Pod重启，会话粘性会失效（用户后续请求会被路由到新Pod），所以服务必须具备分片上传的幂等性，或者能在Pod重启后重新处理未完成的分片。

2. 基于自定义用户ID的服务网格路由 #

如果你的集群使用了服务网格（比如Istio），可以基于请求中的用户ID Header（比如X-User-ID）做精准路由，确保同一用户的所有请求都转发到同一个Pod。

这种方式比Cookie更可靠，避免了Cookie被禁用或用户IP变化的问题，但需要前端在每个分片请求中携带X-User-ID，并在服务网格中配置对应的路由规则。

3. 不推荐：基于IP的会话粘性 #

K8s也支持基于客户端IP的会话粘性，但这种方式缺陷明显：如果用户处于NAT网络下，多个用户会共享同一IP；或者用户切换网络（比如从WiFi到4G），IP变化后会被路由到其他Pod，导致分片分散到不同Pod，因此不建议用于分片上传场景。

二、服务器端分片上传处理逻辑 #

1. 请求参数约定 #

前端每个分片请求必须携带以下核心参数：

• user_id：用户唯一标识
• file_id：文件唯一标识（前端生成，比如UUID）
• chunk_index：当前分片的索引（从0开始）
• chunk_total：分片总数
• chunk_hash（可选）：当前分片的哈希值（用于校验完整性）
• 分片文件数据：作为请求体或FormData字段

2. 分片接收与验证 #

• 先校验user_id、file_id、chunk_index、chunk_total的合法性：比如chunk_index不能小于0或大于等于chunk_total，user_id必须是已认证的有效用户。
• 校验分片文件的大小是否符合预期（比如前端约定每个分片10MB，服务器可校验避免异常分片）。
• 可选：对比chunk_hash和服务器计算的分片哈希值，确保分片未损坏。

3. 分片存储 #

• 为每个用户的每个文件创建独立的临时目录，比如/data/tmp/uploads/{user_id}/{file_id}/，避免不同用户或文件的分片冲突。
• 分片文件命名为chunk-{chunk_index}，方便后续合并时按顺序读取。
• 如果分片已经存在（比如前端重试上传），直接返回成功（实现幂等性），避免重复存储。

4. 合并触发与执行 #

• 主动触发：前端在最后一个分片上传完成后，发送专门的合并请求（携带user_id和file_id），服务器收到后执行合并。这是推荐方案，更及时且资源消耗更低。
• 被动触发：服务器定时扫描临时目录，检查某个文件的所有分片是否都已上传（比如对比chunk_total和目录下的分片数量），如果齐全则自动合并。
• 合并时，按chunk_index从小到大的顺序，将所有分片文件的内容写入最终文件（比如/data/uploads/{user_id}/{file_id}.ext）。
• 合并完成后，删除临时分片目录，释放存储空间。

5. 元数据记录与结果反馈 #

• 将最终文件的存储路径、文件大小、完整哈希值、上传完成时间等信息写入数据库，关联到user_id和file_id。
• 向前端返回合并成功的响应，包含文件访问地址或唯一标识。

6. 异常处理 #

• 分片上传失败：前端重试时，服务器需支持幂等，避免重复存储或报错。
• 合并失败：记录错误日志，保留临时分片文件，以便后续重试合并；同时通知前端合并失败，让用户触发重试。
• 超时清理：设置定时任务，清理超过一定时间（比如7天）未完成合并的临时分片目录，避免磁盘空间浪费。

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