我们公司接手了一个跨境电商客户，计划上线一个 “全品类 + 高流量 + 高并发查询 + 高频促销” 的独立站——包括商品展示、库存查询、用户订单查询、价格优惠规则、库存同步、订单状态同步等。预计日均 PV 会达到几十万／天，促销高峰可能瞬时出现 上千到几千个并发数据库查询 (例如多个用户同时浏览、下单、库存 check + 写操作)。

我们为这个项目在A5IDC香港数据中心上架了一台物理裸金属服务器，配置如下：

• CPU: Intel Xeon E5‑2695 v4（22 核 / 44 线程，基础频率 2.1GHz，睿频可达 3.3GHz，具有较大的 L3 缓存）
• 内存: 128 GB DDR4‑2400
• 存储: 1 TB SSD (当时用于数据库数据 + WAL + 索引)
• 操作系统: Ubuntu 20.04 LTS + ext4 或 xfs（后期改为 xfs + noatime + nodiratime）
• 数据库: 当时我们测试过 PostgreSQL (也评估过 MySQL / InnoDB，但最终选择 PostgreSQL，因为跨境电商订单与库存逻辑复杂，事务和一致性要求高)

最初我们觉得，这套硬件配置——22 核 + 128 GB + SSD ——对于一个中等 / 大型电商数据库 server 应该 “绰绰有余”。但上线后不久，就遇到了两个严重问题：

• “查询延迟”在高并发访问时明显上升，有时单个查询从几十毫秒飙升到 200–500ms。
• “连接池耗尽 / 超时 / 连接排队”：应用层连接池 (pool) 很快用光，新的请求必须等待，造成用户端卡顿甚至失败。
• 这些现象令我们夜不能寐 —— 促销期间大型数据库瓶颈，很可能导致大量订单丢失 / 用户流失。于是我们决定亲自深入排查、优化。

问题排查：我首先关注什么？

1. 是硬件不够？还是数据库 / 系统配置不当？

我先检查硬件资源使用情况：

结论：物理硬件 + SSD + 内存，从基础性能上看是足够的。瓶颈更可能出在数据库软件配置、连接管理、查询设计层面。

2. 看慢查询 / 执行计划 / 连接池状态

我开启了 PostgreSQL 的慢查询日志 (设置 log_min_duration_statement = 100 ms)，并使用扩展 pg_stat_statements 收集统计信息，以识别最慢、最频繁的 SQL。 

同时，在应用层 (Node.js + pg driver) 我打印 pool 状态 (connections in use / idle / waiting)、连接等待队列情况、连接获取 / 释放时间。

也触发了人工压测 (模拟数百、上千并发)，并用 EXPLAIN ANALYZE 检查慢查询的执行计划。

结果显示：

很多慢查询是对大表 (orders / products / inventory) 的复杂 JOIN / filter / sort / group_by。

尽管我们在某些字段上建了索引，但访问模式变化 (促销、库存 check、搜索 filter + price range + category + sort by popularity) 导致大量索引未被有效利用，甚至出现顺序扫描 (sequential scan) + 排序 (sort) + 临时表 + 磁盘 I/O。

连接池在高并发时长时间被用满 (active connections = pool.max)，新的请求只能等待或失败。

这些都说明，问题不仅是连接管理，还有查询本身和数据库配置——尤其在高并发、高复杂度查询时，默认配置无法支撑。

我采取的优化 / 解决措施（分步骤详述）

以下是我当时按顺序做的优化，并记录遇到的问题／坑，以及最终效果。

第一步：数据库 + 系统调优

调整 PostgreSQL 配置

我参考社区和生产环境经验 (例如生产级 tuning 指南) ，对 postgresql.conf 做了一系列调整：

# memory-related
shared_buffers = 32GB        # 约为总内存的 25%–30%
effective_cache_size = 80GB   # 估算 OS + PostgreSQL 总缓存
work_mem = 16MB               # 适当提升，以支持复杂 JOIN / sort / hash 操作
maintenance_work_mem = 512MB  # 用于 VACUUM / CREATE INDEX 等操作

同时，我启用了 Linux 的大页 (hugepages) + 禁用了透明大页 (transparent hugepages)，以减少页面碎片与 TLB miss，提高大内存访问效率。 

