企业官网建设流程全解析

来源：程序员老廖

功能概览

• 用户注册/登录：用户名+密码注册，MySQL 存储，INSERT IGNORE 原子去重

• Token 认证：登录后 Redis 存储 token，1 小时过期

• WebSocket 实时聊天：RFC 6455 完整实现，支持文本帧、Ping/Pong、Close

• 消息持久化：Redis List 存储最近 200 条聊天记录

• 历史消息推送：WebSocket 连接建立后推送最近 50 条历史消息

• 全员广播：消息实时推送给所有在线 WebSocket 客户端

• HTTP Keep-Alive：复用 TCP 连接减少开销

• 嵌入式前端：商业 IM 风格 UI，左右分栏布局，彩色头像，连接状态指示器，响应式适配

系统架构

整体架构

线程模型

数据流

用户注册流程

WebSocket 聊天消息流程

文件结构与模块职责

chatapp/ | +-- coro_net.h 核心协程网络层 | |-- FireAndForget 协程返回类型，启动即忘 | |-- Worker epoll 事件循环 + 协程句柄管理 + 跨线程调度 | |-- AsyncRead 异步 socket 读 awaiter | |-- AsyncWrite 异步 socket 写 awaiter | +-- SwitchToWorker 跨线程切换 awaiter | +-- async_redis.h Redis 异步访问层 | |-- RedisAwaiter Redis 命令结果容器 | |-- WorkerRedis hiredis-async 适配器，集成 Worker epoll | +-- AsyncRedisCommand co_await Redis 命令 awaiter | +-- async_mysql.h MySQL 异步访问层 | |-- ThreadPool 通用线程池，条件变量调度 | |-- MySQLPool MySQL 连接池，阻塞 acquire/release | |-- MySQLResult SQL 查询结果 | |-- AsyncMySQLQuery co_await SQL 执行 awaiter | +-- mysql_escape SQL 参数转义 | +-- http_server.h HTTP 协议层 | |-- HttpRequest 请求解析：方法、路径、头、body、JSON、Cookie | |-- HttpResponse 响应构建：状态码、头、body、JSON、重定向 | +-- json_escape JSON 字符串转义 | +-- websocket.h WebSocket 协议层 | |-- ws_crypto SHA1 + Base64 握手算法 | |-- WSOpcode 帧类型枚举 | |-- WSFrame 帧结构 | |-- ws_encode_frame 服务端帧编码，无 mask | |-- WSClient 在线客户端信息 | +-- WSManager 连接管理器，广播 | +-- chat_page.h 嵌入式前端页面（从 chat_app.h 分离） | +-- HTML_PAGE 商业 IM 风格前端（左右分栏、彩色头像、连接状态） | +-- chat_app.h 业务逻辑层 | |-- generate_token 随机 token 生成 | |-- hash_password FNV-1a 密码哈希 | |-- handle_http_conn HTTP/WebSocket 主协程 | +-- 路由处理 注册/登录/发消息/获取消息/WebSocket | +-- main.cpp 入口 | |-- worker_thread Worker 线程函数 | |-- init_mysql_tables 建表 | +-- main 参数解析、初始化、accept 循环 | +-- Makefile 编译脚本 +-- benchmark.cpp HTTP 压测工具 +-- ws_bench.cpp WebSocket 压测工具 +-- bench_layers.cpp 分层性能测试 +-- bench_pool.sh 连接池参数调优脚本 +-- test_ws.py WebSocket 功能测试脚本

项目源码：C++20协程项目-高并发Web聊天室，包括协程如何调用MySQL+Redis

核心设计详解

协程网络层 coro_net.h

这是整个系统的基石，将 epoll 事件驱动与 C++20 协程无缝结合。

FireAndForget —— 协程返回类型

