AI搜索扛不住高并发？这套架构和配置可以直接参考

发布人：慈云数据-客服中心发布时间：15小时前阅读量：2

AI搜索高并发解决方案｜附配置文件

随着大模型与向量检索技术的发展，AI搜索正在从传统“关键词匹配”演进为“语义理解 + 多路召回 + 大模型生成”的新一代搜索形态。相比传统搜索系统，AI搜索不仅要完成文档检索、排序、摘要，还经常需要调用Embedding模型、向量数据库、LLM推理服务、缓存系统以及业务数据库。

这也意味着：AI搜索系统的高并发治理，比普通Web接口复杂得多。

在低并发场景下，一个简单的FastAPI服务加一个向量数据库就能跑起来；但一旦进入生产环境，尤其是面对数百、数千甚至更高QPS时，系统很容易出现以下问题：

接口响应时间急剧升高；
大模型调用排队严重；
向量数据库查询延迟抖动；
Redis缓存命中率不稳定；
服务线程、连接池、文件句柄耗尽；
请求雪崩导致整体系统不可用；
单个慢查询拖垮整条链路。

本文将从架构设计、性能瓶颈、核心优化策略、限流熔断、缓存设计、异步化处理、部署配置等方面，系统介绍一套适用于AI搜索的高并发解决方案，并附上可参考的配置文件。

一、AI搜索的典型请求链路

一个典型的AI搜索请求，通常会经历如下流程：

用户请求
  ↓
API网关 / Nginx
  ↓
AI搜索服务
  ↓
查询改写 / 意图识别
  ↓
Embedding向量化
  ↓
向量数据库召回
  ↓
关键词检索召回
  ↓
结果融合 / 重排序
  ↓
大模型生成答案
  ↓
返回结果

如果进一步细化，AI搜索的核心模块包括：

接入层
负责接收用户请求、SSL卸载、负载均衡、限流、日志记录等。
应用服务层
负责查询解析、路由调度、召回控制、结果聚合、权限校验等。
Embedding服务层
负责将用户Query转换为向量，用于语义检索。
检索层
包括向量数据库、全文检索引擎、倒排索引等。
排序层
包括粗排、精排、Reranker模型等。
生成层
调用LLM，根据检索结果生成自然语言答案。
缓存层
包括Query缓存、Embedding缓存、检索结果缓存、生成结果缓存等。
观测层
包括日志、指标、链路追踪、告警系统。

高并发优化的核心目标，就是让这条链路中的每一个环节都具备足够的吞吐能力，并且在异常情况下不会相互拖垮。

二、高并发下的核心瓶颈

AI搜索系统的瓶颈通常不是单点，而是多环节叠加造成的。

1. Embedding计算耗时

如果每次用户搜索都实时调用Embedding模型，延迟通常在几十毫秒到几百毫秒之间。对于高并发场景来说，Embedding服务会成为非常明显的瓶颈。

优化方向：

对相同Query进行Embedding缓存；
使用批量推理提升GPU利用率；
将短文本Embedding模型独立部署；
使用轻量模型处理高频查询；
对热门问题提前预生成向量。

2. 向量数据库查询压力

向量检索通常需要在高维空间中做近似最近邻搜索。数据量越大、召回数量越多，查询耗时越明显。

优化方向：

合理设置向量索引参数；
控制TopK数量；
使用分片与副本；
热点集合单独部署；
结合过滤条件减少搜索空间；
对热门查询结果进行缓存。

3. LLM生成延迟高

AI搜索与普通搜索最大的区别在于，很多场景需要大模型生成答案。LLM推理通常是整条链路中最慢的环节。

优化方向：

支持流式输出，降低用户感知延迟；
对热门问题缓存最终答案；
使用小模型处理简单问题；
对复杂任务异步生成；
限制最大输出Token；
设置超时与降级策略。

4. 数据库连接耗尽

高并发下，如果服务没有合理配置连接池，容易出现数据库连接耗尽、Redis连接耗尽、HTTP连接耗尽等问题。

优化方向：

设置连接池上限；
使用连接复用；
开启KeepAlive；
避免每次请求新建连接；
对慢请求进行超时回收。

