MinerU并发问题处理记录
目前是一个mineru，启动了四个相同的服务。需要通过启动多个mineru服务，用户无感的调用一个地址。
方案一
一：外部负载均衡器
- 架构调整
将 NGINX 提取出来，部署在一个独立的容器或服务器上，专门作为外部负载均衡器。后端服务则分别部署在各个容器实例中。 - 工作原理
外部 NGINX 通过健康检查与服务发现机制，自动更新上游服务器列表。这样当某个容器实例不可用时，外部 NGINX 不会再向其转发请求，从而保证高可用性。 - 优点
- 实现了两级负载均衡：外部负载均衡器调度各个容器实例，容器内部可以继续使用 NGINX 做进程或端口级别的分发。 便于监控和故障隔离，提高整个系统的健壮性。
二：利用容器编排平台（如 Kubernetes 或 Docker Swarm）
- 自动化管理
使用编排平台可以自动管理容器的副本数量、健康检查和自动故障恢复。例如 Kubernetes 中的 Service 对象，可以为每个后端 Pod（容器实例）提供统一的访问入口，并自动进行负载均衡。 - 动态服务发现
编排平台会将服务实例注册到内部 DNS 或服务发现机制中，外部的负载均衡器或反向代理可以动态获取健康的服务实例列表，从而实现无缝的流量切换。 - 优点
- 编排平台可以在一个节点故障时自动迁移工作负载，从而提高整体系统的容错能力。 支持滚动更新和扩展，方便运维和管理。
三：虚拟 IP 或 Keepalived 实现高可用
- 虚拟 IP 技术
在同一网络中部署多个容器实例，并通过 Keepalived 或类似技术分配一个虚拟 IP，当一个实例不可用时，自动将虚拟 IP 迁移到健康的实例上。 - 优点
- 实现了快速的故障切换和无缝迁移。 可以在一定程度上屏蔽后端多实例的复杂性，对外提供单一入口。
总结
直接在一个容器内同时运行 NGINX 和应用服务，会导致高可用性受到限制。建议采取如下措施：
- 解耦：将外部负载均衡器（如 NGINX）与应用服务分离部署；
- 编排平台：利用 Kubernetes、Docker Swarm 等工具实现容器副本管理、健康检查和自动恢复；
- 动态配置：采用服务发现或虚拟 IP 方案，确保当新增或移除容器实例时，外部负载均衡器能实时更新其上游列表，从而保证请求流量始终路由到健康实例上。
方案二（超时影响业务）
1.启动4个mineru服务
-gpu-mem ory-limit 4 batch ratio 设置
单机多进程，但仍然是一个服务，不能跨多台机器负载均衡
gunicorn -w 4 -k uvicorn.workers.UvicornWorker main:app --bind 0.0.0.0:8000
多机
uvicorn main:app --host 0.0.0.0 --port 8001 &
uvicorn main:app --host 0.0.0.0 --port 8002 &
uvicorn main:app --host 0.0.0.0 --port 8003 &
2. Python 服务注册到 Nacos
pip install nacos-sdk-python
from nacos import NacosClient
# Nacos 服务器地址
NACOS_SERVER = "127.0.0.1:8848"
SERVICE_NAME = "python-service"
IP = "192.168.1.100" # 服务器 IP
PORT = 8001 # 这个实例的端口
client = NacosClient(NACOS_SERVER)
client.add_naming_instance(SERVICE_NAME, IP, PORT)
print(f"Python 实例 {IP}:{PORT} 注册到 Nacos 成功！")3. Spring Cloud Gateway 进行负载均衡
spring:
cloud:
gateway:
discovery:
locator:
enabled: true # 启用 Nacos 服务发现
routes:
- id: python-service
uri: lb://python-service # 负载均衡到 Python 服务
predicates:
- Path=/python/**
filters:
- name: RequestRateLimiter
args:
redis-rate-limiter.replenishRate: 5 # 每秒 5 个请求
redis-rate-limiter.burstCapacity: 10 # 突发 10 个请求4.挂了怎么启动
Supervisor / Systemd / Docker / Kubernetes 自动重启实例