请分享一个你参与过的系统高并发或高可用改造的项目经验，包括遇到的挑战、解决方案以及最终效果。

1) 【一句话结论】在期货交易系统订单处理模块，通过分布式缓存预热、消息队列解耦、数据库分库分表及负载均衡，将系统峰值QPS从5000提升至15000（生产环境1000并发测试），故障恢复时间从30分钟缩短至5分钟（主从切换时缓存集群同步），高并发与高可用能力显著提升。

2) 【原理/概念讲解】高并发指系统处理大量请求的能力，核心指标为QPS（每秒查询数）与响应时间；高可用指故障时仍提供服务，核心指标为故障恢复时间与SLA。改造技术及类比：

• 分布式缓存（如Redis）：将热点数据（如用户余额）从数据库转移至缓存，减少数据库压力，类比“数据缓冲池”，快速响应高频查询。
• 消息队列（如Kafka）：解耦业务流程（如订单与通知），异步处理，类比“任务缓冲区”，避免业务阻塞。
• 负载均衡（如Nginx）：分发请求至多实例，避免单点故障，类比“请求分发器”，合理分配负载。
• 数据库分库分表：水平扩展数据库，按业务分库（交易库、账户库），分表规则按用户ID哈希，类比“数据仓库扩容”，避免单表压力。

3) 【对比与适用场景】

• 缓存预热 vs 热点预加载：
  • 定义：缓存预热是系统启动前预加载数据；热点预加载是运行时动态加载。
  • 特性：预热需从数据库读取最新数据；预加载实时加载。
  • 使用场景：系统启动或高峰前提升命中率。
  • 注意点：预热需避免数据不一致，预加载需考虑实时性。
• 消息队列持久化 vs 非持久化：
  • 定义：持久化写入磁盘，不丢失；非持久化内存存储，可能丢失。
  • 特性：持久化需配置日志保留时间，避免磁盘耗尽；非持久化成本低。
  • 使用场景：金融场景（如通知）需保证不丢失。
  • 注意点：持久化需监控磁盘空间，非持久化需接受消息丢失风险。
• 数据库分库分表（热点表处理）：
  • 定义：按业务分库，热点表（高频访问）放在主库或独立库。
  • 特性：水平扩展，避免单表压力；热点表不参与分库。
  • 使用场景：数据量大的系统，高频访问表。
  • 注意点：需分析业务访问模式，避免热点表分库导致查询慢。
• 负载均衡算法（轮询 vs 加权轮询）：
  • 定义：轮询均匀分发；加权轮询根据实例负载调整。
  • 特性：轮询简单，加权轮询动态。
  • 使用场景：多实例部署，请求量大。
  • 注意点：结合实例CPU/内存负载动态调整，避免资源不均。

4) 【示例】：假设项目为期货交易系统订单处理模块，原系统为单体架构，订单提交后直接查询数据库。改造步骤：

• 缓存预热：系统启动时，脚本将用户余额等热点数据加载到Redis，伪代码：

  for user_id in 用户列表:
      balance = 数据库查询(user_id)  # 获取最新余额
      redis.set(f"user:{user_id}", balance, 300)  # 300秒过期
  

• 消息队列持久化：Kafka配置log.retention.hours=48，订单处理模块将通知消息写入持久化主题（如order_notify），通知模块异步消费。
• 数据库分库分表：交易库、账户库，用户余额表（热点表）放在主库，分表规则：按用户ID哈希（如user_balance_0、user_balance_1）。
• 故障恢复：数据库主从切换时，缓存集群（Redis集群）通过哨兵自动切换，故障恢复时间5分钟（原30分钟）。

5) 【面试口播版答案】
面试官您好，我分享一个期货交易系统订单处理模块的高并发改造项目。当时系统在交易高峰期（如开盘），峰值QPS约5000，用户下单响应时间超3秒，还偶发超时。挑战包括用户余额热点查询压力、订单与通知业务流程耦合、单体架构单点故障。解决方案：首先，通过Redis缓存预热脚本，预加载用户余额等热点数据到缓存，提升缓存命中率；其次，引入Kafka持久化消息队列解耦订单处理与通知，避免业务阻塞；再次，部署3个实例并配合Nginx负载均衡分发请求；最后，数据库按业务线分库，将高频访问的用户余额表放在主库，避免分库导致查询效率下降。最终效果：生产环境测试，1000并发下QPS提升至15000（比改造前提升3倍），响应时间缩短至0.5秒内，故障恢复时间从30分钟缩短至5分钟（比如主从切换时，缓存集群自动同步，恢复快）。

6) 【追问清单】

• 问：如何保证缓存预热时数据的一致性？
  答：预热脚本从数据库读取最新数据，避免缓存与数据库数据不一致；同时设置合理过期时间（如300秒），或订单修改时同步更新缓存。
• 问：消息队列持久化如何处理消息积压？
  答：通过监控队列长度，当积压超阈值时，动态扩容消费者实例，或调整生产者速率，避免消息堆积。
• 问：数据库分库分表后，如何避免热点表查询效率下降？
  答：分析业务访问模式，将高频访问的热点表（如用户余额）放在独立的主库或原库，不参与分库分表，确保查询效率。
• 问：缓存雪崩的应对措施是什么？
  答：设置随机过期时间（如EXPIRE 3600 + random(0, 300)），避免大量缓存集中过期，导致服务压力激增。

7) 【常见坑/雷区】

• 坑1：缓存预热未考虑数据更新，导致缓存数据过期。避免：预热后设置合理过期时间，或订单修改时触发缓存更新（如更新用户余额时，同时更新Redis缓存）。
• 坑2：消息队列持久化导致磁盘空间耗尽。避免：配置合适的日志保留时间（如48小时），并监控磁盘使用情况，及时清理过期日志。
• 坑3：数据库分库分表规则不合理，导致热点表查询慢。避免：在分库分表前，分析业务访问模式，明确哪些表是热点表，避免将热点表分库或分表。
• 坑4：负载均衡策略不当，导致请求分发不均。避免：选择轮询或加权轮询算法，并结合实例的CPU、内存负载动态调整，确保资源均衡。
• 坑5：缓存穿透未处理，导致数据库压力激增。避免：使用布隆过滤器拦截无效查询（如用户ID不存在），或设置缓存空值并设置过期时间（如1分钟），避免恶意请求穿透。