上个月，公司接到了一个跨境电商客户，要求在香港部署一台数据库主机，承载促销高峰期每日 50 万 PV、瞬时并发写入达到几千条／秒的订单流 + 查询流。作为一家专注香港服务器租用托管的技术团队，我负责这台主机的选型、部署、系统调优、上线运营。这篇文章，就记录我从机房现场硬件上架、系统安装、数据库部署、性能瓶颈排查、优化调优，到最终稳定上线的全过程，希望给同样在香港服务器环境下（尤其是跨境电商／游戏／短视频类）做数据库系统的同仁一个可参考的 “落地”方案。

一、硬件／网络环境 与 选型缘由

硬件配置

我们最终选定如下硬件配置（全部在香港数据中心机柜现场实装）：

二、为什么选择上述配置？我当时现场思考如下：

客户数据库为促销高并发＋大量写＋查询混合型，而香港服务器既要面向东南亚/内地用户，又要稳定承载高并发。

Intel Xeon Gold 6230 在多核＋高缓存＋较新架构方面表现优异，对数据库高并发场景有优势。

使用128 GB内存，可以将大部分热数据缓存至内存／操作系统缓存＋数据库缓冲池，从而减轻 SSD 的压力，提升响应速度。

1 TB 主 NVMe SSD 可作为数据库主数据 +日志盘，未来可考虑将日志盘／数据盘分离，但初期部署简化为单盘。

网络上香港至内地的路由非常关键：选择 CN2 优化线路以降低访问延迟、丢包率，对游戏/电商体验至关。

操作系统选择 RHEL 8，是目前主流企业级服务器系统，且有多项性能优化提升。

三、系统安装与初始配置

操作系统安装

在机房现场完成硬件上架、网线、电源、IPMI 控制台访问。

从 USB 安装 RHEL 8.6（当时版本）；选择最小安装模式 + GUI（仅做运维方便）。

安装后，执行以下命令关闭不必要的服务、启用性能模式等：

# 禁用 SELinux 临时 → 持久
sed -i 's/^SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config
setenforce 0

# 安装常用工具
dnf install -y vim git net-tools perf sysstat

# 开启性能模式
tuned-adm profile throughput-performance

我选择 throughput‑performance 模式，基于 tuned 工具，该工具官方文档指出可对磁盘、网络、CPU 进行调优。

同时，在 BIOS 里将 CPU 节能选项关闭（Server Performance／C‑States最低）以保证最低延迟。

存储与文件系统配置

将 1 TB NVMe SSD 设置为 /dev/nvme0n1。我决定将整个盘用于数据库，但在文件系统上使用 XFS，因为在 RHEL8 上 XFS 是推荐用于大文件系统、现代硬件场景的。

分区策略：

简化为一个分区 /dev/nvme0n1p1，挂载至 /var/lib/mysql。

在 /etc/fstab 中配置挂载选项（加入 noatime,nodiratime）：

/dev/nvme0n1p1  /var/lib/mysql  xfs  defaults,noatime,nodiratime  0 0

格式化命令示例：

mkfs.xfs -f /dev/nvme0n1p1
mkdir -p /var/lib/mysql
mount /dev/nvme0n1p1 /var/lib/mysql
chown mysql:mysql /var/lib/mysql
chmod 750 /var/lib/mysql

我也按 RHEL 的调优指南，将 I/O 调度器更改为 deadline，这是针对 SSD 的建议之一。

网络配置

在机房网络控制台确认：1 Gbps 物理口已绑定，网络为 CN2 优化＋BGP多线路。

在 Linux 系统里检查 /etc/sysctl.d/99‑db‑network.conf，加如下调优：

net.core.somaxconn = 4096
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_max_syn_backlog = 2048

同时禁用网卡节能待机（ISOLATION_MODE关闭）、关闭 irqbalance 并手动绑定网络中断到特定 CPU 核（考虑未来游戏/电商峰值场景）。

四、数据库系统选型与初始部署

在本案例中，客户使用的是 MySQL 8.0（社区版）+ InnoDB 引擎，用于订单表 +商品表 +用户表 +实时查询业务。初期配置如下：

MySQL 安装（通过 RHEL 官方仓库）：

dnf install -y @mysql
systemctl enable --now mysqld

初始化后，编辑 /etc/my.cnf.d/custom.cnf，加入关键参数：

[mysqld]
# 基本
user = mysql
basedir = /usr
datadir = /var/lib/mysql
port = 3306
symbolic-links = 0

