我是一名在吉隆坡创业五年的后端工程师。几个月前，我们为一个本地大型电商平台部署了一个促销活动系统。原本预期峰值 QPS（每秒查询数）为1万，但活动上线首小时就飙到了3.5万，写入队列几近崩溃，更糟的是，部分数据在服务重启后竟然丢失了。那一次，我们被真实世界狠狠上了一课：“高并发写入”场景下，没有良好的数据持久化优化手段，光靠冗余根本救不了命。
从那以后，我着手重新设计我们的服务器架构，尤其是部署在马来西亚的数据中心的那几台主写入服务器。我会在这篇文章里，详细分享我们如何一步步进行持久性优化、性能提升与架构重构的全过程，希望给面对类似困境的开发者一些实用的参考。
一、目标与挑战
在马来西亚数据中心部署的写入服务需要满足如下几个核心需求：
- 高并发支持： QPS≥30,000，写操作TPS（每秒事务数）稳定在15,000以上；
- 高可用性： 单点故障不会导致数据丢失；
- 强持久性： 在系统重启、意外宕机情况下，已提交数据不会丢失；
- 低延迟写入： 单次写入延迟不超过5ms；
- 符合本地部署政策： 所有数据物理落地马来西亚。
二、服务器选型与基础设施部署
我们部署在Cyberjaya的数据中心，主要选择了马来西亚本地云服务商 AIMS Data Centre 的裸金属方案和阿里云国际版（马来西亚Region）组合部署。
硬件规格（主写入服务器）：
- CPU： AMD EPYC 7742（64 核心，128线程）× 1
- 内存： 512 GB DDR4 ECC
- 存储：
- Primary：Intel P5800X 3.2TB NVMe（用于WAL和热数据区）
- Secondary：Samsung PM9A3 7.6TB（大容量日志冷存）
- 网络： 25 Gbps 专线，双冗余链路
- RAID配置： 使用ZFS + RAIDZ2保证冗余与校验
三、系统架构与中间件选型
我们最终选择了以 PostgreSQL + Kafka + Ceph 为核心的写入持久化架构：
- PostgreSQL 15：主存储与事务支持；
- Kafka 3.x：作为写入缓冲与异步任务管道；
- Ceph Octopus：分布式对象存储，存放批量归档数据；
- Patroni + etcd：实现PostgreSQL HA（高可用性）；
- Zookeeper + Kafka MirrorMaker：支持多区域数据同步与灾备。
组件部署图（简化）：
用户请求 -> Nginx 网关 -> Kafka（写入管道） -> PostgreSQL + Ceph
|
--> Kafka Consumer 批处理 -> Ceph
四、写入持久性优化方法详解
1. PostgreSQL 层优化
- 启用 wal_compression = on：压缩WAL（Write-Ahead Logging）日志，减少磁盘压力；
- 配置 synchronous_commit = remote_apply：确保副本节点已持久化才返回成功；
- 写入频繁表启用 UNLOGGED 切换策略：在某些缓存表上使用临时表替代持久化写入，减轻I/O负担；
- pg_partman 自动分区表策略：按时间分区日志数据，提高写入效率；
- 启用 pgbackrest + Ceph RGW远程备份：异步增量备份保障安全；
2. Kafka 持久化策略
- acks=all 配置开启：确保数据写入所有ISR副本才确认；
- Kafka 日志写入磁盘使用P5800X：超低延迟NVMe大幅提升吞吐；
- 配置 log.flush.interval.messages = 1 强制每条消息立即刷盘（只用于核心数据）；
- 采用Kafka事务生产者（enable.idempotence=true） 防止重复写入；
3. Ceph 归档持久化
- 对象存储桶策略配置：versioning=on；
- 配置 bluestore_cache_size 动态调整缓存，提升冷热数据处理；
- 对老数据进行RADOS Gateway Bucket Sharding 优化查询性能与维护性。
五、数据支撑与性能验证
测试环境：
- 模拟10,000并发客户端持续写入60分钟；
- 单条数据写入大小：1KB
- 验证维度：TPS、延迟、数据一致性、重启后丢失率
测试结果（关键指标）：
六、运维实践与建议
- 每天对WAL日志进行压缩归档并上传Ceph；
- 定时重启非主写入节点测试恢复能力；
- Kafka与Postgres均开启Prometheus监控，结合Grafana设置告警；
- 每月进行全节点“模拟灾难演练”，验证持久性及重建能力；
- 日志监控策略：关键写入失败、异步消费者延迟 >10s 自动触发回滚机制。
我的这套方案经历了数轮压测与实战验证，目前稳定支撑多个高并发写入场景，包括支付订单系统、视频上传元数据记录等。虽然成本相对较高，但在可用性、持久性和扩展性上达到了我们预期的水准。
