[1]如何设计一个优雅的消息重试机制：我在自研 MQ 项目中的实践

如何设计一个优雅的消息重试机制：我在自研 MQ 项目中的实践

在最近的一次面试中，面试官针对我简历中提到的自研 MQ（消息队列）中间件项目抛出了一个问题："在你的 MQ 项目中，Producer 端是如何实现消息重试机制的？"这个问题看似简单，但实际上考察了我对设计模式、代码封装以及系统健壮性的理解。以下是我当时回答的思路，以及事后的一些总结和优化思考，希望对大家有所启发。

背景：为什么需要消息重试？

在分布式系统中，消息队列是解耦生产者和消费者的利器。然而，网络抖动、服务端故障或消费者处理异常等不可控因素，可能导致消息发送失败。为了提升系统的可靠性和容错能力，Producer 端需要一套优雅的重试机制，确保消息尽可能被成功投递，同时避免无限重试带来的资源浪费。

在我的 MQ 项目中，Producer 既支持单条消息发送，也支持批量发送。针对这两种场景，我设计了一个通用的 Retry 组件，核心目标是：灵活、可扩展、低耦合。

技术选型与设计模式

为了实现这个目标，我结合了多种设计模式：建造者模式（Builder Pattern） 、命令模式（Command Pattern） 和 模板方法模式（Template Method Pattern）。下面逐步拆解我的设计思路。

1. 建造者模式：灵活构造重试参数

消息重试并不是简单地重复发送，而是需要根据业务场景配置不同的参数，比如重试次数、间隔时间、是否指数退避（Exponential Backoff）等。如果通过硬编码或一堆 setter 方法来配置，显然不够优雅且难以扩展。

因此，我引入了建造者模式来封装 Retry 组件的构造过程。以下是一个简化的代码示例：

java 复制代码

public class RetryConfig {
    private int maxAttempts; // 最大重试次数
    private long delay;     // 重试间隔
    private boolean exponentialBackoff; // 是否指数退避

    private RetryConfig(Builder builder) {
        this.maxAttempts = builder.maxAttempts;
        this.delay = builder.delay;
        this.exponentialBackoff = builder.exponentialBackoff;
    }

    public static class Builder {
        private int maxAttempts = 3; // 默认3次
        private long delay = 1000;   // 默认1秒
        private boolean exponentialBackoff = false;

        public Builder setMaxAttempts(int maxAttempts) {
            this.maxAttempts = maxAttempts;
            return this;
        }

        public Builder setDelay(long delay) {
            this.delay = delay;
            return this;
        }

        public Builder enableExponentialBackoff(boolean enable) {
            this.exponentialBackoff = enable;
            return this;
        }

        public RetryConfig build() {
            return new RetryConfig(this);
        }
    }
}

通过建造者模式，用户可以灵活地构造 RetryConfig，例如：

java 复制代码

RetryConfig config = new RetryConfig.Builder()
    .setMaxAttempts(5)
    .setDelay(2000)
    .enableExponentialBackoff(true)
    .build();

这种方式不仅提高了代码的可读性，还为后续扩展（比如添加重试策略）提供了便利。

2. 命令模式：解耦发送逻辑与重试逻辑

在 Producer 端，消息发送是一个核心操作，但发送失败后的重试逻辑不应该与发送本身耦合在一起。为了实现这种解耦，我引入了命令模式，将"发送消息"和"重试发送"抽象为命令（Command）。

例如，我定义了一个 MessageCommand 接口：

java 复制代码

public interface MessageCommand {
    void execute(); // 执行发送逻辑
}

对于单条发送和批量发送，我分别实现了对应的命令类：

java 复制代码

public class SingleMessageCommand implements MessageCommand {
    private Message message;
    private MessageSender sender;

    public SingleMessageCommand(Message message, MessageSender sender) {
        this.message = message;
        this.sender = sender;
    }

