第8次面试回顾：

一、 基本信息

1.1 公司：曙光信息产业股份有限公司

1.2 岗位：NVME全闪阵列高级研发工程师

岗位职责：

  1. 参与存储阵列的模块设计，配合架构师完成模块及特性的概要设计和详细设计
  2. 负责模块和特性的核心代码的开发
  3. 协助架构师完成模块内的设计评审，代码review，和疑难问题解决

任职资格：

  1. 从事存储阵列或者分布式存储相关研发工作1年以上
  2. 熟练掌握C语言编程，具有良好的编程习惯
  3. 承担过存储阵列或分布式存储团队核心特性和流程的开发人员优先
  4. 具备良好的沟通习惯、语言表达清楚、思路清晰，有团队合作精神
  5. 有带领过研发技术团队经验的优先

二、面试细节回顾

第1题：你描述的产品架构我听不懂，请手绘以下产品设计图

**1. 我的视角：

  • 作为普通开发人员，我所说的内容领导根本听不懂。汇报的形式似乎比内容更重要，
  • 在领导眼里，我的报告全部被看成漏洞，觉得不够严谨、不够上进。我们与领导之间存在明显差距，
  • 但我根本不知道问题出在哪里。

2. 面试官视角：

  • 你需要汇报给上级领导，必须假设领导对项目一无所知。
  • 你的报告要整体绘制，包括系统设计、模型设计、概要设计等。
  • 给人的感觉是你平时从没做过类似汇报、系统设计或概要设计，完全不会写。

3. 技能要求：

第2题：如何将单线程改为多线程处理，并保证各线程负责的任务均衡？

1. 从我的角度来看：

  • 这点我也很好奇。刚接触时也有同样的疑问。谷歌提供了基于数学公式的解决方案，而不是普通的 hash，一致性hash，但具体细节我不清楚。
  • 后来工作忙起来，也没再有时间深入研究。最重要事情不去做，做了其他人做垃圾事情。

2. 从面试官的角度来看：

  • 你自己都没考虑清楚这个问题，就算是用了别人的方案，也必须研究透彻
  • 算法的输入是什么？输出是什么？如何保证数据分配均衡？这是最基本的要求。

3. 技能要求：

  • 你必须考虑数据拆分是否均衡，并能对比不同算法的优缺点，
  • 最终说明采用了哪一个，以及原因，有数据支撑。

4. 技术解析（仅供参考）：

  • Ceph 使用 CRUSH（Controlled Replication Under Scalable Hashing）算法来决定数据对象的存储位置。
  • TiKV 将数据按键范围划分为多个 Region，每个 Region 存储一个连续的键值区间
  • 3FS 的数据分布与均衡策略：
  • 3FS链式复制（Chain Replication）**：3FS 使用链式复制协议来确保数据的一致性和高吞吐量。在该协议中，数据写入请求沿着复制链传递，直到所有副本都被更新为止。
  • 3FS分布式元数据管理：3FS 的元数据服务是无状态的，使用事务性键值存储（如 FoundationDB）来管理文件系统的元数据。客户端可以连接到任意元数据服务实例，实现负载均衡和高可用性。

第3题：针对大文件，如何写入的？

1. 我的视角：

  • 什么是“大文件”？就是一个非常大的文件，而不是大目录。
  • 从元数据管理角度看，大文件与小文件并无区别。能否用存储池管理大文件？但我对具体处理过程并不了解。

2. 面试官视角：

  • 你需要清楚阐述在 CephFS 或类似系统中，如何并发读写大文件，
  • 包括任务的分割模型、线程如何协作、并发访问是怎么处理的。
  • 但你的回答目前还非常模糊。

3. 技能要求：

  • I/O 栈的与文件系统之间关系

4. 技术解析（仅供参考）：

  • CephFS：大文件被拆分成多个默认 4 MB 的 stripe（对象），客户端多个线程并行读写不同 stripe，调用 pwrite() 或使用 mmap 定位偏移并发处理，尽量并行访问多个 OSD 提升吞吐。stripe 单元太小会增加调度和 metadata 开销
  • TiKV（Raftstore）：数据切分为多个 Region，每个 Region 由 Raftstore 独立处理。TiKV 已支持多线程 Raftstore（通过 raftstore.store-pool-size 配置）并发处理 Region，避免 Raftstore 单线程成为瓶颈

