请问Google Cloud Pub/Sub中best-effort delivery与at least once delivery有何差异？

1. 核心投递保障差异 #

• At-Least-Once 投递：这是Pub/Sub的默认模式，核心承诺是每条消息至少会被投递到订阅者一次。如果订阅者未发送确认（ACK）——比如处理过程崩溃、网络中断导致ACK丢失——Pub/Sub会自动重试投递，直到收到ACK为止。
• Best-Effort 投递：无严格投递保障，消息可能被投递0次、1次或多次，但绝大多数情况下只会投递一次。如果投递过程中出现异常（比如订阅者暂时不可达），Pub/Sub不会重试，消息直接丢失。

2. 重复消息概率 #

• At-Least-Once：重复投递是必然会遇到的场景。举个例子：订阅者处理完消息，但ACK请求在传输中丢失，Pub/Sub会认为消息未被处理，再次投递。因此订阅者必须实现幂等性逻辑（比如通过消息ID去重）来避免重复处理带来的业务问题。
• Best-Effort：重复概率极低，但并非完全不存在。只有在极端的网络抖动场景下，才可能出现服务误判投递失败而触发额外投递的情况，远少于At-Least-Once模式。

3. 性能与延迟表现 #

• At-Least-Once：由于需要跟踪每条消息的投递状态、处理重试队列，会产生额外的服务开销，延迟相对略高，吞吐量也会受到重试机制的限制（尤其是订阅者ACK响应慢的时候）。
• Best-Effort：没有状态跟踪和重试逻辑，投递流程更轻量化，延迟更低，吞吐量更高，是Pub/Sub里性能最优的投递模式。

4. 适用业务场景 #

• At-Least-Once：适合无法容忍消息丢失的核心业务，比如金融交易记录、订单创建流程、关键系统日志采集。只要订阅者做好幂等处理，就能兼顾可靠性和业务需求。
• Best-Effort：适合对消息丢失容忍度高，但对延迟、吞吐量要求极高的场景，比如实时流数据的初步清洗、非核心监控告警（少量丢失不影响整体监控效果）、高并发的用户行为上报。

5. 配置与附加功能限制 #

• At-Least-Once：默认启用，无需额外配置。支持配合重试策略（自定义重试间隔）、死信队列（转发无法处理的消息）等附加功能使用。
• Best-Effort：需要显式配置，比如使用gcloud命令：

  gcloud pubsub subscriptions create my-best-effort-sub --topic my-topic --delivery-type=best-effort
  

  不支持重试策略和死信队列，因为本身不提供重试机制。

内容的提问来源于stack exchange，提问作者tru