元戎启行 - 一面 - 8.20 面经 (1h)

自我介绍。我看你简历都是基架相关的，会考虑业务这边吗
我看你这边项目比较多，选一个自己觉得有挑战性的我们聊一下（选了开源之夏的agent课题）
介绍一下（Agent Hub, A2A, Cli Agent, Agentic Workflow, Txn Agent分别介绍了下）
我理解 hub 就是提供一个provider然后agent可以通过自然语言去向hub里已经注册的内容查询需要的能力是吧（是的）
那这里你不是seata框架的内容吗，它和分布式事物有集成吗，或者怎么结合起来。（讲了整套生态和seata的关系，以及一些可以和分布式事物结合起来的场景，类比实习里的rule-engine和smart-engine讲了为什么可以结合起来）
好的，那其实本质上他后期对seata是会有一个辅助的效果对吧（对）。
因为这里涉及到的ai相关的或者协议封装的比较多，其实技术上可以考察的点会比较少，可以再选一个技术上可以check的点比较多的项目聊聊吗？（说了自己的分布式kv项目）
介绍一下（从单机和分布式的角度分别介绍了下，然后说了目前的完成度，以及一些优化的点）
可以可以，我们聊一下这个，涉及到的东西会比较广一点。我看你这里是用了Bitcask做的存储层，他是一个类LSM的结构是吧（对，然后讲了bitcask的插入删除查询的流程）
我有一个问题啊，Bitcask他是怎么去组织这个实例，下面的日志文件，还有条目的。（讲了bitcask实例结构和日志编码）
这里bitcask是直接写磁盘吗，LSM是会有一个cache这样（写磁盘然后更新内存索引）
那你再讲一下完整的查询的流程吧。（查索引拿log_file_id和offset,然后查日志文件，反序列化，校验CRC，利用LogHeader取具体kv）
这里你校验CRC这个步骤是每次都要做的吗，启动的时候能不能优化一下。（讲了有hintfile和没有的时候分别怎么做）
ok，然后你这边索引是一个全内存的对吧`，数据量巨大索引巨大的时候这里有什么优化可以去避免掉节点的oom。（单机可以用类似虚拟内存的思想解决，然后用bloomfilter避免无效切页，分布式可以去对每个node设置size/cap的阈值，DHT散列的时候优先倾斜到size/cap值比较小的node）
你这里提到了布隆过滤器，有没有想过把bloom过滤器的序列化内容也放在日志里去做加速。（想过，但是感觉时机有问题，插入bloomfilter序列化内容的时机应该是触发merge日志轮转的时候，但是此时的hintfile和indexer会因为插入bloomfilter导致需要变更，更新成本比较大，会导致merge时间拉长，且期间想要查询的话得copy一份内容让读和merge的写隔离）
好的，有读过HBase的代码吗，讲讲（之前看过一篇分布式索引的博客，其中倒排索引为了避免full gc参考了HBase的堆外内存的做法，讲了一下）
是的，不过java高版本是可以直接控制gc的。（是的，但是go没有这一块的内容，提了一嘴之前有个arena的提案但是官方没有实现貌似）
做题（m*n的矩阵，左到右升序，上到下升序，查找target）
反问：
您在面试的过程中觉得我还有哪些需要提升的点（说我写题前可以先和面试官交流一下思路再写，然后可以继续打磨下简历，引导后面的面试官的问题）
最近更新过简历可以和hr同步更新下然后同步到面试官那边吗（不确定）