在投放系统中，如何处理海量广告请求和用户行为数据？请说明数据库选型（如MySQL、Redis、MongoDB）以及分库分表、索引优化策略，并举例说明具体实施步骤。
答案
1) 【一句话结论】：在投放系统中，通过分层数据库架构（Redis缓存+MySQL主从+MongoDB日志），结合分库分表（按广告ID/用户ID拆分）和索引优化（复合索引、覆盖索引），实现高并发请求处理与海量用户行为数据存储，核心是平衡性能与数据一致性，通过缓存加速热点访问，关系型数据库保障核心数据一致性，文档型数据库灵活存储行为日志。
2) 【原理/概念讲解】：面试官问如何处理海量广告请求和用户行为数据，本质是解决高并发读写与海量数据存储的矛盾。
- 缓存（Redis）：像超市的快速货架，存储热点数据（如广告位实时库存、热门广告信息），通过内存存储实现亚毫秒级访问，缓解数据库压力。
- MySQL（关系型数据库）：像仓库，存储结构化数据（如广告主信息、用户画像、投放策略），支持事务（ACID），保证数据一致性，通过主从复制实现读写分离，提升并发能力。
- MongoDB（文档型数据库）：像档案室，存储非结构化或半结构化数据（如用户点击、曝光、转化行为日志），文档结构灵活，适合存储行为序列，便于后续分析。
- 分库分表：为解决单库单表性能瓶颈，通过水平拆分（如按广告ID分库、按用户ID分表），将数据分散到多个节点，提升查询与写入性能。
- 索引优化：通过创建合适的索引（如复合索引、覆盖索引），减少数据库扫描范围，加快查询速度。
3) 【对比与适用场景】：
| 数据库类型 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| Redis | 内存数据库，支持键值、列表等 | 高并发读写、低延迟、支持事务（部分）、持久化 | 缓存热点数据、实时计数、会话管理 | 内存依赖，需定期持久化，不适合复杂查询 |
| MySQL | 关系型数据库，遵循ACID | 事务支持、主从复制、索引优化 | 核心业务数据（广告主、用户画像、策略表） | 单表数据量过大时性能下降，需分库分表 |
| MongoDB | 文档型数据库，BSON存储 | 文档结构灵活、支持聚合查询、副本集 | 用户行为日志、点击流数据、非结构化数据 | 查询复杂度较高时性能可能下降，索引维护成本高 |
4) 【示例】：以广告请求处理为例，分库分表和索引优化。
- 分库分表：广告请求表（ad_request）按广告ID（ad_id）哈希分库（库1存ad_id 1-1000，库2存1001-2000），按用户ID（user_id）范围分表（表1存user_id 1-1000，表2存1001-2000）。
- 索引优化：在ad_request表创建复合索引（ad_id, user_id, request_time），用于快速查询最近请求；用户行为表（user_action）创建索引（user_id, action_time, action_type），支持按用户ID和事件时间查询行为序列。
- 伪代码（MySQL查询）：
SELECT * FROM ad_request WHERE ad_id = 101 AND user_id = 102 AND request_time > NOW() - INTERVAL 1 MINUTE ORDER BY request_time DESC LIMIT 10;（索引覆盖查询，无需回表）。
5) 【面试口播版答案】：在投放系统中处理海量广告请求和用户行为数据，核心是构建分层数据库架构并优化存储策略。首先，缓存层用Redis存储热点数据（如广告位实时库存、热门广告信息），通过内存访问实现亚毫秒级响应，缓解数据库压力。然后，核心业务数据用MySQL主从复制，存储广告主信息、用户画像、投放策略等结构化数据，通过事务保证数据一致性，并按广告ID分库、按用户ID分表，水平拆分数据，提升并发能力。对于用户行为日志，用MongoDB存储点击、曝光、转化等非结构化数据，文档结构灵活，便于后续分析。具体优化：在MySQL中为广告请求表创建复合索引（ad_id, user_id, request_time），用于快速查询最近请求；在MongoDB中为用户行为表创建索引（user_id, action_time, action_type），支持按用户ID和事件时间查询行为序列。分库分表时，按ad_id哈希分库、按user_id范围分表，避免热点数据集中。这样，缓存加速热点访问，关系型数据库保障核心数据一致性，文档型数据库灵活存储行为日志，整体实现高并发处理和海量数据存储。
6) 【追问清单】：
- 问：分库分表时如何处理跨库事务？
回答要点：对于需要跨库的事务，可使用分布式事务（如两阶段提交或SAGA模式），但需权衡性能，对于非强一致性场景，可采用最终一致性（如补偿机制）。 - 问：如何解决缓存雪崩问题？
回答要点：设置缓存过期时间随机化，避免集中过期；或使用分布式锁控制并发写入，或预热缓存。 - 问：索引优化中，复合索引和覆盖索引的区别？
回答要点：复合索引是多个列的组合索引，查询条件包含索引列且顺序正确可利用；覆盖索引是索引包含查询所需的所有列，无需回表，提升性能。 - 问：用户行为数据如何保证数据一致性？
回答要点：通过消息队列（如Kafka）异步写入MongoDB，确保数据最终一致性，或使用事务（但MongoDB事务支持有限，需评估）。 - 问：分库分表后，查询性能如何保障？
回答要点：通过分片路由（如Sharding Key选择，如ad_id或user_id），确保查询数据集中在少数节点，减少跨节点查询；同时优化索引，减少扫描范围。
7) 【常见坑/雷区】：
- 分库分表导致事务跨库，无法保证原子性，需明确业务是否允许最终一致性。
- 索引过多或选择不当，导致写性能下降（如覆盖索引未正确使用）。
- 缓存穿透：空值或不存在数据被频繁请求，需设置缓存空值或布隆过滤器。
- 数据库分片策略不合理，导致热点数据集中，性能反而下降（如按时间范围分片，但热点数据集中在某段时间）。
- MongoDB的聚合查询性能问题，复杂查询需优化索引或分批处理。