技术选型与解决方案设计

1. 简历关联点

技术选型是架构师面试高频题。面试官不是想听“我会 Redis（远程字典服务）、MySQL（关系型数据库）、MQ（消息队列）”，而是想听你为什么选、什么时候不用、风险是什么、怎么迁移、如何兜底。

本模块用于准备：

• 数据库、缓存、MQ（消息队列）、搜索、时序、对象存储的选型。
• 单体、微服务、分库分表、读写分离、异步化的方案选择。
• 高可用、高并发、高一致性场景下的解决方案。
• 架构方案如何写成能落地的工程计划。

2. 技术选型主线

技术选型建议按八个维度回答：

一句话模板：

我选型时不会只看性能指标，而会结合业务一致性要求、数据规模、团队运维能力和迁移成本。优先选团队能掌控、满足当前规模、支持未来演进的方案。

3. 常见组件选型

3.1 MySQL（关系型数据库）还是 NoSQL（非关系型数据库）

面试表达：

订单、支付、库存这类核心交易数据，我优先放 MySQL（关系型数据库），因为需要事务、约束和审计；物流轨迹和搜索可以同步到 Elasticsearch（搜索引擎）；报表分析可以进入 ClickHouse（列式数据库）；不是为了新技术而拆数据源。

热门面试题

1. 问题（基础题）：为什么订单主数据不建议直接放 Elasticsearch（搜索引擎）？

   • 考点：主数据、事务、一致性。
   • 回答思路：Elasticsearch（搜索引擎）适合检索，不适合作为强一致交易主库；订单主数据要保证事务、约束和审计。
   • 进阶追问：搜索数据和主库不一致怎么办？

2. 问题（原理题）：ClickHouse（列式数据库）为什么适合报表？

   • 考点：列式存储、压缩、聚合。
   • 回答思路：列式存储只读取查询需要的列，压缩率高，适合大批量聚合分析。
   • 进阶追问：为什么不适合高频事务写入？

3. 问题（项目追问题）：跨境物流轨迹怎么选存储？

   • 考点：写入量、查询模式、归档。
   • 回答思路：近期轨迹可放 MySQL（关系型数据库）或 MongoDB（文档数据库）支撑查询，搜索场景同步 Elasticsearch（搜索引擎），历史轨迹归档到低成本存储。
   • 进阶追问：轨迹重复上报怎么去重？

3.2 Redis（远程字典服务）用还是不用

Redis（远程字典服务）适合低延迟、高频访问、临时状态、分布式协调的场景，但不能随便替代数据库。

热门面试题

1. 问题（基础题）：Redis（远程字典服务）适合做什么？

   • 考点：缓存、计数、锁、延迟队列。
   • 回答思路：适合低延迟访问、热点缓存、短期状态、原子计数、分布式锁和 ZSet（有序集合）延迟队列。
   • 进阶追问：Redis（远程字典服务）宕机会不会影响主链路？

2. 问题（原理题）：为什么 Redis（远程字典服务）不能作为所有数据的事实来源？

   • 考点：持久化、事务、审计、一致性。
   • 回答思路：Redis（远程字典服务）虽然有持久化，但不适合承载所有强一致和审计要求，核心交易数据仍要落数据库。
   • 进阶追问：库存预扣用 Redis（远程字典服务）后如何和数据库对齐？

3. 问题（项目追问题）：库存防超卖如何组合 Redis（远程字典服务）和 MySQL（关系型数据库）？

   • 考点：缓存加速、数据库兜底、补偿。
   • 回答思路：Redis（远程字典服务）用于热点预扣和削峰，MySQL（关系型数据库）用条件更新保证最终不超卖，异步对账修正异常。
   • 进阶追问：Redis（远程字典服务）扣成功但数据库失败怎么办？

3.3 MQ（消息队列）选型

面试表达：

如果是物流轨迹或日志流，我倾向 Kafka（分布式日志消息系统）；如果是订单支付这类需要事务消息、延迟消息和业务可靠性的场景，我更倾向 RocketMQ（分布式消息队列）；如果是路由模型复杂、存量系统集成，RabbitMQ（消息队列）也有价值。

热门面试题

1. 问题（基础题）：为什么要引入 MQ（消息队列）？

   • 考点：削峰、解耦、异步、最终一致性。
   • 回答思路：MQ（消息队列）用于削峰、解耦和异步处理，也能承载最终一致性事件流。
   • 进阶追问：引入 MQ（消息队列）会带来什么复杂度？

2. 问题（原理题）：Kafka（分布式日志消息系统）和 RocketMQ（分布式消息队列）怎么选？

   • 考点：吞吐、事务、业务消息。
   • 回答思路：Kafka（分布式日志消息系统）强在高吞吐日志流，RocketMQ（分布式消息队列）更适合交易业务消息和事务消息。
   • 进阶追问：顺序消息怎么保证？

3. 问题（项目追问题）：支付成功后通知库存、物流、积分如何设计？

   • 考点：事件驱动、幂等、补偿。
   • 回答思路：支付状态落库后发领域事件，下游各自消费，消费者幂等，失败进入重试和死信，最终通过对账补偿。
   • 进阶追问：消息发出失败怎么办？

4. 解决方案设计模板

4.1 通用方案结构

