架构师面试知识点整理
一、正在做的项目介绍及核心重点
（一）项目基础信息
项目名称：[可替换为实际项目名，如：电商全链路中台系统、金融风控平台、政企数字化协同平台、SaaS服务管理平台]
业务领域：[如：B2C电商、跨境支付、政务审批、企业级运维、直播互动]
项目周期：XXXX年XX月 - 至今（持续迭代优化阶段）
担任角色：技术架构师/核心架构设计负责人
（二）项目背景与核心目标
原有系统采用单体架构，随着业务规模扩张，逐渐暴露出性能瓶颈突出、迭代效率低下、耦合度高、扩容困难等问题，无法支撑日均百万级订单、千万级用户的并发诉求。本次项目核心目标如下：
-
完成单体架构向分布式微服务架构重构，实现业务模块彻底解耦，支持团队并行开发、独立部署迭代
-
保障系统高可用（99.99%以上）、高并发（峰值QPS可达XXXX），解决流量峰值、数据一致性、服务容错等核心难题
-
搭建标准化CI/CD流程、全链路监控体系，降低运维成本，提升故障排查与修复效率
-
优化数据存储与读写效率，支撑海量数据的存储、检索与分析，提升用户体验
（三）核心架构设计
1. 整体架构分层
-
接入层：Nginx + Spring Cloud Gateway 实现路由转发、黑白名单、限流鉴权、请求过滤
-
应用层：基于Spring Cloud Alibaba微服务拆分，划分为用户中心、订单中心、支付中心、商品中心、风控中心等核心业务域
-
数据层：MySQL 8.0（分库分表）+ Redis 6.x（多级缓存）+ Kafka（异步解耦）+ Elasticsearch（全文检索）
-
基础设施层：Docker容器化 + K8s容器编排 + Jenkins自动化部署，搭配Prometheus+Grafana全链路监控
2. 核心技术栈
-
开发框架：Spring Boot 2.7.x、Spring Cloud Alibaba、Dubbo、MyBatis-Plus
-
服务治理：Nacos（注册/配置中心）、Sentinel（熔断限流）、Seata（分布式事务）
-
中间件：Redis、Kafka、Elasticsearch、MinIO（文件存储）
-
运维部署：Docker、K8s、Jenkins、SkyWalking（链路追踪）
（四）核心难点与解决方案
| 核心难点 | 技术挑战 | 落地解决方案 |
|---|---|---|
| 高并发下单场景 | 峰值流量冲击、库存超卖、订单重复提交、数据库压力过载 | 采用Redis分布式锁控制库存扣减；雪花算法生成唯一订单号防重；消息队列异步削峰；本地缓存+Redis多级缓存兜底；接口分层限流防护 |
| 跨服务数据一致性 | 订单、支付、库存跨模块事务，极易出现数据不一致 | 核心链路采用Seata TCC模式保证强一致性；非核心链路采用事务消息+补偿机制，实现最终一致性 |
| 服务容错与高可用 | 单点故障、服务雪崩、依赖服务宕机导致整体不可用 | 微服务集群部署；Sentinel实现熔断、降级、限流；注册中心多节点部署；数据库主从切换、Redis哨兵模式保障数据层高可用 |
| 海量数据检索 | 千万级订单/商品数据查询响应慢，数据库查询瓶颈 | Elasticsearch构建专属检索索引，Canal监听binlog异步同步数据；索引分片+冷热分离，优化查询速率 |
（五）项目优化成果
-
系统响应时长：平均接口耗时从500ms优化至80ms以内，核心接口低于50ms
-
并发承载能力：峰值QPS从500提升至5000+，平稳应对大促/峰值流量
-
故障恢复效率：从小时级修复缩短至分钟级，线上故障率降低70%
-
研发迭代效率：单模块迭代周期从2周压缩至3天，并行开发效率大幅提升
二、微服务核心问题
（一）业务与中间件结合分析
核心思路是业务场景驱动选型，中间件匹配业务特性，拒绝盲目引入技术。例如：高并发读写场景选用Redis做缓存与分布式锁；异步解耦、流量削峰选用Kafka；强一致性分布式锁、协调服务选用ZooKeeper；服务注册发现优先选用AP模型组件保证可用性。需兼顾性能、成本、运维复杂度三大维度，落地最优方案。
（二）Spring Cloud 与 Spring Boot 关系
-
Spring Boot：微服务开发的基础框架，主打简化配置、自动装配、快速启动，专注单个微服务应用的高效构建，屏蔽底层技术细节
-
Spring Cloud：基于Spring Boot的分布式微服务全家桶，依托Spring Boot的单体服务能力，提供服务注册发现、配置管理、熔断限流、网关路由、消息总线等分布式治理能力，解决微服务集群协同问题
（三）注册中心（Eureka vs ZooKeeper）
| 特性 | Eureka | ZooKeeper |
|---|---|---|
| 设计原则 | 优先保证 AP（可用性） | 优先保证 CP（一致性） |
| 核心逻辑 | 节点平等，无主从选举；15分钟85%节点无心跳触发自我保护机制 | 主从架构，master故障触发leader选举（30~120s），选举期间集群不可用 |
| 自我保护机制 | 网络故障时不剔除过期服务，仍接受注册/查询（本地缓存兜底），网络恢复后同步数据 | 无客户端缓存兜底，选举期间注册服务暂时瘫痪 |
| 适用场景 | 服务注册发现（容忍数据最终一致性，追求服务可用性） | 分布式锁、配置协调、分布式协同（强一致性需求场景） |
（四）Spring Cloud 核心组件
| 组件 | 核心功能 |
|---|---|
| Spring Cloud Eureka | 服务注册中心（AP设计，服务注册、发现、心跳检测） |
| Spring Cloud Ribbon | 客户端负载均衡，内置轮询、随机、权重等多种策略 |
| Spring Cloud Feign | 声明式HTTP客户端，集成Ribbon+Eureka，简化跨服务调用 |
| Spring Cloud Hystrix | 断路器组件，防止服务雪崩，支持熔断、降级、线程隔离 |
| Spring Cloud Config | 分布式配置中心，统一管理配置，支持配置拉取与刷新 |
| Spring Cloud Zuul | 服务网关，实现路由转发、权限校验、流量监控、请求过滤 |
| Spring Cloud Bus | 消息总线，联动Config实现配置动态刷新、服务间事件通信 |
（五）分布式信息共享（底层方案）
1. 基础共享策略
-
信息分级管理：按数据重要性、更新频率分层，核心数据入数据库持久化，热点数据入缓存，临时数据用消息队列传递
-
公用存储备份：核心数据统一入库+多副本备份，保证数据不丢失
-
消息队列解耦：异步传递非实时数据，实现服务解耦、流量削峰
-
服务寻址定位：依托注册中心实现服务与数据的快速定位
2. 核心技术对比
| 技术 | 说明 |
|---|---|
| 事务性发件箱(Outbox) | 保证本地事务与消息发送的原子性，解决数据操作与消息发布不一致问题 |
| 变更数据捕获(CDC) | 监听数据库binlog/redo日志实现数据同步，主流框架：Canal（阿里）、Debezium（Redhat）、Maxwell（Zendesk）、SpinalTap（Airbnb） |
（六）发布部署（高阶实践）
采用Jenkins+Docker+K8s标准化CI/CD体系，实现全流程自动化：
-
核心流程：代码提交→自动化构建→单元测试→镜像打包→镜像仓库→K8s滚动发布→灰度验证→全量上线
-
核心价值：保证环境一致性，避免部署差异导致的线上问题；支持滚动更新、回滚、弹性扩缩容，降低发布风险，提升部署效率
（七）Dubbo 核心特性
-
定位：高性能RPC框架 + 完善的SOA服务治理框架
-
通信模式：默认单一长连接 + NIO异步通讯，适配小数据量、高并发场景
-
RPC能力：支持dubbo、hession、json、fastjson等多种传输协议，底层基于mina/netty实现长连接通信
-
治理能力：依托ZooKeeper实现服务注册发现，提供负载均衡、容错、路由、监控、权重调整等完整治理能力
（八）熔断机制
核心逻辑：监控服务调用失败率、响应时长等指标，达到阈值后立即触发熔断，关闭故障服务调用通路，快速返回兜底结果，防止局部故障扩散导致整个系统雪崩。熔断状态分为关闭、开启、半开三种：开启状态持续一段时间后进入半开状态，尝试放行部分请求探测服务恢复情况，调用成功则关闭熔断，失败则重新开启熔断。
三、Redis 核心问题
（一）缓存穿透
1. 定义
用户查询的Key在Redis中不存在，且对应数据在数据库也不存在，恶意请求或无效请求会直接绕过缓存打穿至数据库，大量并发下极易导致数据库宕机。
2. 解决方案
-
缓存空值：对不存在的Key缓存空对象/空字符串，设置短期过期时间，避免重复查询数据库
-
布隆过滤器：提前将合法Key载入布隆过滤器，请求先过过滤器拦截无效Key，从源头阻断穿透
-
接口防护：增加参数校验、IP限流、黑名单机制，拦截恶意请求
（二）Redis 宕机数据恢复
| 方案 | 核心逻辑 | 特点 |
|---|---|---|
| RDB | 周期性生成内存数据快照，存储为二进制文件 | 恢复速度快、占用空间小，可能丢失快照后的数据 |
| AOF | 记录所有写操作日志，重启时回放日志恢复数据 | 数据完整性高，恢复速度慢，日志文件体积较大 |
| 混合模式 | RDB快照+AOF增量日志结合，Redis 4.0+支持 | 兼顾恢复速度与数据完整性，生产环境首选 |
（三）Redis 数据类型及应用场景
| 类型 | 存储特性 | 典型应用场景 |
|---|---|---|
| String | 单Key单Value，最大512MB；支持整数自增/自减；分int/embstr/raw存储 | 缓存、接口限流、计数器、分布式锁、分布式Session |
| List | 有序字符串列表，支持头尾推拉操作，元素可重复 | 微博时间轴、简单消息队列、评论列表、历史记录 |
| Set | 无序无重复集合，支持交集、并集、差集运算 | 点赞/踩、用户标签、好友关系、去重、抽奖活动 |
| ZSet | 有序集合，按分值自动排序，元素唯一 | 排行榜、延时队列、Geo定位、权重排序 |
| Hash | 键值对集合，类似HashMap，支持单字段更新 | 用户信息、商品属性、对象缓存、组合查询 |
（四）缓存雪崩
1. 定义
大批量缓存Key同时过期失效，或Redis集群整体宕机，所有请求直接涌入数据库，瞬间流量压垮数据库，导致系统瘫痪。
2. 解决方案
-
过期时间打散：非热点Key设置随机过期时间，避免集体失效；热点Key设置永不过期
-
多级缓存兜底：本地缓存（Caffeine）+ Redis集群+数据库，层层拦截请求
-
集群高可用：部署Redis哨兵/集群模式，避免单点故障
-
服务限流降级：接口层限流、熔断，数据库压力过载时启动兜底方案
（五）缓存数据同步/恢复方式
-
懒加载模式：查询时先查缓存，缓存无数据则查询数据库，再回写缓存，适配读多写少场景
-
主动推送模式：数据更新时，主动同步至缓存，保证缓存与数据库一致性
-
批量导入模式：通过Redis Pipeline、数据脚本批量写入，适用于全量缓存预热
-
CDC同步模式：监听数据库变更日志，异步同步增量数据至缓存
四、数据库核心知识
（一）数据库优化（核心方向）
1. 架构优化
-
分库分表：垂直分库按业务拆分，水平分表按范围/哈希拆分，解决单表数据量过大问题
-
读写分离：主库负责写入，从库负责读取，扩容从库分担查询压力，搭配MyCat、ShardingSphere实现路由
-
实例隔离：核心业务与非核心业务数据库实例分离，避免相互影响
2. 表设计优化
-
合理设计索引：主键索引、联合索引优先，避免冗余索引、失效索引
-
字段精简：选用合适数据类型，用tinyint代替int、varchar代替text，避免NULL值滥用
-
适度反范式：减少多表关联查询，允许少量字段冗余，提升查询效率
3. SQL与运维优化
-
慢查询优化：通过EXPLAIN分析执行计划，避免全表扫描，优化关联查询
-
批量操作：替代循环单条操作，减少数据库IO
-
控制事务：避免长事务、大事务，拆分小事务降低锁冲突
-
定期维护：清理历史数据、优化索引碎片、定期备份
五、Java 基础与高并发
（一）高并发解决方案
1. 服务器层优化
-
负载均衡：Nginx/LVS/F5实现流量分发，分摊单服务器压力
-
无状态化：服务剥离会话信息，存入Redis，支持水平扩容
2. 数据库层优化
-
并发控制：乐观锁（version版本号）、悲观锁（行锁/表锁）防止数据错乱
-
分库分表+读写分离，降低单节点压力，提升吞吐量
-
缓存落地：热点数据缓存至Redis，减少数据库查询频次
3. 程序设计层优化
-
锁机制：synchronized（JVM层优化）、ReentrantLock（灵活可控）、CAS无锁编程
-
异步编程：线程池、CompletableFuture、消息队列异步化，提升并行处理能力
-
多级缓存：本地缓存+分布式缓存结合，降低远程调用损耗
（二）核心设计模式
-
单例模式：保证类全局唯一实例，枚举式最优（防反射/反序列化破坏）
-
代理模式：JDK/CGLIB动态代理，Spring AOP核心实现，实现切面增强
-
工厂模式+反射：Spring IOC容器核心，解耦对象创建与使用
-
模板方法模式：定义固定流程骨架，子类实现细节，如JdbcTemplate、RedisTemplate
-
观察者模式：事件监听、消息订阅，实现松耦合通信，如Spring事件机制
