
难度:中等 考察点:动态规划、中心扩展算法 关键思路:
•
定义dp[i][j]表示s[i...j]是否为回文
•
状态转移:dp[i][j] = (s[i] == s[j]) && dp[i+1][j-1]
•
边界情况:单个字符一定是回文
难度:简单 考察点:哈希表、字符统计 核心解法:
def longestPalindrome(s):
char_count = {}
for char in s:
char_count[char] = char_count.get(char, 0) + 1
length = 0
has_odd = False
for count in char_count.values():
if count % 2 == 0:
length += count
else:
length += count - 1
has_odd = True
return length + (1 if has_odd else 0)
我的回答:从并发和易用角度回答 面试官评价:没有回答到要点
正确回答要点:
•
资源利用率:轻量级线程,创建销毁成本低
•
同步编程的异步效果:用同步写法实现异步性能
•
I/O密集型场景优势:避免线程阻塞,提高吞吐量
•
内存占用小:单个协程栈大小通常为KB级别
我的盲区:只知优点,忽视缺点
真实缺点:
•
调试困难:协程切换使调用栈复杂
•
CPU密集型任务不适用:无法利用多核优势
•
生态系统依赖:需要配套的异步库支持
•
错误处理复杂:异常传播路径不直观
我的错误认知:ST作者通过多进程提高扩展性
正确理解:
•
Go协程:基于GMP调度模型,原生支持多核
•
C++20协程:无栈协程,需要手动调度
•
关键差异:Go有运行时调度器,C++需要用户自己实现调度
我的思路局限:只会从故障处理角度回答
完整高可用方案:
1. 负载均衡层
•
多机房部署,DNS轮询
•
LVS/Nginx负载均衡
•
健康检查机制
2. 无状态服务
•
多实例部署
•
会话外部化存储
•
自动扩缩容
3. 有状态服务
•
主从复制
•
领导者选举(Raft/Paxos)
•
分片存储
4. 数据层
•
多副本同步
•
故障自动切换
•
数据一致性保证
我的失误:没有说出混合使用方案
Redis持久化策略对比:
方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
RDB | 文件小,恢复快 | 可能丢失数据 | 备份,灾难恢复 |
AOF | 数据安全 | 文件大,恢复慢 | 对数据可靠性要求高 |
混合 | 兼顾两者优点 | 配置复杂 | 生产环境推荐 |
面试官追问:全量持久化是否阻塞用户请求
正确答案:
•
RDB:fork子进程处理,主进程继续服务
•
AOF:追加写入,性能影响小
•
混合模式:结合两者优势,平衡性能与安全
•
减少部署机器数量
•
减少同步延迟
•
概念堆砌,缺乏深度
1. 写入优化
•
批量写入,减少IO次数
•
异步提交,提高吞吐量
•
顺序写入,利用磁盘特性
2. 锁优化
// 悲观锁 → 乐观锁
std::mutex lock; // 阻塞式
std::atomic<bool> flag; // CAS操作
// 锁粒度细化
// 粗粒度:整个数据结构加锁
// 细粒度:单个节点加锁
3. 网络优化
•
TCP滑动窗口调整
•
连接复用
•
数据压缩
4. 架构优化
•
读写分离
•
缓存分层
•
数据分片
面试官建议:
•
从经典项目开始(如LevelDB)
•
不要被初期的代码混乱吓退
•
关注核心算法和数据结构
•
理解设计思想和架构演进
你知道的,面试官知道的:不是好回答 你不知道的,面试官知道的:才是重点
•
协程机制:只知表面,不懂底层实现
•
系统设计:缺乏完整的架构思维
•
性能优化:停留在概念,缺少实践经验
1
算法刷题:0-100题反复刷5遍
2
源码阅读:深入阅读LevelDB等经典项目
3
系统设计:学习大型系统架构案例
4
实践项目:在真实场景中应用优化技巧
•
预期管理:回答要超出面试官预期
•
细节把握:重要的技术点要深挖到底
•
思维展现:展示思考过程,不只是结果
这次百度面试的失败,让我明白了一个残酷的事实:在技术面前,侥幸心理永远行不通。
面试官不是要听你背诵知识点,而是要看到你对技术本质的理解。每一个"为什么"背后,都是对你思考深度的考察。
技术成长没有捷径,唯有持续深挖,不断实践。
从今天开始,放下浮躁,重新出发。把每个技术点都吃透,把每个问题都想深。下一次,我会带着真正的实力回来。