WebSocket消息不丢需服务端落库，核心是消息到达即写入Kafka/Redis Stream等持久化队列，由独立消费者异步刷库，避免阻塞连接线程；高并发下应批量写入并校验字段长度，Kafka+Flink组合可保障Exactly-Once语义与系统稳定性。
WebSocket长连接断开后消息怎么不丢
靠客户端重连时主动拉取，基本不可行。真实场景中用户离线可能长达数小时，服务端必须在连接存活期间就完成关键消息的落库动作，否则重连时根本不知道该补哪几条。
核心原则是：消息到达服务端 → 立即写入持久化队列（如 Kafka / Redis Stream）→ 由独立消费者异步刷库，而不是在 WebSocket 处理线程里直接 INSERT INTO。这样既避免阻塞连接读写，又解耦了网络稳定性和数据库可用性。
- 不要在
onTextFrame回调里调用 JDBCexecuteUpdate—— 数据库慢查询会拖垮整个连接的读事件循环 - 推荐用
Redis Stream作为中间缓冲：生产者用XADD快速追加，消费者用XREADGROUP实现多实例负载均衡 - 若必须直写 DB，至少包一层
CompletableFuture.supplyAsync（Java）或asyncio.to_thread（Python），并配置超时和降级逻辑
async-http-client 的 ResumableAsyncHandler 能不能直接存消息到 MySQL
不能。它只负责 WebSocket 连接层的断点续传，比如恢复未发完的二进制帧，但不感知业务语义，更不会帮你序列化 JSON、填充 user_id 字段、处理幂等写入。
ResumableAsyncHandler 的持久化目标是「连接状态」，不是「业务消息」；它的 saveState 方法默认写本地文件，你强行改造成写 MySQL，反而会引入连接池竞争、事务死锁、主从延迟导致重复消费等问题。
WebSocket 8.18.2 是该协议规范的一个重要迭代版本，主要优化了连接稳定性与数据传输效率。它通过全双工通信机制，允许客户端与服务器在单一长连接上实时交换数据，大幅降低传统 HTTP 轮询的开销。该版本增强了心跳保活、自动重连及二进制帧传输能力，适用于即时通讯、在线游戏及金融行情推送等低延迟场景，为开发者提供更可靠的实时网络交互基础。
- 真正该持久化的消息，应在
WebSocketListener.onTextFrame中解析 payload 后，构造业务对象再投递到下游队列 - 如果用了 Kafka，建议按
user_id % partition_count分区，保证同一用户的顺序性 - 注意
onTextFrame可能被并发调用（多个帧同时到达），需确保投递逻辑线程安全，比如用无锁队列ConcurrentLinkedQueue
高并发下 WebSocket 消息写 DB 的吞吐瓶颈在哪
不在网络，也不在 SQL，而在事务提交频率和索引维护开销。每条消息都走一次 BEGIN; INSERT; COMMIT，MySQL 的 redolog 刷盘 + binlog 写入 + 二级索引更新，实测单机极限约 1200 QPS，超过就出现 Lock wait timeout exceeded 或 Too many connections。
解决方案不是加机器，而是合并写入：把 10–50ms 内收到的消息攒批（batch），统一用 INSERT INTO ... VALUES (...), (...), (...) 提交。这要求你在内存中维护一个轻量定时器 + 线程安全 buffer。
- 别用
ScheduledExecutorService做定时 flush —— 它无法感知当前 buffer 是否为空，容易空刷 - 推荐用
Disruptor或LMAX RingBuffer替代普通队列，避免 GC 和锁竞争 - 批量写入前务必校验字段长度，防止某条超长消息导致整批
Packet too large失败
为什么 Kafka + Flink 是比直写 MySQL 更稳的选择
因为 Kafka 把「接收」和「落地」彻底分离。WebSocket 服务只需保证消息进 Kafka 不丢（ACK=all + retries=3），后续无论 MySQL 宕机、Flink 作业重启、还是表结构变更，都不影响上游连接的稳定性。
Flink 的 Exactly-Once 语义还能解决最头疼的“重复消费”问题：比如某条消息因网络抖动被重发两次，Kafka 消费者 offset 提交失败，Flink 会自动回滚状态并重放，而直写 MySQL 很难做到幂等且低延迟。
- 别手动管理 Kafka offset，用
FlinkKafkaConsumer内置的 checkpoint 机制 - MySQL sink 推荐用
flink-connector-jdbc的 upsert 模式，配合PRIMARY KEY自动去重 - 注意 Kafka topic 的
retention.ms要设足够长（建议 ≥7 天），避免消费者故障期间消息被自动清理
sideOutputLateData 或单独的 dead-letter topic，而不是让所有消息共用同一个异常分支。 
