分类：面试题

前言 AI 时代，开发者写代码的比例在降低，更多时间花在需求梳理、方案评审，以及最后的代码审查和功能验收上。角色一变，今年的 Go 面试也跟着变——不再纠缠你背不背得出 API，而是看你对 Go 的理解深度够不够：能不能在一堆 AI 生成的代码里，一眼看出那些编译能过、单测也过、一上量就出事的细节问

前言 AI降低了编写普通代码的门槛,但对程序员的要求反而变了:你需要掌握更多的底层原理、优秀的设计理念和语言细节,才能对AI生成的代码做出敏锐的审核、及时发现问题,保证软件运行的稳定。 例如针对一个接口的性能瓶颈,AI为了避免阻塞,提议用channel把逻辑异步化,结果因为协程没处理好,反而引发全局

前言 如今基础语法、标准库用法、常见陷阱这些,AI已经答得又快又准,开发者更多时间不是在写代码,而是在长上下文里审查AI输出的代码。 面对AI输出的长上下文，即使是资深的开发者也很容易漏掉语言层面潜藏的bug。例如:你让AI实现一个并发场景,它顺手用了普通map做并发读写——编译能过、单测可能也过,

写在文章开头 近期和读者聊到了一道大厂面试题： 有一个库存为n的商品，用三个线程进行库存扣减及三个线程进行库存补给，如何设计？ 借着这个问题，笔者就从一个设计者的角度聊聊并发编程的设计技巧。 (https://qiniuyun.sharkchili.com/202404212229302.png)

写在文章开头 针对既有场景设计和架构这个话题，一直是笔者近几年的工作课题，也一直想写，但是没有时间。还好，最近因为个人一些原因刚刚好需要针对这些场景进行一下复盘。而这篇文章正是基于上一篇starrocks架构优化前所遇到一个存量问题，即一个分布式架构下各个软件中间件局限性所导致的数据一致性问题。 同

基于RocketMQ重构seata AT模式分布式事务 问题说明 我们核心的企业短信发送服务接入主要是用于处理各大企业的短信请求的，整体来说业务逻辑为： 1. 创建短信任务，存任务根到本地库(当前服务) 2. 日限扣减，扣减企业用户本日限额短信数(网管服务) 3. 短信发送，调用调度服务将短信提交到

大文件数据导入 需求 针对报备的企业，集团每日会将数据传输至文件服务器上，由本平台程序进行定时采集入库，这些文件的特点是： 1. 每日 1h 投放一份增量文件。 2. 文件最多可能有 15 个 3. 15 个文件中可能存在文件重复的情况 所以我们要做到： 1. 尽可能1小时内完成采集入库，如果失败要

@ toc 排查与定位因Spring拓展点使用不当导致RPC调用偶发错误问题 故障说明 在微服务设计拆解之初，因历史原因配置信息表和群发平台分到了不同的数据库上，因为业务上的需要群发平台的企业实体信息配置需要依赖于维测控制台的实体信息配置，由于涉及的join查询众多，所以考虑的开发成本和 RPC 网

@ toc 对ElasticSearch了解多吗？有参与哪方面的工作？ ES 这一块我们主要是做一些故障短消息和一些群发任务的检索的，整体来说 qps 量也不是很大，着重是需要考虑检索性能以保证某些故障情况下，短信详情可以快速被定位到，我在这其中主要是负责： 1. 配合运维进行ES服务器和分片设计的

@ toc 缓存置换失效问题 故障说明 本人负责的短信调度中心是负责发送短信的，在设计初期为了考虑到短信重发的场景，我们采用的 redis 来缓存已经发送的短信数据，只有明确短信发送且成功后，我们才会将其发送出去。 (https://qiniuyun.sharkchili.com/img0fba9c