    @Override
    public void execute() {
        sender.send(message);
    }
}

public class BatchMessageCommand implements MessageCommand {
    private List<Message> messages;
    private MessageSender sender;

    public BatchMessageCommand(List<Message> messages, MessageSender sender) {
        this.messages = messages;
        this.sender = sender;
    }

    @Override
    public void execute() {
        sender.sendBatch(messages);
    }
}

通过命令模式，发送逻辑被封装成独立的可执行单元，重试组件只需要调用 execute() 方法，而无需关心具体的发送细节。

3. 模板方法模式：统一重试流程

有了灵活的配置和解耦的发送逻辑，下一步是定义一个通用的重试流程。重试的核心步骤通常包括：检查是否需要重试、执行发送、处理失败和等待下一次重试。为了避免代码重复，我使用了模板方法模式。

Retry 组件的核心类设计如下：

java 复制代码

public abstract class RetryTemplate {
    protected RetryConfig config;

    public RetryTemplate(RetryConfig config) {
        this.config = config;
    }

    // 模板方法：定义重试流程
    public void retry(MessageCommand command) {
        int attempts = 0;
        while (attempts < config.getMaxAttempts()) {
            try {
                command.execute();
                return; // 发送成功，退出
            } catch (Exception e) {
                attempts++;
                if (attempts == config.getMaxAttempts()) {
                    handleFailure(e); // 达到最大重试次数，处理失败
                    return;
                }
                waitBeforeRetry(attempts); // 等待下一次重试
            }
        }
    }

    // 钩子方法：子类可自定义失败处理
    protected abstract void handleFailure(Exception e);

    private void waitBeforeRetry(int attempt) {
        long delay = config.isExponentialBackoff() 
            ? config.getDelay() * (1 << attempt) // 指数退避
            : config.getDelay(); // 固定间隔
        try {
            Thread.sleep(delay);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
    }
}

具体实现类可以继承 RetryTemplate，并根据业务需求自定义 handleFailure 逻辑。例如：

java 复制代码

public class ProducerRetry extends RetryTemplate {
    public ProducerRetry(RetryConfig config) {
        super(config);
    }

    @Override
    protected void handleFailure(Exception e) {
        // 记录日志或触发告警
        System.err.println("Message send failed after retries: " + e.getMessage());
    }
}

单条与批量发送的统一实现

有了上述组件，单条发送和批量发送的重试机制就可以通过统一的接口实现：

java 复制代码

RetryConfig config = new RetryConfig.Builder().build();
RetryTemplate retry = new ProducerRetry(config);

// 单条发送
MessageCommand singleCmd = new SingleMessageCommand(message, sender);
retry.retry(singleCmd);

// 批量发送
MessageCommand batchCmd = new BatchMessageCommand(messages, sender);
retry.retry(batchCmd);

设计亮点与优化空间

通过建造者模式，我实现了配置的灵活性；通过命令模式，解耦了发送与重试逻辑；通过模板方法模式，统一了重试流程。这种组合拳的好处在于：

高内聚低耦合：各模块职责清晰，易于维护。
扩展性强：新增发送类型只需实现新的 Command，重试策略调整只需修改 RetryTemplate。
可测试性：每个组件都可以独立单元测试。

当然，事后复盘时，我也想到了一些优化点：

异步重试：当前是同步阻塞的，可以引入线程池实现异步重试，提升性能。
熔断机制：如果服务端持续不可用，可以结合熔断器避免无意义的重试。
动态配置：支持从外部配置文件或注册中心加载 RetryConfig。

总结

在面试中，我通过这套设计思路向面试官展示了我在代码架构上的思考：从需求出发，选择合适的设计模式，逐步构建一个优雅的解决方案。面试官对我的回答表示认可，并进一步讨论了异步重试的实现细节，这也让我意识到持续优化和学习的重要性。

希望这篇文章能给大家带来一些启发。如果你也有类似的项目经验，欢迎留言交流！