update

main.tex

@@ -71,19 +71,19 @@
 % \ResumeDesc{技术栈}{SPDK / NVMe / Blobstore / LD\_PRELOAD / xattr / Unix Domain Socket。}
 
 \begin{itemize}
-    \item 需要非侵入的绕过内核 I/O 栈以降低存储延迟：以 LD\_PRELOAD 劫持 POSIX I/O 接口，通过 Unix Domain Socket 将 LD\_PRELOAD 层拦截的 POSIX I/O 请求路由至 Daemon 进程，由 Daemon 统一接管 SPDK Blobstore 数据路径，完成数据库场景零侵入接入。
+    \item 围绕“零侵入接管应用 I/O”设计整体方案，以 LD\_PRELOAD 劫持 POSIX I/O 接口，通过 Unix Domain Socket 将 LD\_PRELOAD 层拦截的 POSIX I/O 请求路由至 Daemon 进程，由 Daemon 统一接管 SPDK Blobstore 数据路径，完成数据库场景零侵入接入。
 
-    \item 从零实现目录树工程复杂度极高：控制面全部复用 Linux VFS 管理目录、权限、inode 生命周期，仅以 xattr将文件绑定至对应 SPDK Blob；无需实现元数据存储/载机制，显著降低实现复杂度。
+    \item 为解决从零实现目录树工程复杂度高的问题，采用“控制面复用 Linux、数据面走 SPDK”的分层架构，目录树、权限、inode 生命周期继续复用 Linux VFS，仅通过 xattr 持久化文件到 Blob 的映射，避免自建元数据数据库，显著降低系统复杂度。
 
-    \item SPDK 的 Ownership 机制要求固定线程操作元数据：设计 Daemon 进程为「单 IPC I/O 线程 + 单 SPDK 元数据线程 + 多 SPDK I/O 线程」架构，在满足 SPDK 单线程约束的同时支持并行数据 I/O。
+    \item 针对 SPDK metadata 的单线程约束，设计「单 IPC 线程 + 单 metadata 线程 + 多 I/O poller」模型。
 
-    \item 多进程下需要正确模拟 fork/dup 等语义：在 Daemon 进程中模拟 Linux Open File  Description 与 FdTable 模型，并通过 IPC 同步引用计数与偏移语义，保证多 fd / 多进程共享句柄时行为一致。
+    \item 为确保在多进程下正确模拟 fork/dup 等语义，设计在 Daemon 进程中模拟 Linux Open File  Description 与 FdTable 模型的方案，并通过 IPC 同步引用计数与偏移语义。
     
-    \item 每次 I/O 重新申请 DMA 内存导致延迟抖动：实现 DMA IO Pool 复用 DMA 内存区域，消除重复申请开销。
+    \item 为解决每次 I/O 重新申请 DMA 内存导致延迟抖动，实现 DMA IO Pool 复用 DMA 内存区域，消除重复申请开销。
 
-    \item FIO 中 WRITE 延迟明显高于预期：对端到端路径加轻量打点，将总延迟分解至各层；定位到无条件 RMW、poller 调度抖动、线程未绑核等多个叠加问题，逐项修复后 spdk服务端延迟 从毫秒级降至约 350 µs。
+    \item 解决FIO 中 WRITE 延迟明显高于预期问题，基于端到端 trace 对 WRITE 延迟做分层定位，识别并修复无条件 RMW、poller 调度抖动、线程未绑核等问题。
 
-    \item 性能测试：在 VMware + 模拟 NVMe 环境下，FIO 16K Psyn 随机写达到 kernel 路径约 73\% IOPS（1353 vs 1855），平均时延为 692 µs；顺序对齐写场景下吞吐达spdk\_nvme\_perf 基准 90\%（4K: 94/100 MiB/s；128K: 1662/1843 MiB/s）。单客户端场景 TPS 为 38.2，对比 kernel 39.1，端到端性能基本持平（约 4\% 差距）。
+    \item 性能测试：在 4K randwrite 场景下，ZVFS 达到 3816.78 IOPS，高于内核路径 2883.24 IOPS，平均完成时延降至 259.53~\textmu s；WRITE 请求端到端平均耗时约 256~\textmu s。
 \end{itemize}
 
 
