如何让Django API支持多用户同时访问？是否可使用ThreadPooling实现？

线程池（ThreadPooling）是否适用 #

首先明确结论：线程池能在特定场景下缓解并发压力，但对你当前的纯CPU计算的两数求和接口，收益非常有限，不推荐作为核心方案。
原因如下：

• Django默认运行在同步WSGI服务器上，单进程单线程模式下同一时间只能处理1个请求。如果是服务器层面配置线程池（比如Gunicorn sync worker开多线程、uWSGI配置线程参数），对于IO密集型请求（涉及数据库查询、第三方接口调用）能通过线程切换填充IO等待的空窗期，提升并发量；但你这个接口是纯CPU计算逻辑，Python的GIL全局解释器锁会限制同一时间只有1个线程能执行CPU计算任务，线程切换的开销甚至会超过逻辑本身的执行开销，反而降低处理效率。
• 如果是在Django视图内部用concurrent.futures.ThreadPoolExecutor执行业务逻辑，对这个场景完全没有收益，属于冗余设计。

可落地的高并发处理方案 #

按优先级从高到低推荐如下方案：

• 基础方案：使用多进程模式部署Django服务
  用Gunicorn、uWSGI等生产级WSGI服务器启动服务时，配置worker进程数为 CPU核心数*2 + 1，每个进程独立持有GIL锁，能充分利用多核CPU的计算能力，完美适配你这个CPU密集型的接口场景，并发处理能力可以线性跟随CPU核心数提升。
• 扩展方案（后续接口新增IO逻辑时使用）：
  升级到ASGI部署模式，用Uvicorn作为服务器，搭配Django 3.1+版本支持的异步视图，对于存在IO等待的请求，通过协程切换可以把单进程并发量提升到数千甚至上万的级别。如果不想改代码，也可以直接把Gunicorn的worker换成gevent模式，通过猴子补丁把同步IO替换为异步非阻塞IO，不改业务代码就能大幅提升IO密集型请求的并发量。
• 高并发扩容方案：
  如果单服务器性能达到瓶颈，首先可以加缓存：对于重复率高的请求参数，用Django内置缓存或者Redis缓存求和结果，命中缓存的请求直接返回，不用执行计算逻辑，并发能力可以提升几个数量级。如果缓存还是顶不住，可以在前端加Nginx做反向代理负载均衡，把请求分发到多台Django应用服务器上，通过水平扩容无限提升并发处理能力。

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