当仅有一个订阅者连接到具有多个分区的 pub/sub lite 主题时，该订阅者会自动从所有分区拉取消息，不会导致消息堆积；分区负载由客户端库自动均衡处理。
当仅有一个订阅者连接到具有多个分区的 pub/sub lite 主题时，该订阅者会自动从所有分区拉取消息，不会导致消息堆积；分区负载由客户端库自动均衡处理。
在 Google Pub/Sub Lite 中，分区（partition）是并行处理和扩展性的核心抽象，但其消费行为与传统消息队列（如 Kafka 的 consumer group 语义）有重要区别：分区不是按“订阅者实例”静态绑定的，而是由客户端库在运行时动态、透明地管理连接与轮询逻辑。
具体而言，即使主题配置了 2 个（或更多）分区，只要仅启动一个 SubscriberClient 实例，该客户端会自动建立与所有关联分区的连接，并并发地从每个分区拉取消息。这意味着：
- ✅ 消息不会在未被消费的分区中堆积；
- ✅ 单个订阅者即可实现跨分区的吞吐叠加（例如：2 分区 × 10 MiB/s = 理论峰值 20 MiB/s）；
- ✅ 客户端内部通过异步 I/O 和线程/协程池调度，隐藏了多分区细节，开发者无需手动管理分区分配。
以下是一个使用 Java 客户端的简化示例，展示单订阅者消费多分区主题的行为：
SubscriberSettings settings = SubscriberSettings.newBuilder()
.setSubscriptionName(SubscriptionName.of("project-id", "subscription-id"))
.build();
try (SubscriberClient subscriber = SubscriberClient.create(settings)) {
subscriber.subscribe(
(message, ackReply) -> {
System.out.printf("Received: %s%n", message.getData().toStringUtf8());
ackReply.ack();
}
);
// 阻塞等待（实际应用中应配合 shutdown 机制）
subscriber.awaitTermination(5, TimeUnit.MINUTES);
}
? 关键点：SubscriberClient.create(...) 创建的实例会自动发现并连接该订阅所绑定主题的所有分区——无论分区数是 1、2 还是 20。
⚠️ 注意事项：
- 分区数量决定了水平扩展上限：最多支持 N 个并发订阅者（每个独占一个分区），但少于 N 个订阅者时，每个都会分摊多个分区的负载；
- 单订阅者虽能消费全部分区，但实际吞吐仍受限于该实例的网络带宽、CPU 和客户端配置（如 maxOutstandingMessages、flowControlSettings）；
- 若需严格顺序（如 per-key 有序），需结合分区键（partitionKey）与自定义路由逻辑，因为跨分区不保证全局顺序。
总结来说，Pub/Sub Lite 的设计目标是“让扩展性对用户透明”：你只需关注业务逻辑，分区的发现、连接、负载均衡和故障恢复均由官方客户端库自动完成。单订阅者 ≠ 单分区消费——这是其区别于原始 Kafka 消费模型的关键优势之一。