@@ -102,15 +102,19 @@
 % \ResumeDesc{技术栈}{Linux、Reactor、epoll、io\_uring、RESP2、eBPF、共享内存 IPC、gprof、ChainBuffer、SPSC。}
 
 \begin{itemize}
-  \item 频繁小对象分配导致内存碎片严重：自实现内存池统一管理分配，小对象场景吞吐较 glibc malloc 提升 7\%。
+  \item 针对高频小对象分配导致的碎片与锁竞争问题，自研内存池统一管理分配路径；在小对象场景下吞吐较 glibc malloc 提升 7\%。
-  \item AI问答的长回复在固定缓冲区下存在内存浪费：以 ChainBuffer + ET 边缘触发 + readv 直读重构收发路径，支持大命令缓冲，实现跨分段大Key解析。
-  \item 同步持久化阻塞主线程，高并发下落盘成为瓶颈：以 io\_uring + n×spsc 落盘线程组实现异步持久化，配合 in-flight 背压防止 CQ overflow，负载均衡分摊写压力；无fsync 时 set QPS 损失仅 5.6\%，每秒fsync一次 QPS损失 11.3\%，读路径接近零影响。相较同步持久化方案，整体性能提升 2x。对比Redis AOF 模型持久化开销降低50\%。
-  \item 运行时内存泄漏难以追踪：通过 eBPF 实现热插拔泄漏探测组件，对比 valgrind 性能开销更小且无需重启即可介入。
-  \item 为实现读写分离架构，降低主进程压力：实现基于独立进程的主从同步，通过共享内存向独立同步进程转发写命令，QPS损失15\%。设计基于内核态函数探测的eBPF转发方案，探测开销低于3\%。
-  % \item 增量持久化路径存在性能瓶颈：gprof 定位后发现提交落盘任务频繁申请内存，引入组提交机制与可复用组提交缓冲池，合并多次写入批量落盘；持久化路径开销降低 23\%。
-  \item 针对重复问题频繁触发 LLM 调用导致的高延迟与高成本问题：设计“精确匹配 → 向量检索 → LLM 兜底”的三层路由，显著减少模型调用次数与 tokens 消耗。
-  \item 性能测试：压测场景（RBTree，256B value，pipeline=128）下 set/get 吞吐达同环境 Redis 的 72\% / 75\%。
 
+  \item 面向 AI问答系统 场景下长回复与大报文带来的缓冲区浪费，重构 ChainBuffer + ET 边缘触发 + readv 收发链路，支持大命令缓冲与跨分段 key 解析，降低网络层内存拷贝与拼装开销。
+
+  \item 为解决同步持久化阻塞主线程、落盘路径成为瓶颈的问题，设计 io\_uring + n$\times$SPSC 异步持久化模型，并结合 in-flight 背压防止 CQ overflow；无 fsync 时 set QPS 仅下降 5.6\%，每秒 fsync 一次时下降 11.3\%，读路径几乎不受影响，整体方案相较同步持久化性能提升约 2 倍。
+  
+  \item 为降低运行期内存泄漏排查成本，实现基于 eBPF 的热插拔泄漏探测组件；相比 valgrind 开销更低，且无需重启服务即可介入线上问题定位。
+  
+  \item 围绕读写分离与副本同步需求，实现基于独立进程 + 共享内存 IPC 的主从同步链路，将写命令转发至同步进程，MPS 损失控制在 15\% 以内；同时设计基于 eBPF 内核态探测的实时转发方案，探测开销低于 3\%。
+  
+  \item 在落地本地搭建的 AI问答系统 的过程中，针对重复问题频繁触发 LLM 调用带来的高延迟与高成本，设计“精确匹配 $\rightarrow$ 向量检索 $\rightarrow$ LLM 兜底”的三层路由，显著减少模型调用次数与 tokens 消耗。
+  
+  \item 压测场景下（RBTree、256B value、pipeline=128），set/get 吞吐达到同环境 Redis 的 72\% / 75\%，验证了自研存储内核在功能完整前提下具备较强性能竞争力。
 \end{itemize}