Golang Bigtable Admin客户端调用DropRowRange报“已在进行中”

前置场景说明 #

业务侧触发目标资源删除流程时，需要遍历Bigtable中关联的多段行范围执行清理，目前已配置3次及以上admin.DropRowRange(ctx, table, rowKeyPrefix)调用，部分调用指向同一张数据表，每次调用对应不同的行范围。这套逻辑此前在多数场景下运行正常，近期触发报错 DropRowRange operation is already ongoing，目前未检索到该报错的官方公开文档说明，也未查询到其他开发者的同类问题反馈，针对提出的四个技术问题解答如下：

技术问题逐一解答 #

• 关于DropRowRange的调用频率约束
  该操作存在明确的隐式调用约束：它不属于轻量的行级写入操作，而是触发表级分片批量删除的管理面作业，单次操作会占用对应表的管理面运维配额，实际单表维度允许的并行操作数远低于普通数据面API；它的约束不会影响普通行写入类API的频率配额，但短时间内对同一张表发起多次该类调用，会直接触发状态冲突或限流。
• 关于约束的作用范围
  约束粒度为单表级：同一张Bigtable表的管理面通道，同一时间只允许有一个处于进行中的DropRowRange批量删除作业。即使每次调用传入的是完全不重叠的行范围、不同的rowKeyPrefix，只要是对同一张表发起的调用，都会纳入同一状态机校验，不会针对行范围做独立的并行校验。跨表发起的DropRowRange调用不会互相阻塞，不受该约束影响。
• 推荐的问题规避方案
  • 对同一张表的多个DropRowRange调用做串行化处理，不要并发提交，等上一次操作完全返回成功或失败结果后，再发起下一次调用
  • 为DropRowRange调用匹配专用的重试退避逻辑，不要复用面向普通数据面API的毫秒级快速重试策略
  • 如果单次删除涉及的行范围较多，可采用批量行删除的MutateRows接口替代连续多次的DropRowRange调用，绕开单表单操作并行的限制
  • 对同一次业务触发的删除流程增加操作态校验，避免上游重复触发资源删除逻辑导致重复提交操作
• 关于报错的触发原因判定
  该报错大概率是两类场景叠加触发：
  • 直接触发原因是同表并行调用的状态冲突：因为约束是单表级粒度，哪怕传入完全不重叠的行范围，只要同一张表已经有一个DropRowRange作业在运行，新提交的调用就会直接抛出该报错，和行范围是否重叠没有关联
  • 关于幂等性的说明：DropRowRange的操作最终效果是幂等的——重复对无数据的行范围发起删除，不会产生多余的副作用，但操作状态本身不支持无感知重试：如果上一次发起的操作因为网络超时没有收到后端响应，实际上后端仍在运行该作业，此时前端直接重试提交，就会因为后端已存在进行中的同表作业触发报错，并非因为操作结果不幂等导致的问题。

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