SpringBoot+PostgreSQL高并发场景数据库性能优化咨询

你当前遇到的核心问题是单实例PostgreSQL连接数天花板导致的服务不可用，迁移Aurora PostgreSQL时按以下分层方案落地，可稳定支撑峰值流量，不需要强行上调数据库连接数阈值。

架构层优化（优先级最高，先搭架构再调参数） #

• 启用Aurora读写分离集群：预约类场景读请求占比普遍在80%以上（可预约时段查询、个人记录查询、资质校验等），部署1个主写实例+4~8个只读副本（峰值时段可临时弹性扩容副本数），将非强一致性读请求全量路由到只读副本，仅扣库存、提交预约这类事务类写请求走主实例，可直接降低主库70%以上的连接与读写压力。Aurora只读副本与主实例共享分布式存储，常规复制延迟在10ms以内，仅预约提交后的即时结果查询需要强制走主库，其余场景完全满足一致性要求。
• 部署托管连接代理：不要让应用直连数据库，开启Aurora原生配套的RDS Proxy做连接复用，代理层与数据库之间维持固定数量的长连接（主库配置2000个长连接，每个只读副本配置1000个长连接，远低于5000的连接数阈值），承接应用侧的上万级连接请求，从根源上避免连接数打满的问题。RDS Proxy自带空闲连接回收、故障自动切换、连接保活能力，不需要自行维护PgBouncer这类开源连接池，运维成本极低。
• 热点数据前置缓存：将可预约时段库存、预约规则、公共说明这类高频访问的热点数据全量托管到Redis缓存集群，峰值时段90%以上的热点查询直接从缓存返回，不穿透到数据库层。预约扣库存场景可先用Redis做预扣，再异步同步到数据库，大幅降低数据库行锁竞争压力。

Aurora PostgreSQL核心参数调优 #

• 连接数配置：不要盲目上调max_connections参数，主实例设置为2000，每个只读副本设置为1200，预留30%左右的连接容量给备份、运维、数据迁移等内部任务，避免连接数打满拒绝服务。配合RDS Proxy的连接复用能力，这个连接规模完全可以承接前端5万并发用户的请求。
• 内存参数配置：shared_buffers设置为实例可用内存的70%，最大化缓存热点数据，减少磁盘IO；work_mem设置为64MB，满足排序、哈希聚合类查询的内存需求，避免频繁落盘；maintenance_work_mem设置为2GB，提升建索引、VACUUM等维护操作的效率。
• 事务与超时配置：idle_in_transaction_session_timeout设置为30秒，自动回收长时间空闲的事务连接，避免无效连接占用资源；lock_timeout设置为5秒，避免高峰期死锁导致请求堆积；statement_timeout在只读副本设置为10秒、主实例设置为3秒，拦截慢查询拖垮整体性能。
• 日志配置：开启log_min_duration_statement，记录执行时长超过200ms的慢查询，压测及上线初期重点优化慢SQL，为高频查询字段建立合适的联合索引，避免全表扫描消耗资源。

SpringBoot应用侧配套优化 #

• 应用连接池不要配置过大：使用HikariCP连接池时，单个应用实例的最大连接数设置为10_{20即可（按部署200个应用实例计算，应用侧总连接数为2000}4000，经过RDS Proxy复用后，实际落到数据库的长连接仅数百个）。注意数据库连接数不是越大越好，当连接数超过实例CPU核数2倍后，线程上下文切换的开销会导致数据库性能指数级下降。
• 数据库访问逻辑精简：事务范围尽可能缩小，禁止在数据库事务内执行RPC调用、缓存操作这类非DB逻辑，避免长事务占用连接；所有列表查询必须带分页限制，禁止无limit的全量查询；高频更新的预约库存表控制二级索引数量，降低写入时的索引维护开销。
• 熔断降级配置：为所有数据库操作设置1秒的执行超时阈值，超时直接返回“当前预约人数较多，请稍后重试”的降级提示；接入熔断组件，当数据库错误率超过20%时自动拦截非核心请求，避免流量雪崩打穿数据库。

峰值流量削峰设计 #

• 预约类场景天然存在瞬时流量尖刺，前端增加验证码、答题、排队等待页逻辑，将瞬时5万并发打散为10秒以上的平滑流量，避免尖刺直接打穿缓存和数据库。
• 预约提交请求先写入消息队列，消费端按数据库最大承载能力匀速消费，用户端先返回“预约提交中”的提示，处理完成后再通过站内信、短信通知结果，将数据库写入QPS稳定在安全阈值内，完全不会出现连接打满的问题。

上线前必须完成全链路压测，模拟5万峰值并发场景，重点验证数据库连接水位、主从复制延迟、慢查询占比、锁等待时长等指标，将数据库峰值CPU控制在60%左右、连接数不超过配置阈值的70%，再切全量流量上线。

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