设计一个支持百万级行业客户（广告主、商家）的运营管理系统，需要支持实时数据查询、客户画像分析、活动配置等功能，请描述系统架构和关键技术选型？
答案
1) 【一句话结论】
采用微服务架构，结合分库分表（MySQL）、缓存（Redis）、消息队列（Kafka）及Saga事务等分布式技术，构建高并发、低延迟的运营管理系统。在合理硬件资源（如X台服务器、Y Gbps网络带宽）下，通过读写分离、缓存预热、异步处理等策略，支撑百万级客户实时数据查询与活动配置的稳定性和数据一致性。
2) 【原理/概念讲解】
老师口吻：咱们先讲核心架构思路——微服务。把系统拆成“客户管理服务”“数据查询服务”“活动配置服务”“客户画像分析服务”“消息通知服务”，每个服务只负责单一功能，像公司不同部门各司其职，这样能提高可维护性和扩展性，比如新增活动配置功能，只需修改活动配置服务，不影响其他服务。
接着是分库分表：当客户数据量达百万级，单个MySQL库压力过大，采用“分库分表”策略。分库：按客户ID哈希取模（如客户ID % 8，分配到库0-7），避免热点库（比如所有客户ID以0结尾的都去库0）；分表：按时间维度（如按月分表，表名格式customer_202401），解决单表数据量过大问题（比如2024年1月的数据都在customer_202401表中）。新增客户时，根据ID哈希值分配到对应库和表，确保数据分布均匀。
然后是Saga事务：处理跨服务数据一致，比如活动配置流程：1. 活动配置服务接收请求，写入MySQL分库分表（活动表），并发布Kafka消息（topic:activity_create）；2. 客户管理服务消费Kafka消息，更新客户画像中的活动参与状态（如标记为“待参与”）；3. 若某步失败（比如客户管理服务更新失败），通过补偿事务回滚（比如删除活动配置记录，或重置客户状态），确保最终一致。
缓存用Redis存储热点数据（如客户基本信息、活动配置状态），设置随机过期时间（TTL随机300-600秒），防缓存雪崩；对查询不存在的客户ID，先通过布隆过滤器预过滤（判断是否在数据库中），避免查询数据库（防穿透）。消息队列用Kafka处理异步任务（如活动通知），解耦服务，比如活动配置成功后，消息通知服务消费消息推送通知，不会阻塞主流程。
3) 【对比与适用场景】
| 技术方案 | 定义 | 特性 | 使用场景 | 注意点 |
|---|---|---|---|---|
| MySQL（分库分表） | 关系型数据库，支持事务，通过分库分表扩展 | 高一致性，强事务，分库分表后读写分离 | 存储客户核心数据（账户、交易、活动配置） | 需设计分库分表规则，冷启动时预加载数据（分批次迁移，验证一致性） |
| MongoDB | NoSQL文档型数据库 | 弹性存储，灵活查询，无事务 | 存储客户画像分析的非结构化数据（如购买行为日志） | 不支持复杂事务，数据迁移需注意模式兼容（如字段变更） |
| Redis | 内存数据库 | 高速读写，支持数据结构（Hash, List） | 缓存热点数据（客户信息、活动状态） | 内存有限，需持久化（RDB/AOF）；缓存雪崩需防护（随机TTL） |
| Kafka | 分布式消息队列 | 高吞吐，持久化，容错 | 异步处理活动配置通知、日志收集 | 需考虑消息积压（设置消费组，防消息丢失），消息确认机制（ACK） |
4) 【示例】
- 活动配置API请求示例：
POST /api/v1/activities
{
"activity_id": "ACT-2024-001",
"name": "春季促销活动",
"target_customers": ["user_001", "user_002"],
"start_time": "2024-03-15T00:00:00Z",
"end_time": "2024-04-15T23:59:59Z"
}
- 系统处理流程：
- 活动配置服务接收请求，写入MySQL分库分表（活动表），并发布Kafka消息（topic:activity_create）。
- 客户管理服务消费Kafka消息，更新客户画像中的活动参与状态（如标记为“待参与”）。
- 消息通知服务消费Kafka消息，向目标客户推送活动通知（短信/推送）。
- 数据查询服务通过Redis缓存活动配置状态（如活动详情、参与状态），实时查询活动信息。
- 分库分表数据迁移（冷启动）：
- 备份数据库数据。
- 按库分批次迁移数据（如库0先迁移，验证数据一致性后，再迁移库1）。
- 迁移后，启动服务，通过压力测试验证性能（如并发查询、写入）。
5) 【面试口播版答案】
面试官您好，针对百万级行业客户运营管理系统，我设计的核心是微服务架构，将系统拆分为客户管理、数据查询、活动配置等独立服务，确保高内聚低耦合。关键技术选型上，核心数据用MySQL分库分表（客户ID哈希分库，按月分表），缓存用Redis存储热点数据（如客户信息、活动状态），消息队列用Kafka处理异步活动通知（如推送）。通过Saga事务保证数据一致性，比如活动配置后，先发布Kafka消息再更新客户状态，若某步失败则触发补偿事务回滚。缓存策略采用随机TTL（300-600秒）防雪崩，布隆过滤器预过滤防缓存穿透。整体架构通过负载均衡、读写分离、多机房部署，在合理硬件资源（如X台服务器、Y Gbps网络带宽）下，支撑百万级并发，满足实时数据查询和活动配置需求。
6) 【追问清单】
- 问：Saga模式中，补偿事务的触发条件和具体实现步骤是怎样的？
回答要点：补偿事务由定时任务或消息触发（如超时未完成则启动），具体步骤包括回滚操作（如删除活动配置记录，或重置客户活动状态），确保数据最终一致。 - 问：分库分表后，新增客户时如何分配到对应库？数据迁移的具体步骤？
回答要点：新增客户时，根据ID哈希值（如ID%8）分配到对应库；数据迁移时，分批次迁移（如按库、按表），冷启动前预加载数据，验证数据一致性（如校验数据总数、关键字段）。 - 问：缓存雪崩或穿透如何应对？具体措施？
回答要点：缓存雪崩用随机过期时间（TTL随机300-600秒），穿透用布隆过滤器预过滤，并设置缓存空值（如“null”），避免查询数据库。 - 问：假设硬件资源有限，如何优化系统性能？比如数据库连接池、缓存容量？
回答要点：数据库连接池设置合理最大连接数（如1000），缓存容量根据热点数据量（如1000万条）配置，结合LRU淘汰策略；同时优化查询语句（如索引优化），减少分库分表查询次数。
7) 【常见坑/雷区】
- 坑1：忽略数据一致性实现，只说微服务，未提及Saga或两阶段提交，导致活动配置后数据不一致。
- 坑2：分库分表策略模糊，比如只说分库分表，未说明哈希分库、时间分表的具体规则，以及冷启动和数据迁移方案。
- 坑3：缓存策略不完善，未考虑雪崩、穿透，导致系统在高峰期缓存失效，查询数据库压力过大。
- 坑4：绝对化表述，如“支撑百万级并发”，未说明假设条件（如硬件资源、网络延迟），可信度不足。
- 坑5：技术选型与业务场景脱节，比如用NoSQL存储核心交易数据，导致事务无法保证，影响数据一致性。