背景：业务问题和现状
目标：功能目标和质量目标
约束：规模、成本、团队、时间
方案：核心架构和技术选型
链路：主流程、异常流程、补偿流程
风险：一致性、性能、可用性、安全、成本
观测：日志、指标、链路、告警
演进：第一阶段、第二阶段、长期方案

4.2 技术选型决策矩阵

5. 架构图与流程图

5.1 技术选型流程

flowchart TD
    A["业务问题"] --> B["数据规模和峰值"]
    B --> C["一致性要求"]
    C --> D["团队能力和运维成本"]
    D --> E["候选方案"]
    E --> F["风险评估"]
    F --> G["阶段性落地"]
    G --> H["监控验证和演进"]

6. 项目落地话术

6.1 分库分表选型话术

我不会一开始就分库分表。先看数据量、增长速度、查询模式和瓶颈。如果主要是慢查询，先做索引、SQL（结构化查询语言）优化、冷热分离和归档；如果单表数据和写入压力确实超过单库承载，再考虑分库分表。分片键要优先贴近核心查询，比如订单按用户或商户，库存按 SKU（库存单位）和仓库。还要提前考虑跨库分页、全局 ID（标识）、扩容迁移和数据校验。

6.2 MQ（消息队列）最终一致性话术

我会先让本地事务保证本服务状态正确，再通过可靠消息驱动下游。消息可能重复、延迟、乱序，所以消费者必须幂等，状态流转要有版本或状态机。失败消息进入重试和死信，最终通过补偿任务和对账保证业务闭环。

7. 高频面试题与追问

1. 问题：你如何做技术选型？

   • 回答思路：按业务目标、规模、一致性、性能、成本、团队能力和演进风险做矩阵，不从技术偏好出发。

2. 问题：如何判断该不该引入 MQ（消息队列）？

   • 回答思路：当需要削峰、解耦、异步或最终一致性时引入；同时评估可靠性、幂等、积压和运维成本。

3. 问题：什么时候不该用微服务？

   • 回答思路：业务边界不稳定、团队规模小、部署治理能力不足、事务强耦合时，不适合过早拆微服务。

8. 本模块复习清单

• 能用八维度讲技术选型。
• 能解释 MySQL（关系型数据库）、Redis（远程字典服务）、MQ（消息队列）、Elasticsearch（搜索引擎）、ClickHouse（列式数据库）怎么选。
• 能把技术选型讲成业务目标和架构取舍。
• 能说明为什么不用某个技术。
• 能用决策矩阵回答方案对比题。

9. 精通级分册入口与学习路线

根文档完整保留既有正文，作为兼容入口；本节只追加分册导航、事实边界和复核统计，不以导航替换原有学习内容。原正文收口基线的 SHA-256（安全散列算法）为 4bc464a4bde2711b5b1d359475dee9eafac48e0a25b2375414a8aa783668d54f。

9.1 七篇分册与七张正式图

七张正式图均由一份 PlantUML（统一建模语言）源文件和一张 PNG（便携式网络图形）渲染图组成；源文件与渲染图分别按 puml 和 png 扩展名统计。

9.2 事实边界、推荐顺序与快速复习

• E0（待核对）：未找到源码、运行记录或原始业务凭证；只能说明待核对项和核对动作。
• E1（源码与可复现证据）：可由源码、配置、脚本、原始事件或可复现实验直接核验的事实。
• E2（已有材料映射）：来自现有简历、项目材料或已成稿模块的可追溯映射，不外推为新的线上结论。
• E3（演练证据）：用于复算机制、容量、失败窗口或验收方法的假设输入与演练结果，不代表真实生产指标、服务等级协议或项目收益。

推荐首次学习顺序为 00 -> 01 -> 02 -> 03 -> 04 -> 05 -> 06：先固定工作负载与证据边界，再完成候选淘汰、风险实验、自建采购比较、退出迁移与方案验收，最后用项目口述和综合题检验表达。快速复习时，从本根的“技术选型主线”“解决方案设计模板”和“项目落地话术”恢复框架；面试前压缩练习时，先阅读 00 分册 的输入边界，再练习 06 分册 的口述与排障题。

9.3 分册统计与复核口径

统计范围仅为 51-技术选型与解决方案设计/ 下的 00-06 七篇 Markdown（标记语言）分册，不含本根兼容正文。知识标记按既有 HTML（超文本标记语言）注释计数；六字段题要求“问题、考点、回答思路、详细答案、进阶追问、进阶回答”六个字段在同一知识题块各恰好一次；口述答案按相应字段计数。Mermaid（图表语法）按围栏计数，时序图按围栏内 sequenceDiagram 计数；标准表按表头紧随 Markdown（标记语言）分隔行计数；数据演绎按 E3（演练证据）演绎标题计数；图资源按目录内 puml/png 文件计数。

复核结果：interview_kb_audit 对本模块全部 Markdown（标记语言）文件审计为 0 个问题；固定 mmdc（Mermaid 命令行工具） 11.4.2 对七篇分册 84 张 Mermaid（图表语法）图真实渲染通过 84 / 84，连同本根 1 张图后为全模块 85 / 85，输出均非空；7 组 PlantUML（统一建模语言）源文件与 PNG（便携式网络图形）渲染图均非空。