class FireAndForget { struct promise_type { FireAndForget get_return_object() { return {}; } std::suspend_never initial_suspend() { return {}; } // 创建即启动 std::suspend_never final_suspend() noexcept { return {}; } // 结束不挂起 void return_void() {} void unhandled_exception() { std::terminate(); } }; };

FireAndForget 是一种 "启动即忘" 的协程。协程创建后立即开始执行（ initial_suspend 返回

suspend_never ），执行完成后自动销毁（ final_suspend 返回 suspend_never ）。调用者不需要管理协程生命周期。

这种设计适用于 "每连接一个协程" 的模型：accept 后创建协程，协程自己管理 fd 的整个生命周期。

Worker —— epoll 事件循环

Worker 是系统的核心调度器，每个 Worker 在独立线程上运行，管理：

1. epoll 事件循环：处理 socket IO 事件

2. 协程句柄映射：fd → coroutine_handle 的映射表

3. ready_events 缓存：处理事件到达但协程未注册 handle 的时序窗口

4. 跨线程唤醒：eventfd 机制，支持从任意线程唤醒 Worker

5. 自定义 FdHandler：支持 hiredis-async 等第三方库注册自己的 fd 处理逻辑

AsyncRead/AsyncWrite —— 异步 IO Awaiter

关键优化： await_ready 的先尝试读取（fast path）避免了在数据已就绪时不必要的 suspend/resume 开销。高吞吐场景下，大部分 IO 操作可以在 await_ready 中直接完成。

Redis 异步访问 async_redis.h

Redis 使用 hiredis-async 库，与 Worker 的 epoll 深度集成。

每 Worker 一个 Redis 连接的设计：

• Redis 协议天然支持 pipeline —— 多个命令可以在一个 TCP 连接上交错发送

• hiredis-async 内部维护命令队列，自动 pipeline

• 一个连接即可服务该 Worker 上的所有协程，无需连接池

MySQL 异步访问 async_mysql.h

MySQL C API ( libmysqlclient ) 是同步阻塞的，无法直接集成到 epoll。解决方案：线程池 + 连接池 + 协程挂起。

关键设计决策：

1. 为什么不用 MySQL 非阻塞 API？

• MySQL C API 的非阻塞模式需要 mysql_real_connect_nonblocking 等函数，API 复杂且文档不足

• MariaDB Connector/C 的非阻塞 API 与 MySQL 不兼容

• 线程池方案简单可靠，性能损失可控

2. 连接池大小如何选择？

• 连接数 = min(CPU 核数 x 2, 并发协程数)

• 8-16 连接已足够饱和大部分场景（MySQL IO 本身是瓶颈）

• 连接过多反而增加 MySQL 内部锁竞争

3. 协程如何不阻塞 Worker 线程？

• await_suspend 把 SQL 任务提交到 ThreadPool 后立即返回

• Worker 线程可以继续处理其他协程的 IO 事件

• SQL 执行完成后通过 worker->schedule + eventfd 唤醒 Worker

HTTP 协议层 http_server.h

实现了 HTTP/1.1 的核心子集：

• 请求解析：方法、路径、Query String、Headers、Body、JSON 提取

• 响应构建：状态码、Headers、Content-Length 自动计算

• Keep-Alive：通过 Connection header 判断是否复用连接

• 无第三方依赖：手写解析器，约 230 行代码

WebSocket 协议层 websocket.h

完整实现 RFC 6455 WebSocket 协议：

WebSocket 帧格式 (RFC 6455 Section 5.2)：

客户端→服务端：必须 mask（4 字节 XOR 密钥）

服务端→客户端：不能 mask

WSManager —— 连接管理与广播

class WSManager { map<int, WSClient> clients_; // fd -> client info mutex mu_; void broadcast(const string& message) { string frame = ws_encode_frame(WS_TEXT, message); lock_guard lock(mu_); for (auto& [fd, client] : clients_) { ::write(fd, frame.data(), frame.size()); // 同步写 } } };

业务逻辑层 chat_app.h

前端 UI 架构

嵌入式前端采用商业 IM 风格设计，参考微信 Web / Telegram 等产品的交互范式：

配色方案：

前端特性：

核心协程生命周期

handle_http_connection 是系统的核心协程，管理单个 TCP 连接的完整生命周期：

协程并发模型

本项目采用 "每个连接一个协程" 的并发模型。每当主线程 accept 一个新的客户端 TCP 连接时，就会创建一个独立

的 handle_http_connection 协程实例。该协程独立管理这个连接的完整生命周期：从读取 HTTP 请求、路由分

发、到 WebSocket 消息循环、最终关闭连接。

一个连接 = 一个协程

关键特征：

• 每个连接独立：协程 A 的 co_await AsyncRead 挂起时，Worker 线程立刻去执行协程 B 的就绪操作，不会阻塞

• M:N 映射：M 个协程映射到 N 个 Worker 线程。当前默认 N=4，可支撑 10,000+ 并发连接

• 连接亲和性：一个协程从创建到销毁始终在同一个 Worker 线程上运行，不跨线程迁移

FireAndForget —— 启动即忘的协程生命周期

handle_http_connection 的返回类型是 FireAndForget ，这并不意味着"发出去就不管了"，而是 "调用者不需要 co_await 等待它完成" 。协程创建后自行运行，直到连接关闭时自动销毁：

协程调度全景图

与其他并发模型的对比

本项目的协程模型兼具了线程的 代码可读性 和事件驱动的 性能。每个连接的处理逻辑看起来就像普通的顺序代 码，但在 co_await 处自动让出执行权，让 Worker 线程去服务其他连接。

请求处理全流程

HTTP 请求处理流程

用户注册流程

为什么用 INSERT IGNORE 而不是 SELECT + INSERT？

• 原子性：没有检查和插入之间的竞态条件

• 单次 SQL：一次往返替代两次

• +88% QPS：从 5.4K 提升到 10.1K

用户登录流程

WebSocket 建连流程

WebSocket 消息流程

协程调度机制

Worker 事件循环

AsyncRead/AsyncWrite 原理

三阶段协议：

为什么要在 await_ready 中先尝试 syscall？

高吞吐场景下，TCP 接收缓冲区经常有数据，try-first 可以跳过整个 suspend/resume 流程。

跨线程调度 SwitchToWorker

ready_events 缓存机制与 Bug 修复

问题场景

Stale ready_events Bug ====================== Timeline: t0: Main thread accept(fd=37), add_client_fd(37, EPOLLIN|EPOLLET) Data is already in TCP buffer (client sent HTTP request) t1: Worker epoll_wait returns EPOLLIN for fd=37 But handles_[37] is nullptr (coroutine hasn't registered yet) --> ready_events_[37] = EPOLLIN (cached!) t2: Coroutine starts, first AsyncRead: await_ready: ::read(37) succeeds! returns data --> return true (no suspend needed) --> ready_events_[37] is NOT cleared t3: ... HTTP processing, WebSocket handshake ... t4: WebSocket msg loop, AsyncRead for new frame: await_ready: ::read(37) returns EAGAIN (no data) --> return false, proceed to await_suspend t5: await_suspend -> set_client_handle(37, h) Worker finds ready_events_[37] has EPOLLIN --> immediately resume coroutine! t6: await_resume: ::read(37) returns -1 (EAGAIN!) --> return -1 t7: WebSocket loop: if (n <= 0) break; --> Connection closed! BUG!

修复方案

bool await_ready() { result_ = ::read(fd_, buf_, len_); if (result_ >= 0 || (errno != EAGAIN && errno != EWOULDBLOCK)) { // 读取成功，清除可能残留的 stale ready_events if (t_worker) t_worker->clear_ready_events(fd_); return true; } return false; }

同时在 WebSocket 消息循环中增加 EAGAIN 防御性重试：

ssize_t n; do { n = co_await AsyncRead(client_fd, (char*)header, 2); } while (n < 0 && (errno == EAGAIN || errno == EWOULDBLOCK || errno == EINTR)); if (n <= 0) break;

双层防御：

1. clear_ready_events 从根源消除 stale 缓存

2. EAGAIN 重试作为额外保险

连接复用策略

Redis：每 Worker 一个 hiredis-async 连接

为什么不用连接池？

Redis 单线程处理命令，pipeline 已达最大吞吐

多连接到同一 Redis 实例不会提升性能

一个连接简化了管理，减少了资源消耗

MySQL：全局连接池 + 线程池

为什么不直接在协程中使用 MySQL？

• MySQL C API 是同步阻塞的，会阻塞整个 Worker 线程

• 一个被阻塞的 Worker 线程意味着该 Worker 上的所有协程都停止调度

• 线程池隔离了阻塞操作，Worker 线程永远不会被 MySQL 阻塞

编译与运行

依赖安装

sudo apt install g++ libhiredis-dev libmysqlclient-dev redis-server mysql-server

数据库准备

mysql -u root -e " CREATE DATABASE IF NOT EXISTS chatapp CHARACTER SET utf8mb4; CREATE USER IF NOT EXISTS 'chatuser'@'localhost' IDENTIFIED BY 'chatpass'; GRANT ALL PRIVILEGES ON chatapp.* TO 'chatuser'@'localhost'; FLUSH PRIVILEGES; "

编译

make # 编译 chatserver, benchmark, ws_bench make clean # 清理

运行

./chatserver --port 9090 --workers 4 --mysql-user chatuser --mysql-pass chatpass

浏览器访问 http://127.0.0.1:9090

完整参数

./chatserver [options] --port N HTTP 端口 (默认: 8080) --workers N Worker 线程数 (默认: 4) --redis-host H Redis 地址 (默认: 127.0.0.1) --redis-port N Redis 端口 (默认: 6379) --mysql-host H MySQL 地址 (默认: 127.0.0.1) --mysql-port N MySQL 端口 (默认: 3306) --mysql-user U MySQL 用户 (默认: root) --mysql-pass P MySQL 密码 (默认: 空) --mysql-db D MySQL 数据库 (默认: chatapp) --mysql-pool N MySQL 连接池大小 (默认: 8) --thread-pool N 线程池大小 (默认: 8)

性能测试

测试环境：单机，MariaDB 10.6，Redis 7.x，g++ 11.4，C++20，4 Worker 线程

HTTP 注册/登录性能

压测工具

./benchmark [options] -h HOST 目标地址 (默认: 127.0.0.1) -p PORT 目标端口 (默认: 9090) -t N 线程数 (默认: 4) -c N 每线程连接数 (默认: 1) -n N 总请求数 (默认: 1000) -m MODE 模式: register 或 login -k 启用 Keep-Alive

注册性能

登录性能

WebSocket 性能

压测工具

./ws_bench [options] -h HOST 目标地址 (默认: 127.0.0.1) -p PORT 目标端口 (默认: 9090) -c N 并发连接数 (默认: 100) -n N 总消息数 (默认: 1000) -t N 线程数 (默认: 4) -m MODE 模式: connect, throughput, echo, concurrent

连接容量

4 Worker 线程可维护 10,000+ 并发 WebSocket 长连接。连接建立耗时主要来自 HTTP 注册/登录，WebSocket握手本身很快。

回声延迟（单发送者 + N-1 旁观者）

100 连接以内，P50 延迟 < 1ms。500 连接时广播成为瓶颈，延迟急剧上升。

消息吞吐量（发送 + 广播全接收）

消息零丢失。发送 QPS ~15-20K，广播 QPS ~2.5-3.8K（计入 N 倍扇出）。

并发回声（多连接同时发+收）

并发模式下 QPS 稳定在 ~20K echo/s，P50 < 0.3ms。

总结

本项目展示了 C++20 协程在实际网络应用中的完整实践：

协程的核心价值：用同步代码的可读性，获得异步代码的性能。

项目源码：C++20协程项目-高并发Web聊天室，包括协程如何调用MySQL+Redis