1. 重发时机与超时策略
在 Java WebSocket 场景下，传输层的可靠性由 TCP 保证，但应用层的逐条消息交付仍需要额外设计。消息重发机制通常通过对发送端的未确认消息进行追踪来实现，确保在对端未返回 ACK 时进行再发送，以提升系统的可靠性。
触发重发的条件一般包括：未收到对等端的 ACK、收到显式的 NACK 或超过设定的超时时间（timeout）。在设计时应避免盲目重复发送，需结合最大重发次数与退避策略来防止资源耗尽。
在实现层面，每条待确认消息都应具备唯一标识，发送端维护一个 Outbox，记录待确认消息、重发次数以及下一次超时点。若在超时点仍未收到确认，则触发下一轮重发。
下面给出一个示例要点：ACK/超时是应用协议面的确认信号，WebSocket 自身不会强制执行消息级别确认，因此“看门狗定时器”和“重发队列”成为关键组成。
1.1 触发重发条件要点
在设计时应明确以下要点：ACK 未到达、收到 NACK、以及超过最大重发次数时应停止重发并触发上层错误处理。合理的重发策略可以避免网络抖动带来的临时丢包，同时防止对端在异常场景下的重复处理。
一个常见做法是对每条消息设置一个 首发超时，随后进入指数退避模式，逐步增加超时间隔，并在每次重发后重新计算动态超时。该策略有助于在高并发场景下控制网络压力。
1.2 超时与退避策略
超时参数通常包括 初始超时、最大超时、以及 最大重发次数。在实际环境中，建议结合网络往返时延（RTT）和抖动情况来设定。
指数退避结合抖动可以降低对网络的冲击：在每次重发前对超时进行乘法放大，并引入少量随机抖动，避免多个客户端在同一时刻触发重发风暴。实现时应确保在达到上限后能稳定退出重传循环。
2. 幂等性设计与实现要点
为了避免重复处理造成的数据错误，幂等性是应用层可靠传输的核心。通过对消息引入全局唯一标识（message_id），服务端在处理时能够判断该消息是否已经被处理过，若已处理则只返回确认而不再次执行业务逻辑。
幂等性键通常是来自发送端的唯一消息标识，服务器端需要将该标识与处理结果绑定，确保同一标识的重复请求不会带来重复的业务效果。
2.1 幂等性的定义与重要性
幂等性定义为对同一请求的多次执行，业务结果保持不变。为了确保幂等性，需要在客户端和服务器端共同维护唯一键和处理状态，避免重复消费、重复扣款或重复写入数据库。
在分布式环境中，去重是实现幂等性的关键步骤，通常借助唯一索引、时间窗或分布式锁来防止重复执行。
2.2 去重与幂等键实现
常见做法是：在数据库中创建一个 去重表，把每条消息的 message_id 作为主键；在处理前先查询该键是否存在，若存在则直接返回成功的 ACK；若不存在则写入记录后继续执行业务。
实现细节包括：消息的 TTL，防止去重表无限增长；对高并发写入进行索引优化；以及在失败场景下对去重表的回滚策略进行设计。
3. 客户端与服务端实现要点
在实际应用中，客户端需要维护一个持续可用的发送队列与一个健康心跳机制，以确保连接稳定时序的一致性。Outbox、ACK 跟踪、心跳是关键组成。
服务端需要处理的核心点包括：去重校验、幂等性处理、以及对ACK/NACK进行正确的回执，确保客户端能够正确进入下一轮重传逻辑。
3.1 客户端实现要点
客户端应具备以下能力：发送未确认消息、收到 ACK 时从队列移除、超时触发重传、以及在网络断开时进行重连策略的保护性设计。
另外，客户端应提供清晰的失败回调，以便上层业务能够在不可恢复的情况下执行降级处理，同时保持日志的完整性以便排错。
3.2 服务端实现要点
服务端的核心目标是确保幂等性与正确的确认回执。收到消息后先进行去重检查，若为新消息则执行业务逻辑并返回 ACK；若为重复消息则直接返回先前的确认结果，避免重复处理。
此外，服务器端应实现对连接状态的合理管理，例如在客户端离线时缓存未确认消息、在恢复连接时重新发送未确认的消息等策略。
4. Java 实现示例
4.1 基本框架与依赖
在 Java WebSocket 实现中，可以选择 Jakarta WebSocket（org.glassfish.jersey 或 Tyrus 实现）或 Java EE WebSocket API。核心要素包括 Session、MessageId、调度任务与去重存储。下面给出一个简化的依赖清单与骨架说明。
<dependencies><dependency><groupId>org.glassfish.tyrus</groupId><artifactId>tyrus-server</artifactId><version>1.13.0</version></dependency><dependency><groupId>com.fasterxml.jackson.core</groupId><artifactId>jackson-databind</artifactId><version>2.12.3</version></dependency>
</dependencies>在实际项目中，还需要引入异步 IO、并发容器以及日志组件以提升性能与可观测性。
4.2 发送端代码示例
下面给出一个简化的发送端实现要点，展示如何给每条消息附加唯一标识、设置超时、以及在 ACK 來临前进行重传：
import javax.websocket.CloseReason;
import javax.websocket.Session;
import java.util.UUID;
import java.util.concurrent.*;public class WebSocketMessageSender {private final Session session;private final ConcurrentMap outbox = new ConcurrentHashMap<>();private final ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();private final int maxRetries = 5;private final long initialTimeoutMs = 200; // 初始超时时间public WebSocketMessageSender(Session session) {this.session = session;}public void sendWithRetry(String payload) {String id = UUID.randomUUID().toString();MessagePacket pkt = new MessagePacket(id, payload);Pending p = new Pending(pkt, 0, initialTimeoutMs);outbox.put(id, p);send(pkt);scheduleRetry(id, p.timeoutMs);}private void send(MessagePacket pkt) {// 将 pkt 序列化为 JSON 并通过 WebSocket 发送String text = pkt.toJson();session.getAsyncRemote().sendText(text);}private void scheduleRetry(String id, long timeout) {scheduler.schedule(() -> {Pending p = outbox.get(id);if (p != null && !p.ackReceived) {if (p.retries >= maxRetries) {outbox.remove(id);// 业务层面可触发回调或日志return;}p.retries++;// 指数退避long nextTimeout = Math.min(timeout * 2, 60000);p.timeoutMs = nextTimeout;send(p.packet);scheduleRetry(id, nextTimeout);}}, timeout, TimeUnit.MILLISECONDS);}// 收到 ACK 时调用public void acknowledge(String id) {Pending p = outbox.remove(id);if (p != null) {p.ackReceived = true;}}private static class MessagePacket {final String id;final String payload;MessagePacket(String id, String payload) { this.id = id; this.payload = payload; }String toJson() { return "{\"type\":\"DATA\",\"id\":\"" + id + "\",\"payload\":\"" + payload + "\"}"; }}private static class Pending {final MessagePacket packet;int retries;long timeoutMs;boolean ackReceived;Pending(MessagePacket packet, int retries, long timeoutMs) {this.packet = packet;this.retries = retries;this.timeoutMs = timeoutMs;}}
}
4.3 服务端确认与重传逻辑
服务端需要对收到的消息进行去重、执行业务并返回 ACK。下面是一个简化的服务端端点示例，演示如何处理数据、进行幂等性检查并发送 ACK：
import javax.websocket.OnMessage;
import javax.websocket.Session;
import javax.websocket.server.ServerEndpoint;
import java.util.Set;
import java.util.concurrent.ConcurrentHashMap;@ServerEndpoint("/ws/relay")
public class WebSocketEndpoint {// 简化的去重集合，实际项目应落地到数据库或分布式缓存private static final Set processed = ConcurrentHashMap.newKeySet();@OnMessagepublic void onMessage(String message, Session session) {// 假设消息为 {"type":"DATA","id":"...","payload":"..."}String id = parseId(message);if (id == null) return;// 去重检查if (processed.contains(id)) {// 已处理，直接回 ACKsendAck(session, id);return;}// 处理业务boolean ok = processBusiness(message);// 标记已处理并回 ACKif (ok) {processed.add(id);sendAck(session, id);} else {// 业务失败时也回 ACK，保持幂等性，避免重复执行sendNack(session, id);}}private String parseId(String msg) {// 简单解析，实际应使用 JSON 解析// 取出 "id" 字段int idx = msg.indexOf("\"id\":\"");if (idx < 0) return null;int start = idx + 6;int end = msg.indexOf("\"", start);return end > start ? msg.substring(start, end) : null;}private boolean processBusiness(String msg) {// 在这里实现具体的业务逻辑return true;}private void sendAck(Session session, String id) {String ack = "{\"type\":\"ACK\",\"id\":\"" + id + "\"}";session.getAsyncRemote().sendText(ack);}private void sendNack(Session session, String id) {String nack = "{\"type\":\"NACK\",\"id\":\"" + id + "\"}";session.getAsyncRemote().sendText(nack);}
}
4.4 幂等性数据库设计
下面给出一个简化的 SQL 设计，用于实现消息级去重与幂等性保障。结合实际场景，可以选择关系型数据库、Redis 等存储介质。
-- 去重表：仅存放已处理消息的唯一标识
CREATE TABLE message_deduplication (message_id VARCHAR(128) PRIMARY KEY,processed_at TIMESTAMP WITHOUT TIME ZONE DEFAULT now(),payload TEXT
);-- 插入前先检查是否存在，存在则视为重复
-- 示例伪代码：
-- INSERT INTO message_deduplication (message_id, payload)
-- VALUES (?, ?)
-- ON CONFLICT (message_id) DO NOTHING;
在分布式场景中，去重表应具备高并发写入能力，并设置恰当的 TTL/过期策略，以避免过去消息的长期占用。此外，也可将幂等键放在 Redis 的 Set 或 Bloom Filter 中以降低数据库压力。
5. 常见问题与性能考量
5.1 网络抖动与重传压力
在网络抖动高的环境中，重传压力可能上升，应通过限流、并发控制和合适的退避策略来缓解。对关键路径可以使用自适应超时算法，根据观测到的 RTT 动态调整初始超时与最大超时。
另外，对端不可达的情况应有明确的降级策略，例如将未确认消息持久化到本地日志，待网络恢复后再尝试发送，以避免数据丢失。
5.2 资源与并发管理
实现发送队列的容量控制和并发写入的保护，避免单个客户端因为大量未确认消息而消耗过多内存或阻塞线程。可通过容量上限、队列回压机制以及对重试任务的动态调度来实现。
为提升可观测性，应对每条消息留存完整的追踪信息（ID、发送时间、重试次数、最后一次状态），并将日志聚合到集中监控系统，帮助排错与容量规划。
