根据 stackdriver 图表，我们开始注意到某个主题/订阅的“未确认消息”数量不时增加。

症状

我不知道我们对 stackdriver 图表的信任程度如何，但我已经检查过了：

• 拉取操作数与发布操作数一样多
• 问题发生时ack操作计数低于pull操作计数

另外，根据我们的日志，我可以看到 pubsub 实际上多次发送相同的消息，这也证实了“pull”成功，但“ack”可能不成功。

因此，我认为我们可以假设我们的系统会及时拉取，但从 GCP 的角度来看，ACK 效果不佳。

我检查了不按时发送 ACK 的可能性，但我认为情况并非如此，如下所示。

在有问题的订阅中，消息会累积几个小时。对于我们来说，这是一个严重的问题。

实施细节

我们出于某种原因使用拉式方法，并且不愿意切换到推式方法，除非有充分的理由。对于每个订阅，我们都有一个消息泵送 Goroutine，并且该 Goroutine 会为每条拉取的消息生成一个工作线程。更具体，

// in a dedicated message-pumping goroutine
sub, _ := CreateSubscription(..., 0 /* ack-deadline */, )
iter, _ := sub.Pull(...)
for {
   // omitted: wait if we have too many workers
   msg, _ := iter.Next()
   go func(msg Message) {
     // omitted: handle the message and measure the latency; it turned out the latency is almost within …

假设有一行包含一个列族和一列。该列族有一个 gc 策略，并且该列中的所有值都刚刚过期。

那么，该行会发生什么呢？该行会被垃圾收集器删除吗？或者，它仍然存在并且可以访问吗？

我检查了文档，但只发现了一些模糊的评论，来自https://cloud.google.com/bigtable/docs/overview#empty-cells

Cloud Bigtable 表中的空单元格不占用任何空间。每行本质上是键/值条目的集合，其中键是列族、列限定符和时间戳的组合。如果某行不包含特定键的值，则该键/值条目根本不存在。

就我而言，根据上述文本，该集合将为空。然后，我的问题是空集合是否仍然存在。

理想情况下，我希望自动删除空行，以防止表中有太多空行。如果空行没有自动删除，除了编写一个程序来扫描和删除这些行之外，是否有任何方法可以自动删除空行？