Webman需搭配Redis Pub/Sub、异步消息队列和微服务拆分才能支撑企业级IM：连接管理须异步广播、状态同步依赖Redis、离线消息需异步落库、部署须严格隔离功能模块。
Webman 本身轻量、基于 libev 和 libwebsockets，适合做高并发长连接服务，但直接拿来搭企业级 IM 容易在连接数上升后卡在消息广播、状态同步或存储写入上。关键不是“能不能扛住”，而是“扛住时有没有隐性瓶颈”。
WebSocket 连接管理：别让 webman_socket_send() 成为性能杀手
Webman 的 webman_socket_send() 是阻塞式调用，如果在主线程里对成百上千个连接逐个调用，会严重拖慢响应——尤其当部分客户端网络差、TCP 窗口满、内核 send buffer 满时，单次调用可能卡几十毫秒。
- 必须把广播逻辑移到异步线程或事件循环外处理，例如用
libev的ev_async触发批量发送，或用无锁队列（如 ringbuffer）暂存待发消息 - 避免在
websocket_dispatch回调里做任何耗时操作（比如查 DB、调外部 API），只做协议解析 + 入队 - 连接数超 5000 时，建议按用户归属分组（如按部门 ID 或租户 ID 哈希），只向目标组内连接广播，而不是全量遍历
webman_get_all_sockets()
消息路由与状态同步：用 Redis Pub/Sub 替代内存广播
单机 Webman 实例的内存广播无法横向扩展，多实例部署后，A 实例上的用户发的消息，B 实例上的接收方根本收不到——这是企业级 IM 最常见的“消息不一致”根源。
Webman 2.2.0版本强化了 TCP/UDP 服务支持，优化路由组管理，并增强异步任务处理能力。结合协程与连接池技术，Webman 能轻松应对高并发场景，适用于网站、接口服务、即时通讯、物联网及游戏开发，兼具高性能、灵活扩展与稳定可靠，是多场景 PHP 服务开发的理想选择。
- 所有消息投递走
Redis PUB/SUB或Redis Stream，每个 Webman 实例订阅同一 channel，收到后只推给本机已连接的对应用户 - 用户在线状态不能只存在进程内存里，要用
Redis SETEX存心跳，配合KEYSPACE 通知或定时扫描清理离线态 - 群组成员关系建议用
Redis ZSET存，按 last_active_time 排序，方便快速剔除长期不活跃成员，减少广播范围
离线消息与历史记录：别让 SQLite 或 MySQL 直接接 WebSocket 流
Webman 默认不带 ORM，开发者容易图省事，在 websocket_dispatch 里直接 INSERT INTO messages，结果数据库连接池迅速打满，连接排队，整个服务变慢。
- 所有写库操作必须异步化：消息先写入
Redis List或本地LMDB队列，再由独立 worker 进程批量刷入 MySQL/PostgreSQL - 历史消息查询接口要加缓存，
GET /history?uid=123&gid=456&before=1712345678这类请求，结果可SETEX cache:hist:123:456:1712345678 300 … - 千万避免用
SELECT * FROM messages WHERE group_id = ? ORDER BY id DESC LIMIT 50这种语句——必须强制走created_at+id复合索引，且分页用游标（cursor），不用 offset
部署与资源隔离：Webman 不是万能胶水
很多人把用户认证、好友关系、文件上传、音视频信令全塞进一个 Webman 实例，结果一个模块出问题（比如大文件上传卡住 event loop），整个 IM 服务雪崩。
- 严格拆分为多个服务：Auth 服务（JWT 签发）、Presence 服务（管在线态）、Message Router（纯转发）、Storage 服务（对接 MinIO/OSS）
- Webman 实例只做一件事：维持 WebSocket 连接 + 协议编解码 + 转发到内部消息总线（如 Kafka 或 NATS）
- 每个 Webman 实例限制最大连接数（
webman_set_max_connections()），并配置ulimit -n至少 65535，否则 Linux 文件描述符不够会静默断连
真正难的不是让 Webman 接住 10 万连接，而是让这 10 万连接里的每条消息，都以亚秒级延迟、零丢失、可追溯的方式，准确抵达该到的人——这要求你在连接层之上，立刻构建一层可靠的消息中间件和状态协调机制，而不是指望 Webman 自己扛下所有。
