Python Web应用实现单聊群聊文件上传聊天功能的稳定方案咨询

我先后在3个不同用户规模的Python Web项目里落地过同类型聊天功能，下面是经过线上2年以上验证的方案，没有过度设计，运维成本低，性能够稳。

核心技术栈选型 #

别选太偏门的组件，优先选生态成熟、踩坑资料多的栈：

• 服务框架：直接用FastAPI，原生ASGI支持WebSocket，单台4核8G实例无优化就能扛3000-5000并发长连接，比Django Channels性能高至少一倍，开发效率还高。
• 中间件：用Redis做在线状态存储、消息路由中转、热数据缓存，90%的中小规模场景根本不需要上专门的MQ，Redis的Pub/Sub、Stream足够用，运维成本极低。
• 文件存储：私有化部署用MinIO，云上部署直接用对应云厂商的对象存储服务，别把文件存在应用服务器本地，扩容迁移的时候能坑死你。
• 数据库：冷消息、关系数据存PostgreSQL，如果群聊消息量级特别大（日增百万条以上），历史消息归档到ClickHouse，查历史消息速度比MySQL快一个数量级。
• 反向代理：前面挂Nginx做WebSocket连接代理、静态资源缓存、限流，别让外部请求直接打到Python应用服务上。

分模块实现逻辑 #

单聊功能 #

• 连接建立时，把用户ID和对应WebSocket实例的映射存在服务内存+Redis里，客户端每30s发一次心跳包，服务端收到后给Redis里的在线状态续期，超过2个心跳周期没收到包直接判定连接断开，清理死连接。
• 发消息时先查接收方在线状态：在线直接通过内存里的连接映射定向推送消息，别做全局广播，纯纯浪费带宽；不在线就把消息存为离线消息，等用户上线后一次性拉取。
• 加消息ACK机制：客户端收到消息后给服务端回传ACK标识，服务端才把消息标记为已送达，避免网络波动丢消息。
• 核心连接管理代码可以参考这个最简实现：

from fastapi import WebSocket
import redis, json
r = redis.Redis(host="127.0.0.1", port=6379, db=0)

class ChatConnManager:
    def __init__(self):
        self.online_conns: dict[str, WebSocket] = {}

    async def user_connect(self, user_id: str, ws: WebSocket):
        await ws.accept()
        self.online_conns[user_id] = ws
        # 在线状态设置350s过期，心跳续期
        r.setex(f"chat:online:{user_id}", 350, 1)

    def user_disconnect(self, user_id: str):
        if user_id in self.online_conns:
            del self.online_conns[user_id]
            r.delete(f"chat:online:{user_id}")

    async def send_to_user(self, recv_user_id: str, msg_data: dict):
        # 点对点推送，不做无意义广播
        if recv_user_id in self.online_conns:
            await self.online_conns[recv_user_id].send_json(msg_data)

群聊功能 #

• 别做发消息时循环遍历群成员挨个推送的傻事，群消息统一先扔到Redis对应群ID的Stream队列里，每个用户的连接只订阅自己加入的群的消息队列，消费到消息就推给客户端，性能比循环推高好几倍。
• 群成员关系、群公告这类元数据全量缓存到Redis，别每次发消息都查数据库，高并发下数据库很容易被打挂。
• 500人以上的大群开启消息批量推送，把100ms内的多条消息打包成一个网络包发送，减少网络IO开销；万人群这类超大群可以单独做消息拉取模式，别主动推，让客户端每隔几秒拉一次新消息，避免瞬时推送量太大堵死带宽。

文件上传功能 #

• 绝对别走WebSocket通道传文件：大文件传输会占满WebSocket的单连接通道，正常的聊天消息会被堵，延迟直接飙高。
• 文件上传单独走HTTP接口，支持分片上传、断点续传，单文件超过20M就自动分片，每片2M大小，上传完服务端做合并。
• 文件校验别只看后缀名，必须读文件头判断真实文件类型，防止用户传恶意脚本、可执行文件。
• 文件存到对象存储后，只把文件ID、访问地址、大小、文件名这些元数据当普通聊天消息，通过WebSocket推给接收方就行，接收方点击再去下载/预览文件。

稳定性&性能优化要点 #

• Nginx配置WebSocket代理的时候，一定要把proxy_read_timeout设成300s以上，配合客户端30s一次的心跳，避免Nginx主动掐断空闲连接。
• 做分实例消息路由：多实例部署的时候，每个服务实例只负责推送连在自己机器上的用户的消息，别跨实例推消息，减少跨服务调用开销。
• 消息分冷热存储：7天内的热消息存在Redis里，用户拉取近期消息直接走缓存，7天以上的冷消息定期归档到数据库，别占宝贵的内存资源。
• 加限流规则：普通用户单秒最多发5条消息，群聊非管理员单秒最多发2条，防止恶意刷消息把服务打崩。
• 客户端重连用指数退避策略：第一次断了等1s重连，第二次等2s，最长等30s，别断了就疯狂发重连请求，把服务端连接池打满。

实际踩坑提醒：别一开始就上微服务、消息集群这类复杂架构，日活10万以内的场景，单台4核8G服务器跑FastAPI+Redis+MinIO+PostgreSQL完全能扛住，架构越简单，出故障的概率越低，排查问题也越快。

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