-- 没错，我又来投滴滴啦，继续刷面试，记面经
- 自我介绍
先聊了聊项目： - 简历中，支付过程是如何实现的，接口调用控制重复使用，redis 锁怎么设置的，超时时间等等
- 公共服务系统，上下流是什么
- redis 挂了，怎么控制接口不重复调用
这里答得不是很好，从ng 控制，但其实可以借助数据库实现 - 报销数据安全性如何保证
费用合理性控制（相关规则） + 代码层面控制（金额数据参与签名，接口进行签名等） - 涉及到的数据分库分表怎么考虑的，具体拆分依据
回答的很浅只回答了 按照 主键 hash + 时间分片； 其实可以再深入一点 - 规则库如何设计，如果要实现动态可重复的配置如何实现
模板方法 + 责任链 + 配置中心 记录规则链路需要配置的服务，配置变化通知 reload bean 重新创建整个规则
聊了下基础： - redis 快的原因
只回答了 内存操作数据 + 单线程架构 + 简单的数据结构，可以补充 使用了IO多路复用，异步持久化不阻塞线程 - 数据库的隔离级别，分别存在什么问题
四种标准隔离级别，在提示的情况下想起来了，还是记录一下：
读未提交（Read Uncommitted）。
特点：允许读取其他事务未提交的数据，性能最高但一致性最差，可能发生脏读、不可重复读和幻读。
适用场景：对数据准确性要求极低的场景，如实时统计。
读已提交（Read Committed）。
特点：仅读取已提交数据，解决脏读问题，但可能出现不可重复读和幻读。Oracle、PostgreSQL等数据库默认采用此级别。
适用场景：高并发读写场景（如电商秒杀），需兼顾性能与基本一致性。
可重复读（Repeatable Read）。
特点：确保同一事务内多次读取结果一致，解决脏读和不可重复读，但可能允许幻读。MySQL默认级别，通过间隙锁（Gap Lock）减少幻读风险。
适用场景：金融交易、库存管理等需要数据强一致性的业务。
可串行化（Serializable）。
特点：完全串行执行事务，解决所有并发问题，但性能最低。
适用场景：银行转账等绝对不允许数据不一致的场景。
算法题 - 最大不重复子串
应该是中等难度的题目，双指针 or 可变滑动窗口，set 存窗口内的字符，如果有重复则移动左边的指针，没有则继续移动右边的指针，加入set
反问： - 面试中的不足
给的反馈是，基本上都能说的回答的出来，但是深度不够 - 工作强度
10.30-9.00 左右 - 对转GO的培养方案
公司有完善的培养体系，具体未介绍
--- 反思
- 需要加强用到中间件的相关基础概念，待补充 数据库基础，复习 redis 基础，IO相关知识
- 继续刷题，不能停，不然笔试可能会翻车....