# InnoDB 配置
innodb_buffer_pool_size = 64G
innodb_log_file_size = 2G
innodb_flush_method = O_DIRECT
innodb_flush_log_at_trx_commit = 1
innodb_io_capacity = 2000
innodb_io_capacity_max = 4000

# 连接数
max_connections = 2000
thread_cache_size = 100
table_open_cache = 4096

# 日志
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
log_error = /var/log/mysql/error.log

说明：

我将 innodb_buffer_pool_size 设为 64 GB，几乎占用内存的一半（128 GB 总内存的一半），这是根据 MySQL 优化手册“缓冲池大小建议占系统内存50–75%”得出的。

innodb_flush_method = O_DIRECT 配合 SSD 使用能避免操作系统缓存带来的双缓存开销。

innodb_io_capacity 提升到 2000 /4000 是因为 SSD 较高 IOPS 能力，我在初期测试发现默认 10000 是偏低，对当前 SSD 跟写密集 SQL 插入场景不够。

max_connections = 2000 是基于预计并发连接数（峰值可能达几千并发）预估的。

初次数据导入与基准测试

使用 mysqlpump 导入初期客户数据库（约300 万行商品、订单日产生10 万条预估）。导入期间 IOPS 测为约 150k 秒级随机读取+写入。

使用 sysbench 进行基准测试：

sysbench oltp_read_write \
  --tables=10 --table-size=1000000 \
  --threads=64 --time=600 \
  --mysql-host=127.0.0.1 --mysql-user=root --mysql-password=… \
  run

首轮跑出 ~1300 TPS，延迟平均 ~18ms。虽然达到了预期，但进一步优化空间仍在。

五、部署中遇到的“坑”与现场解决过程

坑①：SSD 写入延迟偶尔爆表

现象：在高并发插入订单（峰值写入流）时，有时延迟瞬间跳升到 80–100ms，数据库响应变慢。

排查过程：

• 查看 iostat -x 1，发现 SSD 在写入高峰期间 await 上升至 20–30 ms。
• 查看系统 OS 日志，发现 occasional I/O scheduler 重试。
• 进一步看 MySQL 变量 innodb_flush_log_at_trx_commit=1，每次事务提交都 fsync 日志。

方案：采用两步：

• 将 innodb_flush_log_at_trx_commit 临时改为 2，即事务提交后每秒写入一次日志，而不是每次 fsync。适用当天促销高峰时段。
• 将操作系统 I/O 调度器改为 deadline，确认命令 cat /sys/block/nvme0n1/queue/scheduler，并设置 /etc/udev/rules.d/60-ssd-scheduler.rules：
• ACTION=="add|change", KERNEL=="nvme0n1", ATTR{queue/scheduler}="deadline"
• 在 MySQL 中将 innodb_io_capacity_max 提高至 8000，因为 SSD 实测 IOPS 较高，初期 4000 还略保守。

结果：延迟峰值下降至 ~30–40ms，平均延迟 ~9ms，订单写入流畅度显著提升。

坑②：内存压力导致操作系统掉页

现象：在促销节点启动后，系统 free -m 显示 available 内存低于 5 GB，且偶尔系统出现 swap 使用。

排查：

vmstat 1 显示较高 si/s（swap in）值。

查看 MySQL 进程 RES 占用约 70 GB，操作系统 +缓存约 40 GB，剩余约 10 GB。

解决方案：

修改 /etc/sysctl.d/99‑mysqldb.conf：

vm.swappiness = 1
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

将 MySQL 缓冲池 innodb_buffer_pool_size 从 64G 降至 56G，预留约 8G 给 OS 缓存与其他服务。

结果：系统内存可用提升至 ~12 GB，swap 使用消失，系统稳定性提升。

坑③：网络高峰请求延迟与丢包

现象：客户反馈内地用户访问订单提交后页面卡顿，HTTP 响应变慢。监控发现网络丢包率在促销高峰〈0.1%〉但延迟从 ~40 ms飙升至 ~120 ms。

分析：

虽为香港数据中心，但电商促销流量突增导致边缘设备拥堵。

内地回程路由使用普通 BGP，而非 CN2 优化。

解决过程：

与机房网络团队要求切换至 CN2 GIA 优化路由，并启用多条 BGP 备份线路。根据文献，CN2 专线对内地访问延迟/丢包有明显优势。

在服务器端启用 tcp_tw_reuse=1 和 net.ipv4.tcp_mtu_probing=1，并使用 mtr 定期监测网络跳数。

结果：内地用户访问延迟回落至 ~45–55 ms，丢包率下降至几 ×10⁻⁵，用户体验流畅。

六、性能优化深入指南

内核与系统级调优

