拉取模型由消费者主动发起请求获取数据，推送模型由生产者在事件发生时主动发送数据；前者控制权在下游、实时性低但容错简单，后者控制权在上游、实时性强但需复杂可靠性机制。
识别流的“拉取模型”与“推送模型”，关键不在表面通信协议，而在数据流动的发起方、控制权归属和系统行为逻辑。两者内核差异体现在三个不可绕开的层面：谁触发传输、谁决定节奏、谁承担失败后果。
谁发起数据传输？——触发主体决定模型本质
拉取模型中，消费者（Client/Subscriber）主动向生产者（Server/Publisher）发起请求，比如 Prometheus 定时向目标端点发 HTTP GET 请求抓指标；Kafka 消费者循环调用 poll() 方法获取消息。推送模型中，生产者在事件发生时立即构造并发送数据，例如 WebSocket 服务端在用户下单后主动向客户端广播订单状态，或 RocketMQ Broker 收到消息后直接推送给在线消费者（若启用 Push 模式）。
- Pull：请求由下游发起，上游无感知，不响应则无数据
- Push：事件驱动，上游感知状态变化，即使下游未准备就绪也尝试发出
谁控制节奏与频率？——权责分离体现架构哲学
拉取模型天然将节奏控制权交给消费者。它可以按需调整拉取间隔（如从 15s 改为 60s）、批量大小（max.poll.records）、甚至暂停拉取。这种弹性以延迟为代价：两次拉取之间的数据变更无法实时触达。推送模型把节奏锚定在生产者侧，通常依赖事件源本身的活跃度（如日志生成速率、传感器采样频率），消费者只能选择接收、缓冲或丢弃，无法反向调节上游发送频率。
- Pull：消费者可限流、错峰、降级，适合处理能力不均的下游
- Push：生产者需适配下游吞吐，否则易造成积压或连接中断
谁对失败负责？——容错机制设计逻辑不同
拉取模型中，一次请求失败不影响后续动作，消费者可在下次拉取时重试，天然具备幂等性和恢复能力。推送模型则必须额外引入确认（ACK）、重传、死信队列等机制：若消费者宕机未回 ACK，生产者需判断是否重推、推几次、推给谁。Kafka 的 Pull 设计正是为了规避复杂的消息送达保证逻辑；而 MQTT 的 QoS 1/2 级别，则是 Push 场景下对“至少一次”“恰好一次”的工程补救。
- Pull：失败成本低，重试由消费者自主完成
- Push：必须设计端到端可靠性链路，否则消息易丢失
不复杂但容易忽略：看一眼数据流向图上的箭头起点，再问一句“这个请求/连接是谁先建的、谁先发的第一字节”，答案就出来了。
