GCP Pub/Sub拉取订阅结合JPA仓库引发数据库连接问题排查

一、JDBC连接不稳定问题排查与修复 #

核心原因 #

Pub/Sub自定义订阅工具类的拉取线程默认是非Spring管理线程，直接注入HelloService这类Spring Bean时，线程无法获取Spring的事务上下文与连接池绑定的上下文，加上Cloud Run的无状态特性，会触发连接池泄漏、证书刷新异常、连接中断等问题。

具体修复方案 #

1. 将订阅线程纳入Spring上下文管理
   放弃自定义订阅工具类，改用Spring Cloud GCP Pub/Sub Starter，它会自动将订阅拉取线程注册到Spring线程池，注入的HelloService能正常获取事务与JDBC连接。示例代码：

   @Service
   public class HelloTopicSubscriber {
       private final HelloService helloService;
   
       public HelloTopicSubscriber(HelloService helloService) {
           this.helloService = helloService;
       }
   
       @PubSubListener(subscription = "your-subscription-name")
       public void handleMessage(String message) {
           // 直接调用helloService操作数据库，无上下文问题
           helloService.fetchHelloData();
       }
   }
   

2. 自定义订阅工具类的线程适配
   如果必须保留自定义工具类，用Spring提供的TaskExecutor执行拉取逻辑，确保线程能访问Spring上下文：

   @Service
   public class HelloTopicSubscriber {
       private final HelloService helloService;
       private final TaskExecutor taskExecutor;
   
       public HelloTopicSubscriber(HelloService helloService, TaskExecutor taskExecutor) {
           this.helloService = helloService;
           this.taskExecutor = taskExecutor;
       }
   
       public void startPulling() {
           taskExecutor.execute(() -> {
               // 这里执行自定义的Pub/Sub拉取逻辑，调用helloService不会有上下文问题
           });
       }
   }
   

3. 调整Cloud SQL JDBC连接池配置
   针对Cloud Run的资源限制，修改application.properties中的HikariCP配置：

   spring.datasource.hikari.maximum-pool-size=8
   spring.datasource.hikari.connection-timeout=3000
   spring.datasource.hikari.idle-timeout=600000
   spring.datasource.hikari.max-lifetime=1800000
   spring.datasource.url=jdbc:postgresql://google/<db-name>?cloudSqlInstance=<project-id>:<region>:<instance-name>&socketFactory=com.google.cloud.sql.postgres.SocketFactory&user=<db-user>&password=<db-pass>
   

   关键：使用Cloud SQL官方SocketFactory，让它自动管理证书刷新，避免手动证书导致的错误。

4. 排查连接泄漏
   开启HikariCP的泄漏检测，定位是否有未关闭的连接：

   spring.datasource.hikari.leak-detection-threshold=2000
   

二、多订阅@Scope方案的可行性与注意事项 #

使用@Scope创建多订阅是可行的，但存在以下注意点：

• 原型Scope（@Scope("prototype")）：每次获取Bean都会新建一个订阅实例，需确保每个实例的Topic/订阅名称配置唯一，且必须手动管理订阅的启动/关闭逻辑，否则会出现重复订阅、内存泄漏问题。
• 更优替代方案：直接用Spring Cloud GCP @PubSubListener注解，在不同方法上指定不同的订阅名称，Spring会自动为每个订阅创建独立的消费者线程池，无需手动管理Scope：

  @Service
   public class MultiTopicSubscriber {
       private final HelloService helloService;
  
       public MultiTopicSubscriber(HelloService helloService) {
           this.helloService = helloService;
       }
  
       @PubSubListener(subscription = "topic-a-sub")
       public void handleTopicA(String message) {
           helloService.processTopicAData(message);
       }
  
       @PubSubListener(subscription = "topic-b-sub")
       public void handleTopicB(String message) {
           helloService.processTopicBData(message);
       }
   }
  

• 自定义订阅类的批量创建：如果必须用自定义订阅类，建议在@Configuration类中批量创建不同的订阅Bean，用@Qualifier区分，比Scope更清晰：

  @Configuration
   public class PubSubConfig {
       @Bean("topicASubscriber")
       public HelloTopicSubscriber topicASubscriber(HelloService helloService) {
           return new HelloTopicSubscriber(helloService, "topic-a-sub");
       }
  
       @Bean("topicBSubscriber")
       public HelloTopicSubscriber topicBSubscriber(HelloService helloService) {
           return new HelloTopicSubscriber(helloService, "topic-b-sub");
       }
   }
  

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