从https://cloud.google.com/pubsub/architecture#basic_architecture的文档中,我们了解了pubsub如何在发布者转发器和订阅者转发器之间中继消息,以及https://cloud.google.com/pubsub/images/wp_msg_lifecycle.svg所在位置的图像如何可视化这些信息。
从所提供的所有信息中,我可以理解,在任何给定的时间点,多个发布消息源中的未确认消息可以由订阅服务器转发器使用,发布消息源的总数取决于发布转发程序。
在数据应该被实时消耗的场景中,pubsub如何扩展转发器以实现无积压。因为,每个发布者转发器在任何给定的时间点上都可以连接到单个订户转发器,并且由于发行者转发器和订户转发器的扩展是独立/解耦的,这可能会增加系统中的积压,因为订户转发器应该向订户中继多条消息。
发布于 2020-03-10 17:31:05
发布服务器转发器只能连接到单个订阅服务器转发器,这是没有限制的,即使这是图表中的示例。Cloud /Sub中端到端延迟的限制因素很少是服务本身;它是订阅者客户端的行为。特别重要的是:
throughput.
https://stackoverflow.com/questions/60622675
复制相似问题