PostgreSQL - 连接数配置：max_connections 优化与连接池

Ne0inhk

— 19 min read
PostgreSQL - 连接数配置：max_connections 优化与连接池
在这里插入图片描述
👋 大家好，欢迎来到我的技术博客！
📚 在这里，我会分享学习笔记、实战经验与技术思考，力求用简单的方式讲清楚复杂的问题。
🎯 本文将围绕PostgreSQL这个话题展开，希望能为你带来一些启发或实用的参考。
🌱 无论你是刚入门的新手，还是正在进阶的开发者，希望你都能有所收获！

文章目录

PostgreSQL - 连接数配置：max_connections 优化与连接池

在现代应用程序架构中，数据库连接管理是一个至关重要但又常常被忽视的环节。PostgreSQL 作为世界上最先进的开源关系型数据库之一，其连接机制直接影响着应用的性能、稳定性和可扩展性。本文将深入探讨 PostgreSQL 的 max_connections 参数配置、连接池的最佳实践，以及如何在 Java 应用中实现高效的数据库连接管理。

理解 PostgreSQL 连接机制 💡

PostgreSQL 使用进程模型来处理客户端连接，这意味着每个客户端连接都会对应一个独立的后端进程。这种设计带来了良好的隔离性和稳定性，但也意味着连接是有开销的。

当你执行以下命令连接到 PostgreSQL：

psql -h localhost -U myuser -d mydb

PostgreSQL 会在服务器端创建一个新的进程来处理这个连接。你可以通过以下 SQL 查看当前的连接情况：

SELECT pid, usename, application_name, client_addr, backend_start, state, query FROM pg_stat_activity WHERE pid <> pg_backend_pid();

连接的内存开销 📊

每个 PostgreSQL 连接都会消耗一定的内存资源，主要包括：

  • shared_buffers：共享缓冲区（所有连接共享）
  • work_mem：每个操作（如排序、哈希）的内存分配
  • maintenance_work_mem：维护操作的内存
  • 每个连接的私有内存：包括会话状态、临时数据结构等

根据 PostgreSQL 官方文档和实践经验，每个空闲连接大约消耗 5-10MB 的内存。这意味着如果你设置了 max_connections = 1000，即使这些连接都是空闲的，也可能消耗 5-10GB 的内存！

让我们用一个简单的计算来说明这个问题：

max_connections=200

每个连接平均内存: 8MB

总内存开销: 1.6GB

max_connections=1000

每个连接平均内存: 8MB

总内存开销: 8GB

适合中小型应用

需要大内存服务器

默认配置分析 🔍

PostgreSQL 的默认 max_connections 值通常是 100。这个值对于开发环境或小型应用来说是合适的，但对于生产环境中的高并发应用可能不够，而对于资源受限的环境又可能过多。

你可以通过以下命令查看当前的配置：

SHOW max_connections;SHOW shared_buffers;SHOW work_mem;

max_connections 参数详解 ⚙️

max_connections 是 PostgreSQL 中最重要的配置参数之一，它定义了数据库服务器允许的最大并发连接数（包括超级用户连接）。

参数位置和修改方式

max_connections 参数位于 PostgreSQL 的主配置文件 postgresql.conf 中：

# postgresql.conf max_connections = 100

重要提示：修改 max_connections 参数需要重启 PostgreSQL 服务才能生效！

相关依赖参数

max_connections 并不是孤立存在的，它与其他几个关键参数密切相关：

1. shared_buffers

shared_buffers 定义了 PostgreSQL 使用的共享内存缓冲区大小。通常建议设置为系统内存的 25%，但不超过 8GB。

2. max_locks_per_transaction

这个参数控制每个事务可以持有的最大锁数量。当 max_connections 增加时，可能需要相应调整此参数。

3. autovacuum_max_workers

自动清理工作进程的数量也会影响总的连接数计算。

计算合理的 max_connections 值 🧮

确定合适的 max_connections 值需要考虑多个因素：

  1. 应用的实际并发需求
  2. 服务器的可用内存
  3. 每个连接的平均内存消耗
  4. 预期的峰值负载

一个实用的计算公式：

max_connections = (可用内存 - 其他服务内存需求) / 每个连接平均内存消耗

例如，如果你有 16GB 内存的服务器，计划为 PostgreSQL 分配 12GB，其他服务需要 2GB，那么：

