同以往 nStar 的专访，揭开社区用户的非技术、生活面拉近彼此的距离不同。这次的专访下来，仿佛和嘉宾做了一场专业技术交流。也许，通过这种技术人更熟悉的、聊技术的方式，大家能更好地了解今天的这位嘉宾。
他是一个 issue 引起 NebulaGraph 存储负责人注意的贡献者，也是 GitHub 上少有的“底层人民”，搞底层数据存储引擎，贡献 RAFT 相关 pr 的人。
nebula：先来 50+ 字的自我介绍吧，让 NebulaGraph 的社区小伙伴认识下你。
shixiangz：张世祥，现在是在 Shopee 的多模数据库团队搬砖。主要工作是做 Engine 这方面的开发，像是分布式系统之类的。目前，Shopee 这边基于开源的 NebulaGraph 进行了部分的自我封装，比如说 Redis 协议，kkv，kv 等。以上，一共 64 字 :D
nebula：多模数据库开发的主要工作是什么？
shixiangz：就是整合一些常见的数据库类型，比如 kv 数据库，kkv 数据库，还有一些像是 Redis 内存数据库，加上 SQL、事务之类的一个大乱炖。现在 Shopee 这边是在一些开源的数据库基础之上，做些整合封装，让多模数据库既能处理 SQL 之类的数据，又能处理其他结构的数据，像是图。一般来说，多模数据库是在编译环节，选定好你要用哪个数据模型，再进行处理。简单来说，它就是分成了不同的集群，某个集群单一来处理特定的数据模型。
底层用的 storage，修改计算层，进行算法、语法的置换。
nebula：你还记得你第一次提交 pr 是什么时候么？
shixiangz：说来惭愧，nebula 还是我贡献的第一个开源项目，大概在元旦前后吧。在 Shopee 这份工作之前，我是做 CDN 单机存储系统的，没咋接触过 RocksDB 或者 RAFT。在元旦的时候，由于工作需要，我正儿八经地接触了下 RAFT，当时是在线上找数据，用的 ingest 功能，发现它老是出错，就去查看了下代码，发现当中有一个小 bug。就提交了一个 issue 过来，这是 issue 地址：https://github.com/vesoft-inc/nebula/issues/5265
图1：shixiangz 的第一个 pr 痕迹
nebula：作为第一次贡献的人，你提 pr 的姿势还挺规范的：先开个 issue 讨论下要贡献的内容，再提交 pr 过来和之前的 issue 关联。一点都不像是个新手 contributor，是有研究过相关的开源贡献姿势么？
shixiangz：没有没有，当时就看了下官方文档的贡献流程：how to contribute，就先提了个 issue，其实那时候我在本地已经修复了这个问题。不过在 issue 里，思为（NebulaGraph 布道师）和我说能不能顺手 fix 下提个 pr 过来。我就说行，反正已经顺手修了。
至于为什么要开个 issue，其实是想把前因后果描述清楚，如果只是在 pr 的 description 描述下的话，感觉有些背景信息会缺失掉。issue 的好处可能就是你可以先把部分原因和遇到的问题先表明，至少让看 issue 的人知道到问题在哪里。
此外，有些 bug 其实四王（NebulaGraph 存储负责人）他们知道，但是他们认为可能并不会影响整体逻辑，或者感觉修复它的带来的隐患更大于它目前存在的隐患，所以可能并不会一定要修它。就跟之前的提的 RAFT 的线程模型一样，他们也知道有问题，但是他们感觉如果修了之后的话，可能带来的问题会更大一点，所以他们就感觉目前就 OK 了，大家可以先提个 issue 来讨论一下具体是否需要修；反之，你如果只是提个 pr 过来的话，有些人可能不会和你解释为什么，就把 pr 关了。
旁白：也是这个 issue 引起了四王对他的关注，毕竟都是“底层人民”，心心相惜。
nebula：其实除了 GitHub 之外，你在论坛其实也挺活跃的，会回一些论坛的问题。
shixiangz：嗯，论坛的问题还是比较偏业务使用，我的工作内容更偏底层，像是 RocksDB 和 RAFT，所以，大部分问题我也不会。一般就看看，有些重复性的问题就看着回复下。逛论坛，还能遇到一些有意思的问题，比如之前就遇到一个内存增长的问题，还挺好玩的，从里面学到了个 jemalloc 的 Heap Profiling 堆栈分析工具。
其实像是内存爆炸这种问题，虽然表象是一样的，但是可能背后的原因是不一样的。毕竟对 C++ 而言，像是内存泄漏之外的问题就是不可避免，而且定位起来不好定位，但你要上了新版本就会影响业务。因此，我最近在搞内存限制这块的工作，就是 storage 那边做内存限制，主要是为了防止 OOM。
目前这块分两部分，一部分是请求，请求这块就是直接用的 NebulaGraph 官方这边的 Memory Tracker，但它只是控制了下请求内存和 wal buffer；另外一部分，就是 RocksDB 这块。Shopee 这边用 RocksDB 和 NebulaGraph 不大一样。业务侧的话，一个集群上可能很多 Space 和 Partition，会导致用到很多的 RocksDB，而 RocksDB 本身也有内存。因此，我们打算搞下 RocksDB 的内存，把它放到 RocksDB 自己的 Block Cache 里。RocksDB 的内存大头可能就是 MemTable、Bloomfilter 加上 Block Cache，然后把这三部分一起都放到 Block Cache 里，用 Block Cache，就 OK 了。
nebula：我看你代码贡献的话，好像和 RAFT 相关的会比较多点？
shixiangz：是的，主要是 storage 这块的工作。因为像是 graphd 那块的工作是和数据模型强相关的。而我主要还是研究 storage 这边 RAFT 算法和引擎这块。80~90% 搞 RAFT 这套的人都是基于 RAFT 那篇论文，实现里面的部分特性，具体实现细节的话可能会稍微调整。根据使用的工具，或者是现成库之类，进行部分微调，但大多数都是相通的。所以这就是为啥，给 nebula 贡献起来会相对顺手点。
nebula：像是 RAFT 这块的话，你觉得社区还缺些什么呢？
shixiangz：如果要是我提一个需求的话，只能说我希望提供些 RAFT 的运维工具。不过，感觉社区可能一时半会也没法搞，我自己最近在搞。比方说，你因为某些原因，比如说 bug，导致了 RAFT 的状态，跟 RAFT 论文已经不符合了，现在你的 RAFT 整体一致性已经被破坏了。
但是你又不能丢数据，那么最简单的办法就是应该提供一个工具，把现在 RAFT 状态直接清零，先把数据保存住。再重启，重新进行一轮的选举。后面，做完了可以开源出来，贡献给社区。
nebula：听说你还打算搞了一些其他和 RAFT 相关的东西？
shixiangz：之前在社区里提过 Raft 线程分离，和四王交流过，他的意思就是可能坑比较多，暂时不打算搞。
但是，我这边就把 RAFT 线程模型拆出来了，跟整个 storage 的进程完全分离，这样读写跟 RAFT 就完全分离了。这样的好处就是，在 RocksDB 或是写入量比较大的情况下，不会阻塞整个 storage，可以阻塞写，但是读不会被阻塞。这块改动量比较大，涉及的东西太多。最近我还在压测，主要测没有死锁和 coredump 的情况。最后，再测试下正确性，把所有 case 都跑一遍之后，没啥问题再提到社区这边，让四王他们看看，是不是有啥坑点在里面。
此外，上面提过的 RAFT 运维工具也会安排上。还有之前 send heart beat 这块的优化，现在心跳是单发的，因为 Shopee 这边的 Partition 数量太多，担心数量多之后，可能一台机器上四、五千个 Partition，每一个 part 去发一个心跳的话，资源耗费太大了，后边会做一个 Batch 发心跳的逻辑。这块优化的话，不是必须的。毕竟你如果 Partition 少的话，这个资源消耗还是可以容忍的。但是我们这边的话，现在一个集群 50 个 Space，一个 Space 1,000 多个 part，加上机器又没有那么强（64 核 + 512G 内存）。当请求比较多的情况下，可能心跳这一块的 QPS 也是比较高的，希望这波改造完，它降低一点。
nebula：有什么小工具安利给社区用户吗？
shixiangz：一个小插件 Coc.nvim，我日常开发用 Vim。Coc.nvim 有很强的索引、跳转、代码补全功能，借助它，就可以把 Vim 打造成完美的 C++ 编辑器。
整个专访，shixiangz 都透露着技术人对技术、对性能的追求，用开放的心态同社区交流。😂 但其实，他刚休完他的产假，有了一个人类幼崽，正在努力地当好爸爸。谈到他们家宝宝，他不再那么硬核而变得柔弱。
多面，才是社区用户的常态，希望大家能在一期期的专访中，了解社区中那些鲜活的人。如果你有什么想要理解的社区用户，记得留言^^
