金三银四面试题来了

金三银四面试中，12306相关的高并发、分布式系统及中间件技术是高频考点，以下从核心问题、解决方案、中间件应用、设计原则四个维度梳理关键面试点及回答策略：

一、高并发秒杀系统核心问题与解决方案

超卖问题
原因：高并发下库存扣减的原子性被破坏，如“查询库存-扣减库存”非原子操作。
解决方案：
数据库锁：通过SELECT ... FOR UPDATE加行锁（性能差，仅适用于低并发）。
Redis原子操作：利用DECR或Lua脚本实现库存扣减的原子性。
分布式锁：通过Redis或Zookeeper实现全局锁，确保同一时间仅一个请求操作库存。
系统雪崩与穿透
雪崩：缓存集中失效导致大量请求直击数据库。
对策：缓存设置随机过期时间、多级缓存（本地缓存+分布式缓存）、熔断降级（如Hystrix）。
穿透：恶意请求查询不存在的数据，绕过缓存直接访问数据库。
对策：布隆过滤器预过滤、缓存空值（设置短过期时间）。
性能瓶颈优化
无锁化设计：通过CAS（Compare-And-Swap）或原子类（如Java的AtomicInteger）减少锁竞争。
串行化处理：将请求按队列顺序处理（如Kafka消息队列）。
扁平化架构：减少系统层级，降低延迟（如LVS+Nginx直接负载均衡）。

二、分布式系统关键技术与中间件应用

分布式锁实现
Redis分布式锁：
正确实现：使用SETNX key value NX PX milliseconds命令，结合唯一值（如UUID）防止误删他人锁。
Redlock算法：通过多个Redis节点提高可用性，但需权衡性能与一致性。
Zookeeper分布式锁：
原理：利用临时顺序节点和Watcher机制实现公平锁，但性能低于Redis。
微服务架构组件
服务注册与发现：Eureka（CP架构，适合高可用）、Nacos（AP架构，适合一致性要求低的场景）。
负载均衡：Ribbon（客户端负载均衡）、Nginx（服务端负载均衡）。
熔断降级：Hystrix通过线程池隔离资源，防止雪崩；Sentinel提供更轻量的流量控制。
链路追踪：Sleuth+Zipkin实现调用链监控，快速定位性能瓶颈。
消息中间件选型
RocketMQ：适合金融级高可靠场景，支持事务消息和顺序消息。
Kafka：高吞吐量，适合日志处理和大数据分析。
RabbitMQ：轻量级，支持多种协议（如AMQP），适合低延迟场景。

三、数据库与缓存优化策略

MySQL索引设计
执行计划分析：通过EXPLAIN查看索引使用情况，优化type（如避免ALL全表扫描）和key（实际使用的索引）。
索引类型选择：
聚簇索引：InnoDB的主键索引，数据按主键排序存储。
非聚簇索引：普通索引，需回表查询数据。
调优技巧：
避免索引失效（如!=、OR条件未覆盖索引、函数操作字段）。
使用覆盖索引减少回表（如SELECT id,name FROM user WHERE id=1）。
Redis性能优化
持久化策略：
RDB：全量快照，适合数据恢复，但可能丢失数据。
AOF：追加日志，支持everysec（每秒同步）或always（每次操作同步），平衡性能与安全性。
主从复制与集群：
主从同步：通过REPLICAOF命令实现读写分离，主节点写，从节点读。
分片集群：如Redis Cluster，通过哈希槽（16384个）分配数据，支持水平扩展。

四、高频面试题回答思路

12306抢票与微信红包的共同点
高并发场景：均需解决超卖、性能瓶颈问题。
技术方案：
12306：分库分表（按车次、日期分片）、Redis缓存余票、消息队列异步处理订单。
微信红包：预分配红包金额到Redis、原子操作扣减、异步落库。
CAP与BASE理论应用
CAP：分布式系统无法同时满足一致性（C）、可用性（A）、分区容错性（P），需权衡取舍（如Zookeeper选CP，Eureka选AP）。
BASE：通过“基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventually Consistent）”实现高可用，适合电商等场景。
如何向面试官展示技术深度
源码级理解：如分析Redis的INCR命令如何通过单线程保证原子性。
压测实战：描述用JMeter或Gatling模拟高并发，观察TPS、响应时间等指标，定位瓶颈（如数据库连接池耗尽）。
避坑经验：如分布式锁未设置超时导致死锁、消息队列积压引发系统崩溃。

面试方法论：

热门标签