高并发彩票系统MySQL投注限额校验性能优化求助

核心优化思路 #

核心问题是实时校验号码累计投注量的性能瓶颈，需从「数据存储层」和「业务逻辑层」双维度切入，减少对MySQL的依赖，提升并发处理能力。

具体优化方案 #

1. 引入内存缓存层（首选方案） #

• 将68000条号码的Draw+Game+Number作为唯一键，把对应的accumulated和limit数据全量加载到Redis哈希表，结构示例：

  # 哈希表key格式：lottery:limit:{Draw}:{Game}:{Number}
  HSET lottery:limit:01:16:10 accumulated 70000 limit 75000
  HSET lottery:limit:02:17:0102 accumulated 65000 limit 60000
  

• 新投注校验时，直接调用Redis的HMGET查询累计值，判断是否超限，响应时间达毫秒级，完全支撑高并发场景。
• 数据同步策略：
  • 定时同步：每分钟从MySQL视图全量同步数据到Redis（单日投注量变化渐进，分钟级延迟可接受）；
  • 实时同步：每笔成功投注后，用HINCRBY更新对应号码的accumulated值，保证数据实时性。

2. 预计算物化视图替代普通视图 #

• MySQL普通视图是虚拟表，每次查询都会重新关联两张交易表，性能极差。改用物化视图（MySQL 8.0+原生支持，或自定义定时任务实现）：
  • 创建物化表lottery_number_limit，结构与原视图一致；
  • 编写定时任务（每10-30秒执行一次）：INSERT INTO lottery_number_limit SELECT * FROM 原视图 ON DUPLICATE KEY UPDATE accumulated=VALUES(accumulated)，将视图结果持久化到物理表；
  • 给物化表的Draw+Game+Number组合字段创建唯一索引，查询时直接走索引，性能比普通视图提升10倍以上。

3. 源交易表索引与分表优化 #

• 若必须查询源交易表，先给两张交易表的Draw、Game、Number字段创建联合索引，避免全表扫描；
• 按Draw（开奖场次）分表，10个场次对应10张交易分表，查询时仅访问对应场次的分表，缩小锁范围与数据量；
• 确保查询和更新操作命中索引，让MySQL自动使用行级锁，避免表锁阻塞并发请求。

4. 本地缓存+批量查询兜底 #

• 在应用服务器本地用Guava Cache或Caffeine缓存热门号码（如累计投注量接近限额的号码）的限额数据，减少远程请求；
• 对低频号码采用批量查询Redis/物化表的方式，降低单次请求的IO开销；
• 若出现缓存击穿，直接降级到查询物化表，避免系统雪崩。

方案选型建议 #

• 追求极致性能选内存缓存层，适配高并发场景；
• 依赖MySQL生态选物化视图，实现成本低；
• 源交易表数据量极大时选分库分表，从根源解决数据瓶颈。

内容的提问来源于stack exchange，提问作者Jose Manuel Gonzalez