5. 请求雪崩

当下游某个服务变慢时，上游请求会不断堆积，最终导致线程池耗尽、队列爆满，引发系统雪崩。

优化方向：

限流；
熔断；
超时；
舱壁隔离；
队列长度控制；
降级返回。

三、推荐架构方案

下面是一套适合中高并发AI搜索系统的参考架构：

                 ┌────────────────────┐
                 │      Client        │
                 └─────────┬──────────┘
                           │
                 ┌─────────▼──────────┐
                 │   Nginx / Gateway  │
                 └─────────┬──────────┘
                           │
       ┌───────────────────▼───────────────────┐
       │           AI Search API Cluster        │
       │     FastAPI / Go / Java Spring Boot    │
       └───────┬─────────────┬─────────────┬────┘
               │             │             │
        ┌──────▼──────┐ ┌────▼─────┐ ┌────▼──────┐
        │    Redis    │ │ VectorDB │ │  ES/OpenSearch │
        └──────┬──────┘ └────┬─────┘ └────┬──────┘
               │             │             │
        ┌──────▼─────────────▼─────────────▼──────┐
        │        Rerank / Embedding Services       │
        └───────────────────┬─────────────────────┘
                            │
                  ┌─────────▼─────────┐
                  │   LLM Inference   │
                  └───────────────────┘

核心设计原则：

接入层抗流量冲击
Nginx或API Gateway负责连接管理、限流、负载均衡、超时控制。
应用服务无状态化
AI Search API尽量保持无状态，方便水平扩容。
模型服务独立化
Embedding、Reranker、LLM分别部署，避免互相影响。
检索服务分层
向量召回、关键词召回、结构化过滤分开处理，再进行结果融合。
缓存前置
热门Query、Embedding、召回结果、生成答案都要尽可能缓存。
全链路限流与降级
任何一个下游服务不可用时，都不能拖垮主链路。

四、缓存设计策略

缓存是AI搜索高并发优化中最重要的手段之一。合理的缓存可以大幅降低模型调用次数和检索压力。

1. Query标准化

用户输入虽然不同，但语义上可能相同。例如：

“怎么申请退款”
“退款怎么操作”
“如何办理退款”

在缓存Key设计时，可以先进行Query归一化：

去除首尾空格；
转小写；
繁简转换；
去除无意义符号；
同义词归一；
可选：基于Embedding近似匹配相似Query。

示例缓存Key：

search:answer:v1:{tenant_id}:{query_hash}
search:embedding:v1:{model}:{query_hash}
search:retrieval:v1:{index}:{query_hash}

2. 多级缓存

推荐设计四层缓存：

缓存类型	缓存内容	TTL建议
本地缓存	高频配置、短期热点Query	10秒～5分钟
Redis缓存	Embedding、召回结果、答案	5分钟～24小时
CDN缓存	公开类热门答案	1分钟～1小时
预计算缓存	榜单、固定知识库问答	按业务更新

3. 缓存击穿处理

当一个热门Key过期时，大量请求可能同时打到后端服务，形成缓存击穿。可以使用以下策略：

分布式锁；
逻辑过期；
后台异步刷新；
TTL加随机抖动；
热点Key永不过期，定时更新。

Redis缓存伪代码：

async def get_or_build_answer(query: str):
    key = build_cache_key(query)
    cached = await redis.get(key)
    if cached:
        return cached

    lock_key = f"lock:{key}"
    locked = await redis.set(lock_key, "1", ex=10, nx=True)

    if locked:
        try:
            answer = await build_answer(query)
            await redis.set(key, answer, ex=3600 + random.randint(0, 300))
            return answer
        finally:
            await redis.delete(lock_key)
    else:
        await asyncio.sleep(0.05)
        cached = await redis.get(key)
        if cached:
            return cached
        return await fallback_search(query)

五、异步化与并发控制

AI搜索中很多操作可以并行执行，例如向量召回和关键词召回可以同时进行，Embedding缓存查询和用户权限检查也可以并行处理。

1. 并行召回

