请从生产端和消费端两个维度，说明 Kafka 实现批量消息发送与批量拉取消费的具体机制，并讨论哪些参数或配置会影响批量操作的吞吐量与实时性？

回答思路

1. 【回答框架 1】生产端默认采用异步批量发送：生产者将消息写入内存缓冲区，由发送线程按 batch.size 和 linger.ms 决定是否立即发出。batch.size 控制单批次最大字节数，linger.ms 控制等待时长，两者共同决定攒批的粒度，调大可提升吞吐但会增加延迟。
2. 【回答框架 2】消费端通过 poll 一次拉取多条消息实现批量消费，max.poll.records 限制单次拉取最大条数，fetch.min.bytes 和 fetch.max.wait.ms 控制拉取的数据量和等待时间，可调整以提升拉取效率或降低延迟。
3. 【回答框架 3】性能优化建议：生产端可适当调大 batch.size 和 linger.ms（如 16KB、5-10ms），并开启 compression.type（如 lz4、zstd）减少网络和磁盘开销；消费端可调大 max.poll.records 增加单次处理量，但需注意 session.timeout.ms 与 max.poll.interval.ms，避免处理超时触发 rebalance。
4. 【回答框架 4】在实际系统中，吞吐量受网络带宽、磁盘 IO、分区数影响，需要结合压测结果调整参数，并监控 producer 的 buffer 使用率、压缩率、消费 lag 等指标，找到吞吐与延迟的最优平衡点。
5. 【关键点 1】生产端批量发送依赖 batch.size 和 linger.ms，两者共同决定批次形成和发送时机。
6. 【关键点 2】消费端批量消费通过 poll 拉取，max.poll.records 控制单次拉取条数，fetch 参数影响拉取大小。
7. 【关键点 3】压缩（compression.type）能显著降低网络和磁盘开销，但会增加少量 CPU 消耗。
8. 【关键点 4】吞吐量提升会带来延迟上升，需要根据业务要求做权衡。
9. 【易错点 1】批量参数过大会导致内存压力和延迟显著增加，并非越大越好。
10. 【易错点 2】消费端 max.poll.records 过大可能超过 max.poll.interval.ms 处理时限，引发不必要的 rebalance。
11. 【易错点 3】压缩虽节省带宽，但对 CPU 敏感的场景可能带来性能下降，需权衡。