第4题：缓存如何处理的，客户端缓存、元数据管理、存储池？

1. 我的视角：
客户端好像会提供 cap 授权机制？我不确定这是否就是缓存机制的一部分，但我也没有完全理解它的作用。

2. 面试官视角：
你完全偏离了题意，显然不理解缓存系统会面临的核心问题。我们就到这里。

3. 技能要求：
你需要讲清楚缓存系统在并发场景下如何保持一致性，并说明分布式锁如何发挥作用。

4. 技术解析（仅供参考）：

  • CephFS 客户端缓存与 cap 授权机制：当块或 inode 操作发生时，客户端向 MDS 请求 capability（cap），包括读写权限和缓存授权。如果多个客户端访问同一 inode，MDS 会撤销 cap，客户端需返还缓存并同步最新元数据，保证一致

  • 并发控制/分布式锁机制：当多个客户端请求同一 key 或 inode 时，MDS 保证只有一个持有 exclusive cap 写操作，其他客户端等待。这相当于一种分布式锁机制，可防止缓存击穿、写冲突，确保缓存一致

  • TiKV支持：TiKV 能作为 metadata engine 为分布式存储系统提供强一致性支持（如 JuiceFS + TiKV 架构）。TiKV 内部管理 block-cache，以及 Raftstore 机制控制写操作时并发一致性，通过事务机制和重复写缓存控制 client-side 缓存行为

三、动手写代码能力

题目描述：

请10分钟完成下面题目

无重复字符的最长子串

给定一个字符串 s ，请你找出其中不含有重复字符的 最长 子串 的长度。 示例 1:

输入: s = “abcabcbb” 输出: 3 解释: 因为无重复字符的最长子串是 "abc"，所以其长度为 3。

示例 2:

输入: s = “bbbbb” 输出: 1 解释: 因为无重复字符的最长子串是 "b"，所以其长度为 1。

示例 3:

输入: s = “pwwkew” 输出: 3 解释: 因为无重复字符的最长子串是 "wke"，所以其长度为 3。   请注意，你的答案必须是 子串 的长度，"pwke" 是一个_子序列，_不是子串。

1. 我的视角：

  • 这个题目我根本听不懂

  • 算法类的我没准备，之前刷了 300 题现在忘了

  • 用最笨的方法解决，但面试官不认可，面试很快就结束了

2. 面试官视角：

  • 你都写不出来，废话不多说，直接结束

3. 技能要求：

  • 在 BAT 公司通常要求 LeetCode 难度为第 150 至 250 题范围的题目

  • 其他公司可能考 0–50 题，通常涉及字符串、链表基础操作，部分也会考树结构

  • 建议按部就班刷题，不要想太多，每道题都认真完成。大多数公司只关注基础题（LeetCode 前 50 题以内）

技术解析（简短说明 LeetCode 练习策略）

  • LeetCode 官方的 “Top Interview 150” 列表覆盖常见面试题，适合深入准备（前三个月准备）

  • Reddit 上也有大量经验用户分享，他们普遍认为稳定掌握 Leetcode 前 150 题、能总结出解题套路，对准备 BAT 及其他大厂面试更有效

  • 实际上，有用户表示仅刷了约 50-60 题仍能拿到大厂 offer，不过那通常代表对算法基础已非常熟悉，或通过更多场外经验补充

  • 但这是例外，大多数人应基于稳扎稳打的题目练习方案。

提示词

项目背景： 你是项目架构师，擅长项目全局视角设计，分布式文件系统（gfs，CephFS，JuiceFS，3fs），分布式数据库（tidb，等开源源码设计，兼顾口语化，让小白听懂。

任务描述： 请对输入内容 进行润色，保证句子通顺，原文内容保持不变

要求： 1. 这个格式保持不变，1. 我的视角 和2. 面试官视角 3.技能要求 4 技术解析 超过 ceph tikv ，3fs 等分布式数据库，分布式存储怎么做的 如果搜索不到不回答