async def search(query: str):
    embedding_task = asyncio.create_task(get_embedding(query))
    keyword_task = asyncio.create_task(keyword_search(query))

    embedding = await embedding_task
    vector_task = asyncio.create_task(vector_search(embedding))

    keyword_result, vector_result = await asyncio.gather(
        keyword_task,
        vector_task,
        return_exceptions=True
    )

    merged = merge_results(keyword_result, vector_result)
    return await generate_answer(query, merged)

2. 设置超时

所有外部调用都必须设置超时，包括：

Redis；
向量数据库；
Elasticsearch；
Embedding服务；
Reranker服务；
LLM服务。

示例：

async def call_with_timeout(coro, timeout=2.0):
    try:
        return await asyncio.wait_for(coro, timeout=timeout)
    except asyncio.TimeoutError:
        return None

3. 舱壁隔离

不同类型请求应该使用不同资源池。例如：

普通搜索请求；
复杂问答请求；
后台索引构建任务；
管理端请求；
批量导入任务。

不要让后台任务占满线上搜索资源。

六、限流、熔断与降级

高并发系统不能只考虑“正常情况下能扛多少QPS”，还要考虑“异常情况下如何保护系统”。

1. 限流策略

常见限流维度：

IP限流；
用户限流；
租户限流；
接口限流；
模型调用限流；
向量库查询限流。

常见算法：

固定窗口；
滑动窗口；
令牌桶；
漏桶。

推荐使用令牌桶，既能限制平均速率，又允许短时间突发。

2. 熔断策略

当下游服务连续失败或超时时，应临时熔断，避免请求继续打入故障服务。

熔断状态通常包括：

Closed：正常调用；
Open：直接失败或走降级；
Half-Open：少量探测请求尝试恢复。

3. 降级策略

AI搜索的降级可以分层进行：

故障模块	降级方案
LLM不可用	返回检索结果列表，不生成答案
Reranker不可用	使用粗排分数排序
向量库不可用	使用关键词搜索
ES不可用	使用向量搜索
Embedding不可用	使用缓存或关键词搜索
Redis不可用	直接查后端，但降低QPS
部分文档源不可用	返回可用数据源结果

降级返回示例：

{
  "answer": "当前智能总结服务繁忙，已为你返回相关搜索结果。",
  "degraded": true,
  "results": [
    {
      "title": "退款流程说明",
      "url": "https://example.com/refund",
      "score": 0.86
    }
  ]
}

七、Nginx高并发配置文件

下面是一份适合AI搜索API网关层的Nginx参考配置。

user nginx;
worker_processes auto;

events {
    worker_connections 65535;
    multi_accept on;
    use epoll;
}

http {
    include       mime.types;
    default_type  application/octet-stream;

    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;

    keepalive_timeout 65;
    keepalive_requests 10000;

    client_max_body_size 10m;
    client_body_timeout 10s;
    client_header_timeout 10s;
    send_timeout 30s;

    access_log /var/log/nginx/access.log;
    error_log  /var/log/nginx/error.log warn;

    gzip on;
    gzip_comp_level 5;
    gzip_min_length 1024;
    gzip_types application/json text/plain text/css application/javascript;

    limit_req_zone $binary_remote_addr zone=ip_limit:20m rate=20r/s;
    limit_req_zone $http_authorization zone=user_limit:20m rate=10r/s;
    limit_conn_zone $binary_remote_addr zone=conn_limit:20m;

    upstream ai_search_backend {
        least_conn;
        server ai-search-api-1:8000 max_fails=3 fail_timeout=10s;
        server ai-search-api-2:8000 max_fails=3 fail_timeout=10s;
        server ai-search-api-3:8000 max_fails=3 fail_timeout=10s;

        keepalive 512;
    }

    server {
        listen 80;
        server_name search.example.com;

        location /health {
            access_log off;
            return 200 "ok";
        }

        location /api/search {
            limit_req zone=ip_limit burst=40 nodelay;
            limit_req zone=user_limit burst=20 nodelay;
            limit_conn conn_limit 50;

            proxy_http_version 1.1;
            proxy_set_header Connection "";

            proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
            proxy_set_header X-Request-ID $request_id;

            proxy_connect_timeout 2s;
            proxy_send_timeout 30s;
            proxy_read_timeout 60s;

            proxy_buffering off;

            proxy_pass http://ai_search_backend;
        }
    }
}