我在 /etc/sysctl.d/99‑db.conf 中，加入如下关键优化项：

fs.file-max = 1000000
net.core.rmem_max = 134217728
net.core.wmem_max = 134217728
net.core.netdev_max_backlog = 5000
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.ip_local_port_range = 20000 65000

使用 tuned-adm active throughput-performance 时，也手动关闭 CPU 节能 C‑states（intel_idle.max_cstate=1，processor.max_cstate=1）提升响应速度。

磁盘 I/O 调度器设为 deadline，elevator=deadline，并禁用 IRQ 负载均衡，将 nvme0n1 的 interrupt 绑定至 CPU 核 0，为保证 NUMA／内存通道最优。

监控方面，我启动 sar –q 1、iostat –x 1、vmstat 1、pidstat 1，记录每日促销高峰期间系统指标作为基准。

MySQL InnoDB 调优细节

根据 MySQL 官方与 Percona 的建议，结合 SSD 特性，我们进行了如下调优：

• innodb_buffer_pool_size 保持 ~56 GB，也开启 buffer pool instances = 8（每 8 GB 一个实例）以提升并发。
• innodb_flush_method = O_DIRECT_NO_FSYNC 或 O_DIRECT（视内核版本）以减少 fsync 开销。
• innodb_log_file_size 由默认 128M 提升至 2G，日志刷新场景减少。
• innodb_flush_log_at_trx_commit = 2（促销高峰模式）或 = 1（正常模式）灵活切换。
• innodb_io_capacity = 2000、innodb_io_capacity_max = 8000：SSD 具备足够 IOPS，要让 InnoDB 充分利用。
• innodb_read_io_threads = 4，innodb_write_io_threads = 4（允许使用更多内核并行 I/O）。

针对使用 NVMe SSD，禁用 innodb_flush_neighbors，并设 innodb_checksum_algorithm = crc32，减少校验开销。

实例化 SQL 执行优化

对于订单写入表 (orders) 我创建如下 SQL 索引策略：

ALTER TABLE orders 
  ADD INDEX idx_user_created (user_id, created_at),
  ADD INDEX idx_status_updated (status, updated_at);

使用 PREPARE/EXECUTE 方式批量插入，在应用端完成事务合并，每 500 条为批量。

设置 autocommit = 0，在显式 COMMIT 前批量插入，减少事务提交次数。

开启 innodb_doublewrite = ON，用于写入安全，但在 SSD 上可酌情关闭（但出于数据可靠性考虑，本项目保留）。

periodic 执行 OPTIMIZE TABLE orders PARTITION … 每天凌晨执行，避免业务高峰期影响。

七、应用场景与优势回顾

典型应用场景

跨境电商促销主库：要求“高并发写入（订单流）+大量查询（商品/用户/统计）”，香港服务器面向亚太及内地用户。

游戏后端用户数据服务：如游戏启动、排行榜、实时匹配，读写混合、高并发、低延迟。

短视频平台数据库支撑：用户行为日志、播放统计、推荐系统实时更新，需要较大内存、高 I/O SSD 支撑。

本配置的优势

单 S CPU +128 GB 内存足够当前规模，未来如升级可扩 2 S 或 Memory 扩容。

NVMe SSD 提供了高随机 IOPS、低延迟，适合读写密集型数据库负载。

香港机房 + CN2 优化线路 + BGP 多线，确保内地访问体验佳。

RHEL 8 系统与 MySQL 8、InnoDB 调优成熟，可支撑运维团队日常管理。

成本控制合理：比多节点集群初期投入少，但已具备高并发支撑能力。

八、常见问题（FAQ）及建议

九、总结与未来规划

在香港机房亲自完成这台部署后，我深刻体会到：硬件选型+系统调优+网络优化三位一体才是真正能支撑跨境电商／游戏／短视频类数据库系统的成功关键。选择 Intel Xeon Gold 6230 + 128 GB 内存 + 1 TB NVMe SSD 的组合，在 RHEL 8 系统上、配合 MySQL 8.0 InnoDB 引擎、再加上网络 CN2 优化路线，最终实现了“高并发写入＋低延迟查询＋稳定运行”三个目标。

未来，我计划：

• 将存储升级至 2 TB NVMe SSD，并划分专用日志盘／数据盘；
• 引入读写分离、主从复制＋热备库架构，作为扩展方案；
• 增加监控 Prometheus ＋ Grafana Dashboard，实时观察 I/O／内存／连接／网络指标；
• 在促销高峰启动预热模式（将 innodb_flush_log_at_trx_commit 切至 2），结束后恢复严格模式