1. 节目数据库在高并发的情况下有什么额外的设计？2. 比如有一个热点商品，开始秒杀之后大量用户请求，有一个字段是剩余库存，压测过程中发现下单性能较差。讲一下为什么这种表设计会性能较差，在数据库上有何改进。3. 热点商品不管怎么打散，都是访问到具体数据。是不是所有请求都会请求到这条数据，怎么做的改进。4. 缓存的策略，什么数据加入缓存。#牛客AI配图神器# 5. 你只是把购票人信息加入缓存中了吗？6. 热点信息是通过人工设置的吗？7. 缓存击穿的问题了解吗？8. 缓存穿透问题？9. HashMap的初始容量了解吗？10. 扩容的机制知道吗？11. 线程池用的多吗？12. 线程池的伸缩容的机制了解吗？13. MySQL的InnoDB索引是B+树，讲一下它的优缺点。14. 它哪些查询会有问题？15. 领域驱动设计这块了解吗？16. 领域模型有听说过吗？17. 算法题：有一个等概率返回0和1的函数，基于这个函数，设计一个等概率返回1到13整数的函数。18. 反问：有什么需要改进的？更新：疑似kpi，几乎全答出来然后秒挂

无手撕  面试官迟到三分钟（这应该不算迟到）以为会问八股，结果全是项目引申的，麻了 有的面试官不问我这玩具项目呜呜+在日常实习就没看，自己介绍都没讲清楚1. 线程通信方式  oom  线程安全 死锁2. 分布式事务 如果c超时没反应， 咋处理。直接通知回滚的话，可能有c先处理回滚的命令，后面又执行了本地事务（c查看本地事务的状态 执行中就不回滚 还是咋处理）3. 协调者挂了 咋办  项目: 库存变化流程 redis回滚库存为啥会超卖 mq重投db会不会超卖 （幂等判断和回滚在一个事务中）4. 分库和分表的区别（分库一般是多个实例解决高并发，分表是单表数据量比较大  分库和分表很像，都是按分片键路由）基于买家id分表分库的话，卖家想查询怎么办（binlog 卖家id分片）自己说话要坚定，不能弱弱怂怂的 晚上一看，挂了感觉是除了分布式事务那两问题基本都能回答个大概，可能"大概"这种程度不行吧，太久没看了，自己的项目都不熟了，分布式事务确实就学了一点   看见我的项目都想吐，重复看的东西。。#毕业后不工作的日子里我在做什么#呜呜呜呜，好菜，本科学历不太行感觉银行国企也不太稳麻了3. 我搜的是1.TCC  2.本地消息表  3.多节点选举机制（如Raft协议）实现高可用，避免单点故障     三阶段提交只是缓解了单点故障问题      （TCC和本地消息表根本就没有协调者所以没有单点故障   没有往这上面想 一直在绕三阶段提交）2. #### 1. 参与者C超时无响应**解决方案：**- **事务状态查询机制**：协调者先发起事务状态查询（3PC中的CanCommit阶段）- **异步补偿机制**：记录操作日志，超时后通过定时任务重试事务查询- **最终一致性兜底**：若长时间无响应，记录异常事务日志人工介入- **示例流程**：  1. 协调者发送prepare请求  2. 参与者C超时未响应  3. 协调者发起事务状态查询请求  4. 若C本地事务已提交 -> 继续提交其他参与者  5. 若C未提交/回滚 -> 发起全局回滚（我前面讲的RMQ的事务消息 也是反查本地事务状态 这没回答出来）4. ### 二、分库分表核心区别|          | 分库                          | 分表                  ||----------|-----------------------------|---------------------|| 拆分维度  | 数据库实例级别                   | 单表结构级别           || 核心目标  | 降低单点压力，提升并发处理能力        | 解决单表数据量过大问题   || 典型场景  | 电商系统买家库、订单库分离           | 用户表按月分表          || 实施难度  | 需要处理分布式事务、跨库join        | 主要处理SQL路由        |

我第一题就是dfs，但一个样例都通不过说我超时，第二题就模拟，先给方案sort排序，然后对每天贪心从前往后拿直到满，结果答案错误一个样例没过，明明所有的测试都通过了但就是一个没过，这么多笔试唯一一个这么惨的直接爆0了，明天还有高德的面试我都不想去了

1. 技术理解深度- 普通产品经理：侧重业务逻辑与用户体验，理解基础技术原理即可，如前后端协作。- AI产品经理：需深入掌握机器学习、深度学习等算法原理，了解数据预处理、特征工程、模型训练与评估等流程。2. 数据驱动程度- 普通产品经理：依赖用户调研与市场分析，数据用于验证假设。- AI产品经理：以数据为核心，需主导数据采集（如设计埋点方案）、清洗（处理缺失值与噪声）及标注流程（如医学影像的专家标注标准），且需评估数据质量对模型效果的影响。3. 开发流程- 普通产品经理：遵循传统敏捷开发，需求明确后推进开发（如功能优先级排序）。- AI产品经理：需管理不确定性较高的AI开发周期，例如：- 模型实验阶段：设计对比。- 迭代模式：采用「数据-模型-反馈」闭环。- 冷启动问题：规划数据积累策略。4. 风险评估维度- 普通产品经理：关注市场风险（如竞品功能）或技术实现风险（如开发周期延迟）。- AI产品经理：需额外应对：- 算法偏见：设计公平性评估指标（如不同性别用户的推荐覆盖率差异）。- 模型可解释性：在金融风控等场景需提供决策依据（如SHAP值分析）。- 数据合规：确保符合GDPR等法规（如用户数据的匿名化处理）。5. 协作团队角色- 普通产品经理：主要对接开发、设计、运营团队。- AI产品经理：需深度协同数据科学家（如特征选择方案）、算法工程师（如模型压缩部署方案）、数据标注团队（如制定标注SOP）。6. 效果评估指标- 普通产品经理：关注业务指标（DAU、转化率）。- AI产品经理：需兼顾技术与业务双重指标。 #聊聊我眼中的AI#  #牛客激励计划#  #产品经理#  #聊聊我眼中的AI#  #AI产品经理# #牛客AI配图神器# #牛客AI配图神器#