配置说明：

worker_processes auto：根据CPU核心数自动设置Worker数量；
worker_connections 65535：提高单Worker连接能力；
least_conn：优先将请求转发给连接数较少的实例；
keepalive 512：复用后端连接；
limit_req_zone：设置限流规则；
proxy_buffering off：适合流式输出场景；
proxy_read_timeout 60s：给LLM流式生成留出时间。

八、FastAPI + Gunicorn配置

如果AI搜索服务使用Python FastAPI，可以使用Gunicorn + Uvicorn Worker部署。

1. Gunicorn配置文件

gunicorn.conf.py：

import multiprocessing

bind = "0.0.0.0:8000"

workers = multiprocessing.cpu_count() * 2 + 1
worker_class = "uvicorn.workers.UvicornWorker"

worker_connections = 2000
backlog = 4096

timeout = 60
graceful_timeout = 30
keepalive = 30

max_requests = 10000
max_requests_jitter = 1000

accesslog = "-"
errorlog = "-"
loglevel = "info"

preload_app = False

启动命令：

gunicorn app.main:app -c gunicorn.conf.py

2. 应用层并发限制

settings.yaml：

server:
  host: "0.0.0.0"
  port: 8000
  request_timeout_ms: 60000

concurrency:
  max_search_requests: 1000
  max_llm_requests: 100
  max_embedding_requests: 300
  max_rerank_requests: 200

cache:
  redis_url: "redis://redis:6379/0"
  default_ttl_seconds: 3600
  embedding_ttl_seconds: 86400
  answer_ttl_seconds: 1800
  lock_ttl_seconds: 10

retrieval:
  vector_top_k: 50
  keyword_top_k: 50
  final_top_k: 8
  vector_timeout_ms: 800
  keyword_timeout_ms: 800

llm:
  provider: "openai-compatible"
  base_url: "http://llm-gateway:8080/v1"
  model: "qwen2.5-14b-instruct"
  max_tokens: 1024
  temperature: 0.2
  timeout_ms: 30000
  stream: true

embedding:
  base_url: "http://embedding-service:9000"
  model: "bge-large-zh-v1.5"
  timeout_ms: 1000
  batch_size: 32

rerank:
  enabled: true
  base_url: "http://rerank-service:9100"
  model: "bge-reranker-large"
  timeout_ms: 1200

应用层建议使用信号量控制不同下游服务的并发量：

import asyncio

search_sem = asyncio.Semaphore(1000)
llm_sem = asyncio.Semaphore(100)
embedding_sem = asyncio.Semaphore(300)

async def search_handler(query: str):
    async with search_sem:
        return await do_search(query)

async def call_llm(prompt: str):
    async with llm_sem:
        return await request_llm(prompt)

async def call_embedding(text: str):
    async with embedding_sem:
        return await request_embedding(text)

九、Redis配置文件

Redis在AI搜索中通常承担缓存、分布式锁、限流计数等职责。高并发场景下应注意最大连接数、内存淘汰策略、持久化策略。

redis.conf参考配置：

bind 0.0.0.0
port 6379

tcp-backlog 511
timeout 0
tcp-keepalive 300

databases 16

maxclients 20000

maxmemory 8gb
maxmemory-policy allkeys-lru

appendonly yes
appendfsync everysec

save 900 1
save 300 10
save 60 10000

lazyfree-lazy-eviction yes
lazyfree-lazy-expire yes
lazyfree-lazy-server-del yes

slowlog-log-slower-than 10000
slowlog-max-len 256

hz 20

配置说明：

maxclients 20000：提高最大客户端连接数；
maxmemory-policy allkeys-lru：内存不足时淘汰最近最少使用Key；
appendfsync everysec：性能和数据安全之间的折中；
lazyfree-lazy-expire yes：过期删除异步化，降低阻塞风险；
slowlog：记录慢命令，方便排查性能问题。

