4、生产者写入策略：同步发送、异步发送、批量发送、事务消息在读写分离中的应用

在消息队列读写分离架构中，生产者（Producer）的写入策略直接决定了数据从业务系统进入 Broker 主节点的可靠性、吞吐量与一致性。不同的写入策略在故障场景下的表现差异巨大，选型时需结合业务对延迟、吞吐、数据不丢失的容忍度进行权衡。本章深入剖析四种核心写入策略的原理、参数配置及在读写分离架构中的最佳实践。

4.1 同步发送（Sync Send）

同步发送是最基础的写入模式。生产者发送消息后，必须等待 Broker 主节点返回写入确认（ACK），才会继续发送下一条消息。在读写分离架构中，同步发送通常要求消息写入主节点并完成至少一次持久化（如刷盘或写入 PageCache），主节点再向生产者返回成功响应。

4.1.1 同步发送流程

1. 生产者构建消息并序列化。
2. 通过路由算法选择目标主节点（Leader）。
3. 发送请求至主节点，主节点写入本地存储。
4. 主节点根据配置等待从节点同步（可选，取决于 acks 参数）。
5. 主节点返回 ACK 给生产者。
6. 生产者收到 ACK，继续下一条消息。

4.1.2 关键参数配置

4.2 异步发送（Async Send）

异步发送允许生产者将消息提交给内部缓冲区后立即返回，不等待 Broker 确认。实际发送由后台 I/O 线程批量处理。在读写分离架构中，异步发送能显著提升吞吐，但需要业务方自行处理发送失败的回调逻辑。

4.2.1 异步发送回调机制

// Kafka Producer 异步发送示例
producer.send(new ProducerRecord<>("topic-test", key, value),
    (metadata, exception) -> {
        if (exception != null) {
            // 写入失败处理：记录日志、落盘、或重试
            log.error("Send failed: {}", exception.getMessage());
            // 可写入本地失败队列，由补偿任务重新发送
        } else {
            // 写入成功，metadata 包含分区和偏移量
            log.info("Sent to partition {} offset {}", metadata.partition(), metadata.offset());
        }
    });

4.2.2 缓冲区参数调优

4.3 批量发送（Batch Send）

批量发送是异步发送的进阶形态，生产者将多条消息聚合成一个批次（Batch）后一次性发送到 Broker。在读写分离架构中，批量发送能大幅减少网络往返次数（RTT），降低主节点写入压力，是提升吞吐的核心手段。

4.3.1 批量发送与读写分离的协同

• 主节点写入优化：批量写入可合并磁盘 I/O，减少随机写次数，提升主节点写入吞吐。
• 从节点同步优化：批量消息在从节点拉取时同样以批次为单位，减少网络小包，提升同步效率。
• 内存占用控制：批次过大会导致生产者内存飙升，需结合 max.request.size 和 buffer.memory 限制。

4.3.2 批量发送参数矩阵

4.4 事务消息（Transactional Message）

事务消息用于保证生产者本地事务与消息发送的原子性——要么都成功，要么都回滚。在读写分离架构中，事务消息通常依赖 Broker 主节点维护事务状态，从节点不参与事务协调，仅同步已提交的消息。

4.4.1 事务消息生命周期

1. 开启事务：生产者向事务协调器（Transaction Coordinator）申请事务 ID。
2. 发送半消息：消息写入主节点，标记为“未提交”，对消费者不可见。
3. 执行本地事务：业务方执行数据库操作等本地逻辑。
4. 提交/回滚：根据本地事务结果，向协调器发送提交或回滚请求。
5. 消息可见：提交后，消息对消费者可见；回滚则消息被丢弃。

4.4.2 事务消息在读写分离中的约束

4.5 四种策略对比与选型

4.6 生产者写入策略在读写分离中的架构图

下图展示了四种写入策略在读写分离架构中的完整数据流：生产者根据业务需求选择策略，消息写入主节点后，由主节点异步同步至从节点，消费者从从节点读取数据。

4.7 故障场景下的写入策略行为

4.8 最佳实践建议