K8s 滚动发布时 HikariCP close() 对 in-flight 慢 SQL 是「中断」还是「死等」？graceful shutdown 到底该给慢查询留多长 drain 预算？

【背景】

在 Kubernetes 环境中进行滚动发布时，我们常常需要优雅地关闭正在运行的 Pod，以确保服务的平稳过渡。HikariCP 是一个常用的连接池实现，它在关闭时会尝试关闭所有未完成的 SQL 查询。然而，对于那些执行时间较长的「in-flight」慢 SQL，HikariCP 的 close() 方法行为可能会引发一些争议。

【常见分歧】

• 中断模式：HikariCP 的 close() 方法会立即中断正在执行的 SQL 查询，这样可以快速释放资源，但可能会导致数据不一致或业务中断。
• 死等模式：HikariCP 会等待所有未完成的 SQL 查询完成，这样可以保证数据的一致性，但可能会导致关闭过程变慢，影响服务的可用性。

【我的倾向与理由】

我的倾向是采用 中断模式，因为这可以快速释放资源，避免长时间的阻塞。然而，这需要在关闭前设置一个合理的 drainTimeout，以确保有足够的时间处理正在执行的 SQL 查询。通常，drainTimeout 设置为 5 秒左右，这样可以在保证资源释放的同时，避免影响服务的可用性。

【想听大家在什么场景下怎么选】

• 你们在实际工作中是如何处理 HikariCP 的 close() 方法行为的？
• 在哪些场景下会选择中断模式，哪些场景下会选择死等模式？
• 你们是如何设置 drainTimeout 的，有什么经验分享？

【标签】 Kubernetes, HikariCP, graceful shutdown, drainTimeout, 滚动发布, 优雅关闭