需要注意的是，Redis不适合存储过大的LLM答案。如果答案很长，建议只缓存摘要或将完整内容放入对象存储，Redis中保存引用地址。

十、向量数据库优化配置示例

不同向量数据库配置方式不同。这里以Qdrant为例。

qdrant.yaml参考配置：

service:
  host: 0.0.0.0
  http_port: 6333
  grpc_port: 6334

storage:
  storage_path: ./storage
  snapshots_path: ./snapshots
  on_disk_payload: true

  optimizers:
    deleted_threshold: 0.2
    vacuum_min_vector_number: 1000
    default_segment_number: 8
    max_segment_size_kb: 200000
    memmap_threshold_kb: 200000
    indexing_threshold_kb: 20000
    flush_interval_sec: 5
    max_optimization_threads: 4

hnsw_index:
  m: 32
  ef_construct: 128
  full_scan_threshold_kb: 10000
  max_indexing_threads: 4
  on_disk: false

performance:
  max_search_threads: 8
  max_optimization_threads: 4

cluster:
  enabled: true

telemetry_disabled: true

查询时也要合理设置搜索参数：

{
  "vector": [0.12, 0.98, 0.31],
  "limit": 50,
  "params": {
    "hnsw_ef": 128,
    "exact": false
  },
  "with_payload": true,
  "with_vector": false
}

优化建议：

limit不要盲目设置过大，通常召回50～100即可；
with_vector默认关闭，避免返回大向量造成网络开销；
payload字段只返回必要内容；
高频过滤字段应建立索引；
大规模数据应使用分片与副本；
写入和查询高峰尽量错开。

十一、Elasticsearch / OpenSearch配置建议

AI搜索一般不会只依赖向量搜索。对于精确词、品牌词、型号、代码、错误信息等场景，关键词搜索依然非常重要。

索引设置示例：

{
  "settings": {
    "number_of_shards": 6,
    "number_of_replicas": 1,
    "refresh_interval": "5s",
    "index.max_result_window": 10000,
    "analysis": {
      "analyzer": {
        "ik_smart_analyzer": {
          "type": "custom",
          "tokenizer": "ik_smart"
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "title": {
        "type": "text",
        "analyzer": "ik_smart_analyzer"
      },
      "content": {
        "type": "text",
        "analyzer": "ik_smart_analyzer"
      },
      "tenant_id": {
        "type": "keyword"
      },
      "doc_id": {
        "type": "keyword"
      },
      "created_at": {
        "type": "date"
      }
    }
  }
}

查询建议：

避免深分页；
使用search_after替代from + size；
控制高亮字段长度；
对租户、分类、权限字段使用keyword；
写入高峰可以适当调大refresh_interval；
使用只读副本承载查询流量。

十二、Kubernetes部署配置

生产环境建议使用Kubernetes进行弹性扩缩容、健康检查和滚动发布。

1. Deployment配置

ai-search-deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: ai-search-api
  namespace: ai-search
spec:
  replicas: 6
  selector:
    matchLabels:
      app: ai-search-api
  template:
    metadata:
      labels:
        app: ai-search-api
    spec:
      containers:
        - name: ai-search-api
          image: registry.example.com/ai-search-api:1.0.0
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8000
          env:
            - name: ENV
              value: "prod"
            - name: CONFIG_PATH
              value: "/app/config/settings.yaml"
          resources:
            requests:
              cpu: "1000m"
              memory: "2Gi"
            limits:
              cpu: "4000m"
              memory: "6Gi"
          readinessProbe:
            httpGet:
              path: /health/readiness
              port: 8000
            initialDelaySeconds: 10
            periodSeconds: 5
            timeoutSeconds: 2
            failureThreshold: 3
          livenessProbe:
            httpGet:
              path: /health/liveness
              port: 8000
            initialDelaySeconds: 30
            periodSeconds: 10
            timeoutSeconds: 2
            failureThreshold: 3

2. Service配置

apiVersion: v1
kind: Service
metadata:
  name: ai-search-api
  namespace: ai-search
spec:
  selector:
    app: ai-search-api
  ports:
    - name: http
      port: 8000
      targetPort: 8000
  type: ClusterIP

3. HPA自动扩缩容

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: ai-search-api-hpa
  namespace: ai-search
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: ai-search-api
  minReplicas: 6
  maxReplicas: 30
  metrics:
    - type: Resource
      resource:
        name: cpu
        target:
          type: Utilization
          averageUtilization: 65
    - type: Resource
      resource:
        name: memory
        target:
          type: Utilization
          averageUtilization: 70

对于AI搜索系统，仅依靠CPU和内存扩缩容并不充分。更理想的方式是根据以下指标扩缩容：

请求QPS；
P95延迟；
队列长度；
LLM并发数；
GPU利用率；
向量库查询耗时。

十三、Linux系统参数优化

高并发场景下，操作系统参数也需要调整。

/etc/sysctl.conf参考配置：

net.core.somaxconn = 65535
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_max_syn_backlog = 65535

net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15

net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5

fs.file-max = 2097152

生效命令：

sysctl -p

文件句柄限制：

* soft nofile 1048576
* hard nofile 1048576

查看当前限制：

ulimit -n

十四、压测方案与关键指标

高并发优化不能只凭经验，必须通过压测验证。

1. 压测工具

常用工具包括：

wrk；
k6；
JMeter；
Locust；
Vegeta；
Gatling。

2. k6压测脚本示例

search-test.js：

import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 500 },
    { duration: '5m', target: 1000 },
    { duration: '2m', target: 0 }
  ],
  thresholds: {
    http_req_duration: ['p(95)<3000'],
    http_req_failed: ['rate<0.01']
  }
};

