数据库OLTP如何应对峰值

在数据库 OLTP（联机事务处理） 场景中，峰值（突发高并发、写入/查询暴涨）是常见的稳定性和性能挑战。应对思路通常从架构、数据库自身、应用层、运维四个维度入手。

一、架构层面（最根本）

1. 读写分离

• 主库负责写，从库负责读
• 峰值多为读多写少时效果明显
• 注意：从库有复制延迟，强一致读需走主库

2. 分库分表（水平拆分）

• 按用户ID、订单ID等维度分片
• 降低单实例数据量和锁竞争
• 常见方案：
  • MySQL：ShardingSphere、MyCat
  • 分布式数据库：TiDB、OceanBase、PolarDB

3. 引入缓存层

• Redis / Memcached 挡在数据库前
• 典型用法：
  • 热点数据缓存
  • 计数器（库存、点赞）
  • 限流计数
• 注意缓存穿透、击穿、雪崩

4. 消息队列削峰填谷

• 写峰值 → MQ（Kafka / RocketMQ）
• 数据库按自身能力消费
• 适合：
  • 订单创建
  • 日志、积分、通知

二、数据库自身优化

1. 索引与 SQL 优化

• 避免全表扫描
• 控制事务大小
• 避免：
  • SELECT *
  • 大事务
  • 锁表操作

2. 连接池与线程控制

• 使用连接池（HikariCP、Druid）
• 控制最大连接数，防止数据库被压垮
• 数据库线程 ≠ 越多越好

3. 参数调优（以 MySQL 为例）

• innodb_buffer_pool_size
• max_connections
• innodb_flush_log_at_trx_commit
• sync_binlog

4. 选择合适的存储引擎与事务隔离级别

• OLTP 通常用 InnoDB
• 隔离级别权衡：
  • RC（读已提交）性能优于 RR
  • 根据业务容忍度选择

三、应用层策略

1. 限流与降级

• 限流：
  • 令牌桶 / 漏桶
  • 网关层限流
• 降级：
  • 非核心功能关闭
  • 返回缓存旧数据

2. 请求合并与异步化

• 批量写（batch insert）
• 异步日志、统计
• 前端合并请求

3. 热点数据处理

• 热点行（如爆款商品）：
  • 拆分成多行（库存分段）
  • 本地缓存 + 延迟扣减

四、运维与容量保障

1. 弹性扩容

• 云数据库：只读副本、自动扩容
• 容器化 + K8s 水平扩展

2. 压测与容量规划

• 峰值预估（历史 + 业务增长）
• 全链路压测
• 设定水位线（如 70% CPU）

3. 监控与自动防护

• 监控：QPS、TPS、慢 SQL、锁等待
• 自动熔断、慢 SQL kill

五、典型峰值应对组合（示例）

电商秒杀：

• Redis 预扣库存
• MQ 异步下单
• 分库分表
• 限流 + 降级
• 数据库只处理最终一致写

金融交易：

• 强一致主库
• 读写分离只读校验
• 水平分片
• 严格事务控制

如果你有具体场景（如 MySQL / PostgreSQL / 分布式数据库、秒杀、账务、IoT），我可以给更针对性的方案。