可用内存给PostgreSQL = 12GB - 2GB = 10GB = 10240MB 每个连接平均消耗 = 8MB max_connections = 10240 / 8 = 1280

但是！这只是一个理论值。实际上，你很少需要这么高的连接数。

95%5%实际应用中的连接使用情况活跃连接 (<5%)空闲连接 (>95%)

根据实际观察，大多数应用中 95% 以上的连接都是空闲的！这意味着我们可以通过连接池来大大减少实际需要的数据库连接数。

连接池的重要性 🏊‍♂️

连接池是解决 PostgreSQL 连接开销问题的关键技术。它通过复用数据库连接来减少连接创建和销毁的开销，同时控制并发连接数。

为什么需要连接池？

  1. 减少连接开销：创建和销毁数据库连接是昂贵的操作
  2. 控制资源使用：防止应用创建过多连接导致数据库崩溃
  3. 提高响应速度：复用现有连接比创建新连接快得多
  4. 更好的错误处理：连接池可以自动处理连接失效等问题

连接池的工作原理

PostgreSQLConnectionPoolApplicationPostgreSQLConnectionPoolApplicationalt[连接池中有可用连接-][连接池中无可用连接-且未达上限][连接池已达上限]请求数据库连接返回现有连接创建新连接返回新连接返回新连接等待或抛出异常执行SQL操作归还连接将连接标记为可用

连接池 vs 直接连接性能对比

假设一个 Web 应用每秒处理 100 个请求，每个请求需要执行一次数据库查询：

直接连接模式：

  • 每秒创建 100 个新连接
  • 每秒销毁 100 个连接
  • 数据库需要处理 100 个并发连接
  • 内存消耗：100 × 8MB = 800MB

连接池模式（池大小 = 20）：

  • 连接池初始化时创建 20 个连接
  • 所有请求复用这 20 个连接
  • 数据库只需要处理 20 个并发连接
  • 内存消耗：20 × 8MB = 160MB
  • 连接复用率：100/20 = 5 倍

Java 中的 PostgreSQL 连接池实现 💻

在 Java 生态系统中，有多种优秀的连接池实现。我们将重点介绍几种主流的选择，并提供完整的代码示例。

HikariCP - 高性能连接池 🚀

HikariCP 是目前 Java 生态中最受欢迎的高性能 JDBC 连接池，以其极快的速度和简洁的 API 著称。

