服务器资源有限时，如何优化数据库与服务同机部署的稳定性？

在服务器资源受限（如低配 ECS/CVM、内存紧张、CPU 核心数少）的情况下，将数据库与应用服务部署在同一台机器上是一种典型的“高风险高收益”架构。虽然节省了内网延迟和独立硬件成本，但一旦应用出现内存泄漏或突发流量，极易导致数据库进程被 OOM Killer（内存溢出终止器）杀掉，从而引发整个服务雪崩。

要在这种环境下保证稳定性，核心思路不是“增加资源”，而是“隔离风险”和“极致调优”。以下是经过生产环境验证的优化策略：

1. 操作系统层面的硬性隔离与保护

这是最后一道防线，防止应用拖垮系统底层。

• 配置 Swap 分区（虚拟内存）
  • 误区：很多人认为 SSD 做 Swap 会损坏磁盘寿命或影响性能，因此禁用 Swap。但在资源极度受限时，Swap 是防止 OOM 的关键缓冲。
  • 操作：确保至少分配 2-4GB 的 Swap 空间。设置 vm.swappiness=10（默认可能是 60），让系统优先使用物理内存，只有在物理内存耗尽时才谨慎使用 Swap，避免频繁换页导致的性能抖动。
• 调整 OOM Score（防误杀机制）
  • Linux 内核在内存不足时会根据 oom_score_adj 决定杀死哪个进程。通常数据库进程的优先级较高，容易被杀。
  • 操作：降低数据库进程的 OOM 分数，提高其存活优先级。例如，对于 MySQL/MariaDB，可以在启动脚本中设置 OOMScoreAdjust=-900（范围 -1000 到 1000，数值越低越不容易被杀）。同时，适当提高应用服务的 OOM 分数，确保应用先挂，数据库后挂。
• Cgroups 资源限制（如果容器化或支持 systemd）
  • 如果使用 Docker 或 Kubernetes，务必为数据库容器和应用容器分别设置 memory.limit_in_bytes 和 cpu.shares。
  • 关键点：数据库的限制应略高于其实际峰值需求，留出一点余量；应用的限制应严格设定，防止其无底洞式消耗资源。

2. 数据库引擎的深度调优（以 MySQL 为例）

同机部署时，数据库必须“瘦身”并“高效”。

• InnoDB Buffer Pool 大小控制
  • 黄金法则：Buffer Pool 大小不应超过物理内存的 50%-70%。
  • 原因：如果设置过大，当应用突然申请大量内存时，操作系统无法及时回收数据库缓存，直接触发 OOM。留出 30% 给 OS Page Cache 和应用堆内存至关重要。
  • 示例：2GB 内存服务器，Buffer Pool 设为 800MB-1GB。
• 连接数限制（max_connections）
  • 不要使用默认值（通常是 151 或更高）。同机部署下，每个连接都消耗内存（per-thread memory）。
  • 计算：max_connections 应小于 (总内存 - 其他开销) / (每连接内存)。建议设置为 50-100，并通过连接池（如 HikariCP, Druid）在应用层复用连接，避免数据库层面建立过多空闲连接。
• 关闭不必要的功能
  • 关闭二进制日志（binlog）如果不需要主从复制和数据恢复（仅用于开发/测试环境可考虑，生产环境慎用，建议用异步备份替代）。
  • 关闭慢查询日志（slow_query_log）除非正在排查问题，否则 I/O 开销显著。
  • 禁用 DNS 解析：设置 skip-name-resolve，避免每次连接都进行反向 DNS 查询，减少延迟和 CPU 开销。
• 选择轻量级引擎
  • 如果业务简单，考虑使用 SQLite（单机文件型数据库）或 MariaDB（比 MySQL 稍轻）。如果必须用 MySQL，考虑 Percona Server 或 TokuDB 等对 I/O 更友好的变体。

3. 应用层的协同优化

应用是资源消耗的源头，必须做到“克制”。

• 强制使用连接池
  • 绝对禁止每次请求都新建数据库连接。使用 HikariCP（Java）、PgBouncer（PostgreSQL）或类似中间件。
  • 连接池最大连接数应与数据库 max_connections 配合，预留 10%-20% 给管理命令。
• SQL 查询极致优化
  • 索引先行：确保所有高频查询都有合适索引，避免全表扫描。
  • **避免 SELECT ***：只查询需要的字段，减少网络传输和内存占用。
  • 分页优化：深分页（如 LIMIT 100000, 10）极其消耗 CPU 和临时表空间。改用基于游标或 ID 的范围查询。
• 引入本地缓存（Local Cache）
  • 在应用内存中使用 Caffeine、Guava Cache 或 Redis（如果 Redis 也同机，需额外注意）缓存热点数据。
  • 目的：大幅减少对数据库的直接读取次数，尤其在读多写少的场景下效果显著。
• 异步处理与非阻塞 I/O
  • 将非实时任务（如发送邮件、记录日志、统计报表）放入消息队列（即使是一个简单的本地 FIFO 文件或 RabbitMQ 单机版），避免同步阻塞数据库连接。

4. 监控与告警：前置预警

在没有冗余资源的情况下，你必须比故障早一步发现异常。

• 关键指标监控
  • 内存使用率：重点关注 RSS（常驻集大小），而非 Virtual Memory。
  • Swap 使用量：如果 Swap 开始持续增长，说明系统已处于危险边缘，应立即扩容或限流。
  • I/O Wait：同机部署时，应用和数据库共享磁盘 I/O。高 I/O Wait 意味着两者在争抢磁盘带宽。
  • 数据库连接数：接近上限时立即告警。
• 自动化熔断与降级
  • 当检测到数据库响应时间超过阈值（如 500ms）或错误率上升时，应用层应自动触发熔断，返回默认值或友好提示，而不是继续堆积请求压垮数据库。

5. 架构建议：长期来看，必须分离

虽然上述方法可以缓解短期压力，但从工程角度看，数据库与应用同机部署始终是不可靠的。

• 短期方案：利用云厂商的“按量付费”特性，在促销期间购买低配实例，通过上述调优维持运行。
• 中期方案：使用云数据库 RDS（基础版）。国内云厂商（阿里云、腾讯云、华为云）的基础版 RDS 价格极低，有时甚至低于自建服务器的运维成本和电费。将数据库迁移到 RDS，释放本机资源给应用，是性价比最高的稳定化手段。
• 长期方案：微服务拆分 + 独立数据库实例。这是唯一能真正解决资源争抢问题的路径。

总结 checklist

1. [ ] 设置 Swap 并调整 swappiness=10
2. [ ] 调整数据库进程 OOM Score 为负值（如 -900）
3. [ ] InnoDB Buffer Pool 设为物理内存的 50%-70%
4. [ ] 限制 max_connections，并在应用端使用连接池
5. [ ] 启用 skip-name-resolve
6. [ ] 应用层加入本地缓存和 SQL 优化
7. [ ] 部署监控告警，重点盯防 Swap 使用和内存峰值

记住：资源有限时，稳定性不来自“更强”，而来自“更省”和“更稳”。