export default function () {
  const payload = JSON.stringify({
    query: '如何申请退款？',
    stream: false
  });

  const params = {
    headers: {
      'Content-Type': 'application/json',
      'Authorization': 'Bearer test-token'
    },
    timeout: '60s'
  };

  const res = http.post('http://search.example.com/api/search', payload, params);

  check(res, {
    'status is 200': (r) => r.status === 200,
    'has answer': (r) => r.body && r.body.length > 0
  });

  sleep(1);
}

运行命令：

k6 run search-test.js

3. 必须关注的指标

指标	说明
QPS	系统每秒处理请求数
P50/P90/P95/P99	不同百分位响应时间
Error Rate	错误率
Timeout Rate	超时比例
Cache Hit Rate	缓存命中率
Redis Latency	Redis延迟
Vector Search Latency	向量检索延迟
LLM First Token Time	首Token时间
LLM Tokens/s	生成速度
CPU / Memory	应用资源使用
GPU Utilization	模型推理资源使用
Queue Length	排队长度

AI搜索系统尤其要关注两个指标：

首Token时间
对流式问答体验影响极大。
端到端P95延迟
能真实反映大多数用户的等待体验。

十五、上线前检查清单

上线前建议逐项检查：

[ ] Nginx是否配置连接复用和限流；
[ ] 应用服务是否无状态，是否可水平扩容；
[ ] Redis是否设置最大内存和淘汰策略；
[ ] 所有外部调用是否设置超时；
[ ] LLM是否限制最大并发和最大Token；
[ ] 向量库是否关闭不必要的向量返回；
[ ] 是否有缓存击穿保护；
[ ] 是否有熔断和降级策略；
[ ] 是否配置健康检查；
[ ] 是否支持滚动发布；
[ ] 是否有完整监控指标；
[ ] 是否进行过峰值压测；
[ ] 是否有应急开关；
[ ] 是否有慢查询日志；
[ ] 是否有容量预估报告。

十六、推荐的整体参数基线

以下是一套中等规模AI搜索系统的初始参数，可根据实际压测结果调整：

模块	参数	建议值
Nginx	worker_connections	65535
Nginx	keepalive_requests	10000
API实例	replicas	6起步
API服务	单实例最大并发	500～2000
Redis	maxclients	20000
Redis	maxmemory-policy	allkeys-lru
向量召回	top_k	30～100
Rerank	rerank数量	20～50
LLM	max_tokens	512～1024
LLM	timeout	30～60秒
缓存	答案TTL	10分钟～2小时
缓存	Embedding TTL	1天～7天