如何让Spring Boot忽略Cassandra的NoHostAvailableException并正常启动？

当然可以！这种依赖服务暂时不可用导致应用启动失败的场景在集成环境里太常见了，我们可以通过几个配置和代码调整的方案来让Spring Boot忽略Cassandra的连接异常，顺利完成启动。下面是几种实用的解决方案：

方案1：禁用启动时的强制连接校验 #

Spring Data Cassandra提供了一个配置项，可以控制是否在应用初始化阶段就建立Cassandra连接。默认情况下这个属性是开启的，我们只需要把它关掉，应用就不会在启动时强制连接Cassandra，而是等到第一次执行Cassandra操作时才尝试建立连接。

在application.yml中添加配置：

spring:
  data:
    cassandra:
      connect-on-init: false
      # 保留你的其他Cassandra配置，比如contact-points、keyspace-name等
      contact-points: cassandra-server
      keyspace-name: your_keyspace

如果用application.properties的话：

spring.data.cassandra.connect-on-init=false
spring.data.cassandra.contact-points=cassandra-server
spring.data.cassandra.keyspace-name=your_keyspace

这个方案的优势是简单粗暴，不需要写额外代码。但要注意，后续第一次执行Cassandra操作时如果还是无法连接，依然会抛出异常，所以建议配合重试机制（比如Spring Retry）来处理后续的连接重试。

方案2：自定义Cassandra配置，捕获连接异常 #

如果需要更精细的控制，可以自定义Cassandra的配置类，在创建SessionFactory的时候主动捕获NoHostAvailableException，让应用继续启动。

import com.datastax.oss.driver.api.core.NoHostAvailableException;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.data.cassandra.config.AbstractCassandraConfiguration;
import org.springframework.data.cassandra.core.CassandraTemplate;
import org.springframework.data.cassandra.core.session.DefaultSessionFactory;
import org.springframework.data.cassandra.core.session.SessionFactory;

@Configuration
public class CustomCassandraConfig extends AbstractCassandraConfiguration {

    @Override
    protected String getKeyspaceName() {
        return "your_keyspace";
    }

    @Override
    protected String getContactPoints() {
        return "cassandra-server";
    }

    @Bean
    @Override
    public SessionFactory sessionFactory() {
        try {
            // 尝试创建Session
            return new DefaultSessionFactory(session());
        } catch (NoHostAvailableException e) {
            // 捕获连接异常，这里可以根据需求做降级处理
            // 比如返回一个空的SessionFactory，或者自定义的Mock实现
            System.err.println("Cassandra连接失败，应用将继续启动：" + e.getMessage());
            return new DefaultSessionFactory(null);
        }
    }

    @Bean
    public CassandraTemplate cassandraTemplate() {
        return new CassandraTemplate(sessionFactory());
    }
}

这种方式可以在连接失败时做自定义的降级逻辑，比如打印告警日志、返回Mock的SessionFactory等。但后续执行Cassandra操作时会报错，所以需要在业务代码中添加异常处理或者重试逻辑。

方案3：环境化配置，按需加载Cassandra组件 #

如果你的QA环境有时候不需要Cassandra功能，可以通过配置开关来控制Cassandra相关Bean的加载，从根源上避免连接异常。

首先在配置类上添加条件注解：

@Configuration
@ConditionalOnProperty(name = "cassandra.enabled", havingValue = "true", matchIfMissing = true)
public class CassandraConfig extends AbstractCassandraConfiguration {
    // 你的Cassandra配置内容
}

然后在QA环境的application-qa.yml中添加：

cassandra.enabled: false

这样QA环境启动时就不会加载Cassandra的配置，自然不会出现连接问题。这个方案适合不需要Cassandra功能的场景，如果还是需要后续使用，建议优先选方案1或2。

额外建议：配合重试与降级机制 #

不管用哪种方案，都建议添加重试机制来处理后续的连接恢复。比如使用Spring Retry封装Cassandra操作：

import org.springframework.retry.annotation.Backoff;
import org.springframework.retry.annotation.Retryable;
import org.springframework.stereotype.Service;

@Service
public class CassandraLogService {

    @Retryable(value = NoHostAvailableException.class, maxAttempts = 5, backoff = @Backoff(delay = 2000))
    public void writeLogToCassandra(String logContent) {
        // 你的Cassandra写入逻辑
    }
}

这样当Cassandra恢复后，重试机制会自动尝试重新连接并执行操作。另外，也可以考虑在Cassandra不可用时，将日志临时写入本地文件或者其他消息队列，等服务恢复后再同步。

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