对操作系统也做了调优 (通过 tuned / sysctl / kernel 参数)：

禁用 swap / 降低 swappiness，避免在内存紧张时触发 swap。

给 PostgreSQL 数据所在分区挂载时加入 noatime,nodiratime，减少文件访问时的磁盘额外开销。 

分离 WAL 和数据 / 索引存储（可选）

虽然我们的 SSD 性能不错，但 I/O 高峰 (尤其写操作 + 索引 rebuild + VACUUM / autovacuum) 时，WAL 写 + 数据写 + 索引写 + checkpoint 同时进行，仍可能造成 I/O 争抢。
所以我把 WAL 日志单独放到一个专用 SSD（same server，但逻辑分区），而数据 + 索引放主 SSD。结果是在高写入 + 查询 + checkpoint 同时发生时，延迟有明显下降 (约 20–30%)。

定期维护 & 自动统计

开启自动 autovacuum + autoanalyze，确保表统计 (statistics) 不过期，查询优化器 (planner) 能得到合理执行计划。 

对大表 (例如 orders_history, inventory_changes) 设定 partition 分区 (比如按月份 / 按订单日期分区)，这样查询、删除、归档操作都局部化，减少表扫描 / 扫描老数据量。

第二步：连接池 + 架构 + 缓存优化

引入连接池中间件

虽然应用层本身有 pool (Node.js pg pool)，但在高并发、高连接数时，pool 连接复用 + 最大连接数 + 空闲连接 + 超时策略 都是瓶颈。

我改用 PgBouncer 作为外部连接池 (pooler)，把它放在应用 → PostgreSQL 之间。PgBouncer 使用 transaction pooling 模式 (即一个客户端事务结束就释放连接)，极大降低数据库后端实际连接数。 

PgBouncer 配置示例 (pgbouncer.ini)：

[databases]
mydb = host=127.0.0.1 port=5432 dbname=mydb

[pgbouncer]
listen_addr = 0.0.0.0
listen_port = 6432
auth_type = md5
auth_file = /etc/pgbouncer/userlist.txt
pool_mode = transaction
max_client_conn = 500      # 支持更多前端连接
default_pool_size = 100    # 后端 Postgres 实际连接数上限
reserve_pool_size = 20
reserve_pool_timeout = 5

结果：在高并发 (500+ 并发请求) 场景下，后端 Postgres 连接数保持在可控范围 ( ≤ 100)，连接获取与释放延迟大幅下降 (平均 < 2 ms)，连接池不再轻易耗尽。

增加读缓存 / 异步 / 缓存层

对于业务中 “频繁读但变化不大的数据” — 比如商品信息、分类、价格、促销规则、库存缓存 (在允许一定延迟的情况下)，我引入了缓存层 (Redis)：

• 大多数 GET / 商品查询请求先命中 Redis cache (TTL 设置如 30s–5min，根据业务可容忍时延)
• 如果 cache miss，再去 PostgreSQL 查询，并把结果回写缓存

这样，数据库访问量 (尤其 read-heavy 查询) 很大比例被缓存拦截，PostgreSQL 的连接 / 查询压力明显下降。 事实上，当我们把 “read-heavy 查询 + cache first” 的比例提高到约 70–80% 后，整体数据库响应延迟减少到几十 ms → 100ms 内 (高并发下也稳定)，连接池压力大为缓解。 

对高频 / 重量级查询做异步 / 批量 / 延迟处理

对于一些复杂统计 / 报表 /库存同步 /大 JOIN 查询，我不再让前端用户等待，而改为：

• 后台异步任务 (job queue) 批量执行 (用 worker / cron /队列)，避免高并发用户请求同时触发复杂查询
• 或者预先计算 / 预聚合 (pre-aggregate)，将结果缓存 (Redis / 物化视图 / summary table)，减少用户请求时的计算量

这样避免了 “高并发 + 重查询” 对数据库的冲击。

遇到的坑 & “现场调试”故事

坑 1 — 开启 shared_buffers 太大反而造成问题

一开始我把 shared_buffers 设成 64 GB（考虑到我们有 128 GB 内存），但上线后发现数据库启动很慢，有时 autovacuum / checkpoint 时系统 I/O 突然变慢。后来查资料发现，如果把 shared_buffers 设得过大，会与 OS cache + kernel 的 I/O flush / dirty page 写回冲突，反而降低性能。参照社区建议，把它限制在总内存的 20–30% 较为稳妥。 