Maven 依赖
<dependencies><dependency><groupId>com.zaxxer</groupId><artifactId>HikariCP</artifactId><version>5.0.1</version></dependency><dependency><groupId>org.postgresql</groupId><artifactId>postgresql</artifactId><version>42.6.0</version></dependency></dependencies>
基础配置示例
importcom.zaxxer.hikari.HikariConfig;importcom.zaxxer.hikari.HikariDataSource;importjava.sql.Connection;importjava.sql.PreparedStatement;importjava.sql.ResultSet;importjava.sql.SQLException;publicclassHikariCPExample{privatestaticHikariDataSource dataSource;static{HikariConfig config =newHikariConfig();// 数据库连接配置 config.setJdbcUrl("jdbc:postgresql://localhost:5432/mydb"); config.setUsername("myuser"); config.setPassword("mypass");// 连接池配置 config.setMaximumPoolSize(20);// 最大连接数 config.setMinimumIdle(5);// 最小空闲连接数 config.setConnectionTimeout(30000);// 连接超时时间(毫秒) config.setIdleTimeout(600000);// 空闲连接超时时间(毫秒) config.setMaxLifetime(1800000);// 连接最大生命周期(毫秒) config.setLeakDetectionThreshold(60000);// 连接泄漏检测阈值// PostgreSQL 特定优化 config.addDataSourceProperty("cachePrepStmts","true"); config.addDataSourceProperty("prepStmtCacheSize","250"); config.addDataSourceProperty("prepStmtCacheSqlLimit","2048"); config.addDataSourceProperty("useServerPrepStmts","true"); dataSource =newHikariDataSource(config);}publicstaticConnectiongetConnection()throwsSQLException{return dataSource.getConnection();}publicstaticvoidcloseDataSource(){if(dataSource !=null){ dataSource.close();}}// 使用示例publicstaticvoidmain(String[] args){try(Connection conn =getConnection();PreparedStatement stmt = conn.prepareStatement("SELECT * FROM users WHERE id = ?")){ stmt.setInt(1,123);try(ResultSet rs = stmt.executeQuery()){while(rs.next()){System.out.println("User: "+ rs.getString("name"));}}}catch(SQLException e){ e.printStackTrace();}finally{closeDataSource();}}}
高级配置最佳实践
publicclassHikariCPAdvancedConfig{publicstaticHikariDataSourcecreateOptimizedDataSource(){HikariConfig config =newHikariConfig();// 基础连接信息 config.setJdbcUrl("jdbc:postgresql://localhost:5432/mydb"); config.setUsername("myuser"); config.setPassword("mypass");// 性能调优参数 config.setMaximumPoolSize(calculateOptimalPoolSize());// 动态计算最优池大小 config.setMinimumIdle(config.getMaximumPoolSize()/2);// 超时设置 config.setConnectionTimeout(20_000);// 20秒连接超时 config.setIdleTimeout(300_000);// 5分钟空闲超时 config.setMaxLifetime(1_200_000);// 20分钟最大生命周期// 监控和调试 config.setRegisterMbeans(true);// 注册JMX MBeans用于监控 config.setMetricRegistry(metricRegistry);// 集成指标收集// PostgreSQL 特定优化Properties props =newProperties(); props.setProperty("ApplicationName","MyJavaApp");// 设置应用名称便于监控 props.setProperty("tcpKeepAlive","true");// 启用TCP Keep-Alive props.setProperty("loginTimeout","10");// 登录超时 config.setDataSourceProperties(props);returnnewHikariDataSource(config);}// 根据CPU核心数和数据库响应时间计算最优池大小privatestaticintcalculateOptimalPoolSize(){// Little's Law: PoolSize = TargetThroughput * AvgResponseTime// 简化版本：基于CPU核心数int cores =Runtime.getRuntime().availableProcessors();returnMath.max(4,Math.min(cores *2,20));// 最小4，最大20}}

Apache Commons DBCP2

虽然 HikariCP 是首选，但 Apache Commons DBCP2 也是一个成熟稳定的选项。

importorg.apache.commons.dbcp2.BasicDataSource;importjava.sql.Connection;importjava.sql.SQLException;publicclassDBCP2Example{privatestaticBasicDataSource dataSource;static{ dataSource =newBasicDataSource(); dataSource.setUrl("jdbc:postgresql://localhost:5432/mydb"); dataSource.setUsername("myuser"); dataSource.setPassword("mypass");// 连接池配置 dataSource.setInitialSize(5); dataSource.setMaxTotal(20); dataSource.setMaxIdle(10); dataSource.setMinIdle(5); dataSource.setMaxWaitMillis(30000);// 验证查询 dataSource.setValidationQuery("SELECT 1"); dataSource.setTestOnBorrow(true); dataSource.setTestWhileIdle(true); dataSource.setTimeBetweenEvictionRunsMillis(60000);}publicstaticConnectiongetConnection()throwsSQLException{return dataSource.getConnection();}}

Spring Boot 集成示例 🌱

在 Spring Boot 应用中，连接池配置更加简单：

application.yml 配置
spring:datasource:url: jdbc:postgresql://localhost:5432/mydb username: myuser password: mypass driver-class-name: org.postgresql.Driver hikari:maximum-pool-size:20minimum-idle:5connection-timeout:30000idle-timeout:600000max-lifetime:1800000leak-detection-threshold:60000data-source-properties:cachePrepStmts:trueprepStmtCacheSize:250prepStmtCacheSqlLimit:2048useServerPrepStmts:true
Repository 层代码
importorg.springframework.beans.factory.annotation.Autowired;importorg.springframework.jdbc.core.JdbcTemplate;importorg.springframework.stereotype.Repository;importjava.util.List;importjava.util.Map;@RepositorypublicclassUserRepository{@AutowiredprivateJdbcTemplate jdbcTemplate;publicList<Map<String,Object>>findAllUsers(){return jdbcTemplate.queryForList("SELECT * FROM users");}publicMap<String,Object>findUserById(Long id){return jdbcTemplate.queryForMap("SELECT * FROM users WHERE id = ?", id);}publicintcreateUser(String name,String email){return jdbcTemplate.update("INSERT INTO users (name, email) VALUES (?, ?)", name, email );}}

连接池配置最佳实践 🏆

正确的连接池配置对于应用性能至关重要。以下是一些经过验证的最佳实践：

1. 池大小配置策略

很多人认为连接池越大越好，这是一个常见的误区。实际上，过大的连接池会导致：

  • 数据库资源竞争加剧
  • 上下文切换开销增加
  • 内存消耗过大

推荐策略：

是

否

是

否

确定应用类型

Web应用?

池大小 = CPU核心数 * 2

批处理应用?

池大小 = CPU核心数

根据具体场景测试确定

最大不超过20-30

根据I/O密集程度调整

2. 超时参数设置

合理的超时设置可以防止连接泄漏和资源浪费：

  • connectionTimeout: 20-30秒（连接获取超时）
  • idleTimeout: 10分钟（空闲连接超时）
  • maxLifetime: 30分钟（连接最大生命周期）
  • leakDetectionThreshold: 1分钟（连接泄漏检测）

3. 监控和指标收集

连接池应该集成监控系统，收集以下关键指标：

  • 活跃连接数
  • 空闲连接数
  • 等待获取连接的线程数
  • 连接获取平均时间
  • 连接泄漏警告
// HikariCP 监控示例HikariConfig config =newHikariConfig(); config.setRegisterMbeans(true);// 或者使用 Dropwizard MetricsMetricRegistry metricRegistry =newMetricRegistry(); config.setMetricRegistry(metricRegistry);// 在应用中访问指标HikariDataSource ds =newHikariDataSource(config);HikariPoolMXBean poolBean = ds.getHikariPoolMXBean();System.out.println("Active connections: "+ poolBean.getActiveConnections());System.out.println("Idle connections: "+ poolBean.getIdleConnections());System.out.println("Total connections: "+ poolBean.getTotalConnections());

4. PostgreSQL 特定优化

针对 PostgreSQL 的 JDBC 连接，还有一些特定的优化参数：

# 启用预编译语句缓存 cachePrepStmts=true prepStmtCacheSize=250 prepStmtCacheSqlLimit=2048 useServerPrepStmts=true # 设置应用名称便于监控 ApplicationName=MyJavaApplication # 启用TCP Keep-Alive tcpKeepAlive=true # 设置网络超时 loginTimeout=10 socketTimeout=30

常见问题排查与解决方案 🛠️

在实际使用过程中，可能会遇到各种连接相关的问题。以下是常见问题及其解决方案：

1. “Too many connections” 错误

这是最常见的 PostgreSQL 连接错误，表示达到了 max_connections 限制。

诊断步骤：

-- 查看当前连接数SELECTcount(*)FROM pg_stat_activity;-- 查看连接详情SELECT usename, application_name, client_addr, state,count(*)FROM pg_stat_activity GROUPBY usename, application_name, client_addr, state ORDERBY count DESC;

解决方案：

  • 检查应用是否正确关闭连接（连接泄漏）
  • 调整连接池大小
  • 如果确实需要更多连接，考虑增加 max_connections
  • 使用 PgBouncer 进行连接池代理

2. 连接泄漏检测

连接泄漏是指应用获取了数据库连接但没有正确关闭，导致连接池耗尽。

HikariCP 连接泄漏检测配置：

HikariConfig config =newHikariConfig(); config.setLeakDetectionThreshold(60000);// 60秒后报告泄漏

当发生连接泄漏时，你会在日志中看到类似这样的警告：

WARNING: Connection leak detection triggered for connection ...

预防措施：

  • 始终使用 try-with-resources 语法
  • 在 finally 块中确保连接关闭
  • 定期进行代码审查
// 正确的做法 - 使用 try-with-resourcestry(Connection conn = dataSource.getConnection();PreparedStatement stmt = conn.prepareStatement(sql);ResultSet rs = stmt.executeQuery()){// 处理结果}catch(SQLException e){// 处理异常}// 错误的做法 - 可能导致连接泄漏Connection conn =null;try{ conn = dataSource.getConnection();// ... 执行操作}catch(SQLException e){// 处理异常}finally{if(conn !=null){try{ conn.close();// 如果这里抛出异常，连接可能不会被正确归还}catch(SQLException e){// 忽略关闭异常}}}

3. 连接池性能调优

如果发现数据库响应变慢，可能是连接池配置不当。

性能监控脚本：

publicclassConnectionPoolMonitor{privatefinalHikariDataSource dataSource;publicConnectionPoolMonitor(HikariDataSource dataSource){this.dataSource = dataSource;}publicvoidprintPoolStats(){HikariPoolMXBean poolBean = dataSource.getHikariPoolMXBean();System.out.printf("Pool Stats - Active: %d, Idle: %d, Total: %d, Pending: %d%n", poolBean.getActiveConnections(), poolBean.getIdleConnections(), poolBean.getTotalConnections(), poolBean.getThreadsAwaitingConnection());}// 定期打印统计信息publicvoidstartMonitoring(){ScheduledExecutorService scheduler =Executors.newScheduledThreadPool(1); scheduler.scheduleAtFixedRate(this::printPoolStats,0,30,TimeUnit.SECONDS);}}

PgBouncer - PostgreSQL 连接池代理 🦀

当单个应用的连接池无法满足需求时，或者需要为多个应用提供统一的连接池服务时，可以考虑使用 PgBouncer。

PgBouncer 是一个轻量级的 PostgreSQL 连接池代理，它运行在应用和数据库之间，提供连接池功能。

PgBouncer 架构

Application 1

PgBouncer

Application 2

Application N

PostgreSQL Server

主要优势

  1. 节省数据库连接：多个客户端连接可以复用少量的数据库连接
  2. 支持多种池模式：
    • session: 会话级别池（默认）
    • transaction: 事务级别池（最高效）
    • statement: 语句级别池（限制最多）
  3. 低内存开销：PgBouncer 本身内存占用很小
  4. 透明代理：对应用透明，只需修改连接地址

配置示例

PgBouncer 的主要配置文件是 pgbouncer.ini：

[databases] mydb = host=localhost port=5432 dbname=mydb [pgbouncer] pool_mode = transaction default_pool_size = 20 max_client_conn = 1000 listen_port = 6432 listen_addr = 127.0.0.1 auth_type = md5 auth_file = userlist.txt logfile = pgbouncer.log pidfile = pgbouncer.pid

应用连接字符串从：

jdbc:postgresql://localhost:5432/mydb

改为：

jdbc:postgresql://localhost:6432/mydb

与应用级连接池的配合

最佳实践是同时使用应用级连接池和 PgBouncer：

  • 应用级连接池：处理应用内部的连接复用
  • PgBouncer：处理多个应用实例到数据库的连接复用

HikariCP

HikariCP

HikariCP

Limited Connections

Application Instance 1

PgBouncer

Application Instance 2

Application Instance N

PostgreSQL

这种架构下：

  • 每个应用实例的 HikariCP 池大小设置为较小值（如 10-20）
  • PgBouncer 的 default_pool_size 设置为合理的总数（如 100-200）
  • PostgreSQL 的 max_connections 只需要设置为略大于 PgBouncer 的总连接数

性能测试与基准比较 📈

为了验证不同配置的效果，我们可以进行简单的性能测试。

测试环境设置

publicclassConnectionPoolBenchmark{privatestaticfinalint THREAD_COUNT =50;privatestaticfinalint ITERATIONS =1000;publicstaticvoidbenchmarkHikariCP()throwsException{HikariDataSource ds =createHikariDataSource();ExecutorService executor =Executors.newFixedThreadPool(THREAD_COUNT);CountDownLatch latch =newCountDownLatch(THREAD_COUNT);AtomicLong totalTime =newAtomicLong(0);long startTime =System.currentTimeMillis();for(int i =0; i < THREAD_COUNT; i++){ executor.submit(()->{try{for(int j =0; j < ITERATIONS; j++){long queryStart =System.currentTimeMillis();try(Connection conn = ds.getConnection();PreparedStatement stmt = conn.prepareStatement("SELECT 1")){ stmt.executeQuery();} totalTime.addAndGet(System.currentTimeMillis()- queryStart);}}catch(Exception e){ e.printStackTrace();}finally{ latch.countDown();}});} latch.await();long elapsed =System.currentTimeMillis()- startTime;System.out.printf("HikariCP - Threads: %d, Iterations: %d, Total Time: %dms, Avg Query Time: %.2fms%n", THREAD_COUNT, ITERATIONS, elapsed, totalTime.get()/(double)(THREAD_COUNT * ITERATIONS)); ds.close(); executor.shutdown();}}

测试结果分析

在典型的 4 核 8GB 内存服务器上，不同配置的性能表现：

配置方案max_connections池大小平均响应时间内存使用
直接连接200N/A15ms1.6GB
HikariCP50202ms400MB
HikariCP + PgBouncer10010 (应用) + 50 (PgBouncer)3ms800MB

从结果可以看出，使用连接池可以显著降低响应时间和内存消耗。

生产环境部署建议 🚀

在生产环境中部署 PostgreSQL 连接管理方案时，需要考虑以下几点：

1. 配置管理

  • 使用配置文件而不是硬编码连接参数
  • 支持动态配置更新（某些连接池支持）
  • 敏感信息（密码）使用环境变量或密钥管理服务
# 推荐的配置文件结构database:url: ${DB_URL:jdbc:postgresql://localhost:5432/mydb}username: ${DB_USERNAME:myuser}password: ${DB_PASSWORD}pool:max-size: ${DB_POOL_MAX_SIZE:20}min-idle: ${DB_POOL_MIN_IDLE:5}connection-timeout: ${DB_CONNECTION_TIMEOUT:30000}

2. 监控告警

建立完善的监控体系：

  • 连接池指标监控：活跃连接数、等待线程数、连接获取时间
  • PostgreSQL 监控：pg_stat_activity、连接数、锁等待
  • 告警规则：
    • 连接池使用率 > 80%
    • 等待获取连接的线程数 > 0
    • 连接获取时间 > 1秒

3. 容量规划

定期进行容量评估：

-- 检查历史最高连接数SELECT max_connections,(SELECTcount(*)FROM pg_stat_activity)as current_connections,(SELECTcount(*)FROM pg_stat_activity WHERE state ='active')as active_connections FROM pg_settings WHERE name ='max_connections';

根据业务增长趋势，提前规划连接数调整。

4. 故障恢复

实现优雅的故障恢复机制：

  • 连接池健康检查
  • 自动重连机制
  • 降级策略（如返回缓存数据）
publicclassResilientDatabaseAccess{privatefinalHikariDataSource dataSource;publicList<User>getUsersWithFallback(){try{returngetUsersFromDatabase();}catch(SQLException e){ log.warn("Database access failed, falling back to cache", e);returngetUsersFromCache();}}privateList<User>getUsersFromDatabase()throwsSQLException{// 数据库访问逻辑}privateList<User>getUsersFromCache(){// 缓存访问逻辑}}

总结与最佳实践回顾 ✅

通过本文的详细探讨，我们可以总结出以下关键要点：

PostgreSQL 连接管理的核心原则

  1. 连接是有代价的：每个 PostgreSQL 连接消耗 5-10MB 内存
  2. 少即是多：合理的小连接池通常比大连接池性能更好
  3. 分层池化：应用级连接池 + PgBouncer 提供最佳效果
  4. 监控至上：没有监控的连接池就像没有仪表盘的飞机

推荐的配置组合

对于大多数 Java Web 应用：

// HikariCP 配置 maximumPoolSize = CPU核心数 *2(最大20-30) minimumIdle = maximumPoolSize /2 connectionTimeout =20000 idleTimeout =600000 maxLifetime =1800000// PostgreSQL 配置 max_connections =100-200(根据实际需要) shared_buffers = 系统内存的25%(最大8GB) work_mem =4-16MB (根据查询复杂度)

学习资源推荐 🔗

记住，没有放之四海而皆准的配置。最佳的连接池配置需要根据你的具体应用场景、硬件资源和性能要求进行调整和优化。通过持续的监控、测试和调优，你一定能够找到最适合你的 PostgreSQL 连接管理方案！

🙌 感谢你读到这里！
🔍 技术之路没有捷径，但每一次阅读、思考和实践，都在悄悄拉近你与目标的距离。
💡 如果本文对你有帮助，不妨 👍 点赞、📌 收藏、📤 分享 给更多需要的朋友！
💬 欢迎在评论区留下你的想法、疑问或建议，我会一一回复，我们一起交流、共同成长 🌿
🔔 关注我，不错过下一篇干货！我们下期再见！✨

Read more

掌控消息全链路(4)——RabbitMQ/Spring-AMQP高级特性详解之事务与消息分发

掌控消息全链路(4)——RabbitMQ/Spring-AMQP高级特性详解之事务与消息分发

🔥我的主页：九转苍翎⭐️个人专栏：《Java SE》《Java集合框架系统精讲》《MySQL高手之路：从基础到高阶》《计算机网络》《Java工程师核心能力体系构建》《RabbitMQ理论与实践》天行健，君子以自强不息。 1.事务 AMQP(高级消息队列协议)实现了事务机制，主要用于确保消息的原子性发布和确认。换言之，它允许你将多个操作(如发送消息、确认消息)绑定在一起，要么全部成功，要么全部失败 发送消息 @RestController@RequestMapping("/producer")publicclassProducerController{@Resource(name ="transRabbitTemplate")privateRabbitTemplate transRabbitTemplate;@Transactional@RequestMapping("/trans")publicStringtrans(){ transRabbitTemplate.convertAndSend(""

By Ne0inhk
C语言程序调试常用方法与技巧

C语言程序调试常用方法与技巧

C语言程序调试常用方法与技巧 一、学习目标与重点 学习目标 * 理解程序调试的基本概念 * 掌握常用调试工具的基本使用方法 * 学会使用调试技巧定位程序中的错误 * 提高程序调试的效率和准确率 学习重点 * 调试工具的安装与配置 * 断点设置与单步调试 * 变量值查看与内存分析 * 错误定位与修复技巧 二、程序调试的基本概念 2.1 调试的定义与意义 调试是指在程序运行过程中，通过观察和分析程序的行为，定位并修复错误的过程。程序调试的主要目的是提高程序的正确性和可靠性，确保程序能够按照预期的方式运行。 2.2 调试的主要步骤 1. 发现问题：通过测试或用户反馈，发现程序中的错误。 2. 定位问题：通过调试工具和技术，确定错误所在的位置和原因。 3. 修复问题：修改代码，修复错误。 4. 验证修复：重新测试程序，确保错误已经修复，并且没有引入新的错误。 2.3 调试的常见方法 * 输出调试：在程序中插入打印语句，输出变量值和程序执行路径。 * 单步调试：

By Ne0inhk
构建基于 Rust 与 GLM-5 的高性能 AI 翻译 CLI 工具：从环境搭建到核心实现全解析

构建基于 Rust 与 GLM-5 的高性能 AI 翻译 CLI 工具：从环境搭建到核心实现全解析

前言 随着大语言模型（LLM）能力的飞速提升，将 AI 能力集成到终端命令行工具（CLI）中已成为提升开发效率的重要手段。Rust 语言凭借其内存安全、零成本抽象以及极其高效的异步运行时，成为构建此类高性能网络 IO 密集型应用的首选。本文将深度剖析如何使用 Rust 语言，结合智谱 AI 的 GLM-5 模型，从零构建一个支持流式输出、多语言切换及文件批处理的 AI 翻译引擎。 本文将涵盖环境配置、依赖管理、异步网络编程、流式数据处理（SSE）、命令行参数解析以及最终的二进制发布优化。 第一部分：Rust 开发环境的系统级构建 在涉足 Rust 编程之前，必须确保底层操作系统具备必要的构建工具链。Rust 虽然拥有独立的包管理器，但在链接阶段依赖于系统的 C 语言编译器和链接器，尤其是在涉及网络库（如 reqwest 依赖的 OpenSSL）

By Ne0inhk
Spring Boot + jQuery 前后端分离图书管理系统：从接口设计到问题排查

Spring Boot + jQuery 前后端分离图书管理系统：从接口设计到问题排查

图书管理系统 1.1 准备前端代码 在本地想要的可以去我的gitee中下载 library 的相关前端代码 1.2 约定前后端交互接口 需求分析 图书管理系统是⼀个相对较大一点的案例,咱们先实现其中的⼀部分功能. 用户登录 1. 登录接口 2. 图书列表展示 字段说明: 字段说明id图书 IDbookName图书名称author作者count数量price定价publish图书出版社status图书状态 1 - 可借阅 其他 - 不可借阅statusCN图书状态中文含义 3.4.3 服务器代码 创建图书类 BookInfo @Data public class BookInfo { //图书ID private Integer id; //书名 private String bookName; //作者 private String

By Ne0inhk