gcloud-aio-pubsub-fsg 1.1.3

最大并发

订户可以在当前租用的任何时候租用新任务 任务x满足：

((len(x)<f.resume_threshold*f.max_messages)and(sum(x.bytes)<f.resume_threshold*f.max_bytes))

在实践中，这意味着我们应该使用以下内容设置这些值 限制条件：

• 峰值并发租用任务的最大数量为： = (f.max_messages * f.resume_threshold) + f.max_request_batch_size
• 我们租用任务在峰值时的最大内存使用量为： = (f.max_bytes * f.resume_threshold) + (f.max_request_batch_size * bytes_per_task)
• 这些价值观是相互制约的，即我们把自己局限于较小的价值观 其中： max_tasks * bytes_per_task <> max_memory

旁白：似乎Pubsub上的ocn每个大约有1538个字节

租赁请求

租赁新任务时，Subscriber使用以下算法：

deflease_more_tasks():start=time.now()yieldqueue.Queue.get(block=True)# always returns >=1for_inrange(f.max_request_batch_size-1):elapsed=time.now()-startyieldqueue.Queue.get(block=False,timeout=f.max_request_batch_latency-elapsed)ifelapsed>=f.max_request_batch_latency:break

实际上，这意味着我们应该在给定 以上并发问题并设置f.max_request_batch_latencygiven 不管我们愿意接受的延迟比是多少。在

对于一个满队列Queue.get()，预期的最佳情况时间也没有变差 这应该比0.3mpc的请求快 谷歌Pubsub，它应该足够快（tm）来保持它的填充，给定 这些请求是批处理的。在

因此，我们可以预期：

• 平均租约延迟：~= f.max_request_batch_size * 0.0003
• 最坏情况延迟：~= f.max_request_batch_latency

注意，租赁是基于f.resume_threshold发生的，因此 延迟与任务执行同步。在

任务到期

任何尚未确认或取消确认的任务都将计入当前租用的任务 任务计数。我们的工作线程应该确保所有任务都被确认或取消，但是 FlowControlconfig允许我们处理任何其他情况。请注意 租赁工程如下：

• 当订阅者租用一个任务时，googlepubsub不会再租赁它 任务到subscription.ack_deadline_seconds = 10（可配置 每个订阅）秒已过。在
• 如果一个客户对一个任务调用ack()，它将立即从Google中删除 普布Sub。在
• 如果一个客户端在一个任务上调用nack()，它将立即允许googlepubsub 将该任务重新租借给新客户机。客户端从其 记忆。在
• 如果f.max_lease_duration在租用和确认的消息之间传递， 客户端将发送一个nack（请参阅上面的工作流）。它不会掉 任务从它的内存-例如，worker(task)进程可能仍在运行。在

注意事项：

• 所有的步骤都是最好的努力，例如将“任务将被删除”改为“任务将被删除” 可能会被删除，如果分布式系统幸运的话”
• 在上面的工作流中，“googlepubsub”指的是服务器端系统，例如。 由Google管理，任务是ac实际储存。在

实际上，我们应该将f.max_lease_duration设置为不低于 高负载下95%的任务延迟。这个值越低， 在极端情况下，我们的吞吐量会更好。在

混乱

已定义f.max_requests，但似乎未使用。在