查看数据库连接池#

SQLite在创建连接时会先进入连接池, 如果连接池已满, 则后续的连接请求会被阻塞, 直到有连接被释放或默认15秒超时后报错退出

但我们未显式设置连接池数量, 默认为128, 对于我们30并发就阻塞卡死的情况, 显然不合理, 并且我们SQLite是WAL模式, 写不阻塞读, 所以排除数据库的问题

TCP连接池满?#

我们使用ss -tan state close-wait -H | wc -l命令查询了系统未关闭的TCP连接数量,

1
mint@MintServer-WH:~$ ss -tan state close-wait -H | wc -l
2
468

结果非常惊人, 有接近500个连接未被关闭, 这非常符合我们刚刚进行的512并发测试, 并且重启服务这些连接也未被关闭.

反复刷新可以发现这些连接在缓慢减少, 说明后端正在缓慢处理这些堆积的请求, 可是这些请求对应的客户端早都超时退出了, 服务器正在做无用功.

大约半小时过去了, 我们还在寻找解决方案时, 后端服务突然恢复了, 重新查看发现未关闭的连接数果然下降到了1, 这也证实了我们的想法

清除大量未关闭的连接#

从网上查到了这行命令lsof -i:<端口号>, 可以查询正在使用端口的进程和状态, 运行显示

1
mint@MintServer-WH:~$ lsof -i:8080
2
COMMAND      PID USER   FD   TYPE   DEVICE SIZE/OFF NODE NAME
3
nginx    3967538 mint   13u  IPv4 50128379      0t0  TCP localhost:47238->localhost:http-alt (ESTABLISHED)
4
gunicorn 4062077 mint    3u  IPv4 48464702      0t0  TCP localhost:http-alt (LISTEN)
5
gunicorn 4062083 mint    3u  IPv4 48464702      0t0  TCP localhost:http-alt (LISTEN)
6
gunicorn 4062083 mint   28u  IPv4 50129369      0t0  TCP localhost:http-alt->localhost:47238 (ESTABLISHED)

ttp-alt 是 /etc/services 中定义的 8080 端口 的服务别名，实际就是端口 8080。

我们是一个典型的 Nginx 反向代理 → Gunicorn 应用服务器 的本地回环通信架构：

• Gunicorn 在 127.0.0.1:8080 上监听 HTTP 请求（两个 LISTEN 是因为 master + worker 共享同一个监听套接字）。

• Nginx 作为客户端主动向 localhost:8080 发起连接（从自己的临时端口 47238 连过去），用来转发外部 Web 请求。

• 输出中的 ESTABLISHED 连接正是 Nginx 与 Gunicorn 之间当前活跃的一条请求通道。

之前使用systemctl --user restart fastapi.service属于优雅关闭, 保留了进程的TCP连接池, 以便重启后能够继续处理未完成的请求, 这就是我们重启也无效的原因 — 大量的请求还未被关闭, 服务上线后依然在按顺序处理这些过时的请求, 新的请求只能在后面排队, 等排到新请求也超时了.

使用kill -9 <进程PID>强制关闭进程, 这里注意要关闭Gunicorn的主进程, 根据上图也就是4062077, 强制关闭后重新检查未关闭连接数量

1
mint@MintServer-WH:~$ ss -tan state close-wait -H | wc -l
2
1

恢复正常, 使用systemctl --user start fastapi.service启动服务, 后端服务正常运行!

优化单线程逻辑#

之前的操作只是从瘫痪中临时恢复, 如果再来一次高并发, 依然会陷入相同的境地, 我可不想每次都上来杀进程:(

解决方案是在FastAPI http中间件里添加信号量, 试了试asyncio但是我好像不太会用(, 所以就自己写了一个

该设计限制了单worker的最大处理数, 在多worker时依然有效, 因为不同worker内存独立, gunicorn会将负载均衡分配到每一个worker上

1
# 请求限制信号量实现
2
class RequestLimiter:
3
    def __init__(self, max_concurrent: int):
4
        self._max = max_concurrent
5
        self._current = 0
6
        self._lock = asyncio.Lock()
7

8
    async def acquire(self) -> bool:
9
        async with self._lock:
10
            if self._current >= self._max:
11
                return False
12
            self._current += 1
13
            return True
14

15
    async def release(self) -> None:
16
        async with self._lock:
17
            if self._current > 0:
18
                self._current -= 1

1
request_limiter = RequestLimiter(5)
2

3
@app.middleware("http")
4
async def log_requests(request: Request, call_next):
5
    if not await request_limiter.acquire():
6
        return JSONResponse({"detail": "server busy"}, status_code=503)
7
    try:
8
        # 处理请求
9
        response = await call_next(request)    # T1. 先处理业务, 获取响应
10
        return response                        # T2. 由于在try块中, python会先记住要返回的值
11
    finally:
12
        await request_limiter.release()        # T3. finally执行, 释放信号量
13
                                               # T4. 函数真正返回

ESA访问频次限制#

在阿里云ESA访问频次限制中, 限制了同一ip在10秒内请求超过60次即触发拦截, 返回403

来感受恶意()