坑 2 — PgBouncer 配置不合理导致连接 leak

刚开始我设置 default_pool_size = 200，max_client_conn = 1000，想“多开点连接够用”。结果压测中发现 Postgres 后端连接数瞬间爆炸 (接近 200–250)，最终导致 Postgres 无法响应 new connection，出现 “too many connections” 错误。
后来查确认 PgBouncer 的 transaction pooling 模式 + 控制后端连接数 (default_pool_size + reserve) + 限制前端连接 (max_client_conn) 才是稳定做法。

坑 3 — 缓存一致性 / 过期 / 并发更新问题

当促销 / 库存变动频繁的时候，Redis 缓存可能命中旧数据 (例如库存不足还给用户展示为有货)，导致前端用户下单失败 /库存超卖。我不得不为关键写操作 (库存扣减、订单创建) 引入缓存失效 / 更新机制 + 乐观锁 / 库存校验机制 (先从 PostgreSQL 再检查)，有时还需要用分布式锁 (Redis lock) 来保证并发安全。虽然增加了代码复杂度，但保证了数据一致性和用户体验。

最终结果 — 成果 & 性能对比

经过上述优化与调整，我们做了一轮上线前压测 + 真实业务高峰测试 (促销 + 库存同步 + 大量浏览 + 下单)。下面是前后对比 (部分数据来自压测统计 + 真实流量监控)：

“那一刻，我第一次松了一口气 — 我看到监控 dashboard 上，PgBouncer 的 active connection 稳定在 ~100，而 Redis hit rate 接近 75%，PostgreSQL 的慢查询基本消失了。”

我的总结 / Lessons Learned

硬件再强，也需要软件 + 架构 配合。 22 核 + 128 GB + SSD 只是基础，但如果数据库配置、连接管理、缓存、查询设计不当，高并发下依然瓶颈明显。

连接池 (pooling) + 缓存 (cache) + 异步 / 批量 /预计算 是高并发读 / 写混合系统的基础 — 不可或缺。对于跨境电商这种读多且读写混合的场景，必须提前设计好。

数据库和系统调优不能忽视：shared_buffers、effective_cache_size、work_mem、文件系统 mount 选项 (noatime)、HugePages、WAL 分离、autovacuum、表分区……这些看似琐碎，却会对性能产生决定性影响。

监控 + 压测 + 慢查询日志 + 实际高峰测试 必须贯穿整个上线过程。很多问题只有在高并发 + 高写入 + 真实流量环境下才会暴露。

缓存一致性与业务逻辑复杂度是平衡点 —— 缓存能极大减轻数据库负载，但也带来数据 staleness / 并发写冲突 / 复杂失效逻辑，需要谨慎设计。

如果是今天 — 我可能还会这样升级

如果让我重新设计这样一套系统，并且目标是支持未来更大规模 (百万级 PV / 秒级并发 / 多区域部署)，我会考虑：

• 读写分离 + 主从 / 多副本 + 异步复制 + 读库池 + 负载均衡 (master–slave / master–replica / read replica)
• 水平拆库 / 分库 + 分区 + shard / multi‑tenant / microservice 架构，避免单表过大 / 单库过重
• 更多缓存 / CDN / edge cache / application-level cache，尤其是对静态 / 半静态数据 (商品、价格、库存快照等)
• 异步任务队列 / 工作流 /消息队列 (MQ)，把非关键、耗时、批量操作都放后台执行，减少对用户请求响应的阻塞
• 监控 + 自动扩缩容 + 弹性池管理 + 异常报警 / 回退机制，确保高峰 / 异常 /突发流量下系统稳定

写到这里，我回想起那段在香港机房、盯着监控屏幕、手敲配置文件、重启数据库、跑压测脚本、调试 PgBouncer、写缓存失效逻辑、手动制造高并发、然后深夜看着响应时间从“500ms → 50ms → 稳定 20–150ms”的过程——仿佛又回到那个凌晨。

那套 Xeon E5‑2695 v4 + 128 GB + SSD 裸机，虽然从硬件上看还“能跑很多年”，但若没有数据库层面的优化、连接池 + 缓存 + 架构设计，那只是一个“躯壳”。