美团C++ 一面总结

1. 介绍一下你的项目，重点说说架构设计和你负责的模块

回答框架：

• 项目背景和业务场景
• 整体架构（画图说明）
• 你负责的模块和技术选型
• 遇到的挑战和解决方案
• 项目成果和个人收获

2. 你的项目中如何处理高并发场景？具体用了哪些技术手段

回答要点：

• 缓存策略（Redis多级缓存）
• 异步处理（消息队列削峰）
• 数据库优化（读写分离、分库分表）
• 限流降级（令牌桶、熔断器）
• 连接池、线程池复用
• 具体的QPS和优化效果

3. 你们系统的日志是怎么设计的？如何快速定位线上问题

答案：

日志设计：

• 日志分级：DEBUG、INFO、WARN、ERROR
• 统一格式：时间戳、线程ID、日志级别、模块、内容
• 链路追踪：traceId贯穿整个请求链路
• 异步写入：不阻塞业务线程

快速定位问题：

1. ELK日志系统：Elasticsearch存储和搜索Logstash收集和处理Kibana可视化查询
2. 定位流程：根据时间范围缩小范围用traceId追踪完整链路关键字搜索错误信息查看上下文日志
3. 监控告警：错误日志超过阈值自动告警关键业务指标监控实时大盘展示

4. 你们的服务是如何部署的？用过容器化吗

答案：

部署方式：

• Docker容器化部署
• Kubernetes编排管理
• CI/CD自动化流水线

容器化优势：

• 环境一致性：开发、测试、生产环境统一
• 快速部署：秒级启动
• 资源隔离：互不影响
• 弹性伸缩：根据负载自动扩缩容

发布流程：

1. 代码提交触发CI
2. 自动编译、测试、打包镜像
3. 推送到镜像仓库
4. K8s滚动更新
5. 健康检查通过后切流量

灰度发布：

• 先发布到1%流量
• 观察指标正常后逐步放量
• 出问题快速回滚

5. 你们的数据库表是如何设计的？为什么这样设计

答案：

设计原则：

• 三范式：减少冗余
• 适当反范式：提高查询性能
• 冷热数据分离
• 大表拆分

索引设计：

• 主键索引：自增ID
• 唯一索引：username、email
• 普通索引：高频查询字段
• 联合索引：多字段组合查询

分库分表：

• 垂直拆分：按业务模块拆库
• 水平拆分：按用户ID哈希分表
• 路由规则：userId % 256

举例说明："我们的订单表按用户ID哈希分了256张表，查询时先计算表名，然后直接查对应表。历史订单超过3个月的归档到历史库，减轻主库压力。"

6. Redis有哪些数据结构？你在项目中具体怎么用的（保留的八股文1）

答案：

五种基本类型：

• String、Hash、List、Set、Sorted Set

项目实际应用：

1. 用户Session：String存储，设置30分钟过期
2. 商品详情：Hash存储，字段可单独更新
3. 消息队列：List实现，LPUSH生产，RPOP消费
4. 用户标签：Set存储，方便求交集
5. 排行榜：Sorted Set，按分数排序

缓存策略：

• Cache Aside：先查缓存，miss则查DB并回写
• 缓存穿透：布隆过滤器
• 缓存击穿：互斥锁
• 缓存雪崩：过期时间加随机值

7. 如何保证Redis和MySQL的数据一致性

答案：

常见方案：

1. 先更新DB，再删除缓存（推荐）：更新数据库删除Redis缓存下次查询时重建缓存问题：删除失败导致不一致解决：重试机制、消息队列异步删除
2. 延迟双删：删除缓存更新数据库延迟1秒再删除缓存防止并发导致的脏数据
3. 订阅binlog：用Canal监听MySQL binlog解析变更事件异步更新Redis保证最终一致性
4. 分布式事务：用Seata等框架保证强一致性性能差，很少用

实际选择：

• 对一致性要求不高：先更新DB再删缓存
• 对一致性要求高：订阅binlog
• 极致一致性：分布式事务

8. 你们系统的监控是怎么做的？如何发现和处理故障

答案：

监控体系：

1. 基础监控：CPU、内存、磁盘、网络用Prometheus采集Grafana可视化展示
2. 应用监控：QPS、响应时间、错误率接口调用链路（Jaeger、Zipkin）慢查询监控
3. 业务监控：订单量、支付成功率核心业务指标自定义埋点

告警机制：

• 多级告警：P0（立即处理）、P1（1小时内）、P2（当天处理）
• 多渠道通知：短信、电话、企业微信
• 告警收敛：相同告警5分钟内只发一次

故障处理：

1. 收到告警，查看监控大盘
2. 查看日志定位问题
3. 快速止损（降级、限流、回滚）
4. 修复问题，验