前言

兜兜转转又是一年，不知不觉 2023 已经结束。回想自己过去一年的成长与感悟，依然觉得是收获满满。今年工作之后闲余时间相比学生时代少了许多，到了除夕才有时间来写今年的年终总结。好在自己还是下定决心将这个习惯坚持下去，希望这些年终总结不仅能够在未来的时光里鞭策自己，也能够获得更多大家的反馈来修正自己。

首先依然是自我介绍环节，我叫谭新宇，清华本硕，师从软件学院王建民/黄向东老师。目前在时序数据库 Apache IoTDB 的商业化公司天谋科技担任内核开发工程师。我对分布式系统、可观测性和性能优化都比较感兴趣，2023 年也一直致力于提升 Apache IoTDB 的分布式能力、可观测性和写入性能。

接下来介绍一下我司：

天谋科技的物联网时序数据库 IoTDB 是一款低成本、高性能的时序数据库，技术原型发源于清华大学，自研完整的存储引擎、查询计算引擎、流处理引擎、智能分析引擎，并拓展集群管理、系统监控、可视化控制台等多项配套工具，可实现单平台采存算管用的横向一站式解决方案，与跨平台端边云协同的纵向一站式解决方案，可方便地满足用户在工业物联网场景多测点、多副本、多环境，达到灵活、高效的时序数据管理。

天谋科技由全球性开源项目、Apache Top-Level 项目 IoTDB 核心团队创立。公司围绕开源版持续进行产品性能打磨，提供更加全面的企业级服务与行业特色功能，并开发易用性工具，使得 IoTDB 的读写、压缩、处理速度、分布式高可用、部署运维等技术维度领先多家数据库厂商。目前，IoTDB 可达到单节点每秒千万级数据写入、10X 倍无损压缩、TB 数据毫秒级查询响应、两节点高可用、秒级扩容等性能表现，实现单设备万级点位、多设备亿级点位管理。

目前，IoTDB 能够为我国关键行业提供一个国产的、更加安全的、性能更加优异的选择。据不完全统计，IoTDB 已服务超 1000 家以上工业企业，在能源电力、钢铁冶炼、航空航天、石油石化、智慧工厂、车联网等行业均成功部署数十至数百套，并扩展至期货、基金等金融行业。目前已投入使用的企业包括华润电力、中核集团、国家电网、宝武钢铁、中冶赛迪、中航成飞、中国中车、长安汽车等。

2023

介绍完背景后，在这里回顾下 2023 年我们系统组的主要工作，可分为高扩展性、高可用性、可观测性、性能优化、技术支持和技术沉淀 6 个方面。

在高扩展性方面，我们主要做了以下工作：

• 计算负载均衡： Share Nothing 架构面临的主要挑战之一是扩展性问题，扩缩容过程中需要迁移大量数据，这不可避免地消耗系统资源，进而影响现有的读写性能。为了解决这个问题，Snowflake 带头在业界推广了存算分离的架构设计，近年来的 Serverless 架构则进一步追求了更极致的弹性。尽管存算分离架构能够避免在扩缩容时迁移大量数据的问题，但它仍面临着冷启动问题。也就是说，当一个计算节点宕机后，从对象存储服务恢复宕机节点数据的过程可能会比较耗时，这对于对 SLA 要求极高的应用场景构成了挑战。那要如何解决这一问题呢？在 VLDB 2019 的论文中，ADB 介绍了其架构解决方案，其中一个值得注意的点是，它对本应无状态的 ReadNode 实施了热备份。虽然论文没有解释为何采取这种做法，但很明显，这种方案可以通过增加机器资源消耗来确保 SLA 指标，从而进一步说明了面对不同业务场景和问题时，不同架构可以找到更加适合的 trade-off。针对 Share Nothing 架构的扩展性问题，乔老师今年引导我们探讨了在时序场景中是否可能避免扩缩容时的数据迁移。我们发现，相比传统的 TP/AP 场景，时序场景有几个不同之处：首先，读写负载相对更加稳定可预测；其次，大部分情况下数据的时间戳会呈现正态分布，并随着时间不断递增。这为我们提供了结合场景进行优化的可能性。我们通过将数据划分为不同的时间分区，并在新的时间分区到来时进行实时负载均衡分配，从而实现了无需迁移数据即可达到计算资源均衡的效果，甚至在运行 TTL 时间后，还能进一步实现存储和计算资源的双均衡。回顾我们的设计，通过牺牲新节点立即提供服务的能力，我们避免了扩容时的数据迁移，这在大多数负载可预测的时序场景下取得了良好的效果。当然，对于一些特殊场景，我们也提供了手动 Region 迁移的指令，以便运维人员根据业务需求，在存储和计算资源的平衡时间上进行手动调整。
• 分片分配算法：在今年上半年针对某用户的 12 节点 2 副本场景进行高可用性测试时，我们遇到了一个问题：当我们故意使一个节点宕机后，发现另一个节点出现了 OOM 现象。深入分析后，我们明白了问题所在：由于整个集群仅有 6 个副本集合，一个节点的宕机导致约 1/6 的 Region Leader 被迫迁移到了同一节点上，这导致了该节点过载，进而出现 OOM。其实这一问题是一个典型的分片分配问题。我们调研学习了来自 Stanford 的 ATC 2013 Best Paper Copysets 论文以及该作者两年后在扩缩容场景对 Copysets 算法的补充，并决定将该算法应用到 IoTDB 中。通过这一改动，客户场景中的节点散度从 1 增加到了 5.11，这意味着当单个节点宕机时，多个节点能够分摊待迁移 Leader 的压力，有效避免了 OOM 现象的发生。此外，集成 Copysets 算法还带来了其论文提到的对于数据丢失概率和副本恢复速度的提升。回顾这项工作，最让人印象深刻的是陈老师的深厚算法功底。在我们努力理解论文理论证明的过程中，陈老师补充了论文中遗漏的公式证明。当陈老师引入泊松过程的概念时，我们尚能跟上步伐；然而当陈老师引入指数型随机变量和连续马尔可夫链的概念时，我们只能赞叹：天不生陈老师，飞书 Latex 公式功能万古如长夜了。
• 企业版激活：对于企业版软件实现可信授权，我们面临多项挑战：如何在不依赖网络的情况下部署，同时通过硬件绑定来防止许可证的滥用？如何设计一个系统，让激活次数不再受节点数量的限制，以提高整个集群的激活效率？我们还需要引入一系列的使用限制，包括许可证的有效期、节点数、CPU 核心数、序列号和设备数等等。此外，还需考虑如何防止各种潜在的破解尝试，比如回调系统时间、复制文件目录、在使用相同机器码的云平台上部署等，同时保证这些安全措施不会影响到商业用户的使用体验，例如支持非 root 用户激活、提供一键激活功能等。面对这些问题，我们逐一制定了解决方案并加以设计实现。在这个过程中，我和宇衡对各种 Corner Case 进行了深入的分析和讨论，这段经历让我受益匪浅。

在高可用性方面，我们主要做了以下工作：

• IoTConsensus：在过去的一年里，我们针对基于异步复制思路的 IoTConsensus 共识算法，在性能、稳定性、鲁棒性和可观测性方面做出了显著提升。如今，在线上的大部分场景中，该共识算法已经被优化至接近实时同步的效果，基本上不会再出现因为同步速度跟不上写入速度而导致的 WAL 堆积现象。接着我们开始思考一个命题：在异步复制系统中，不考虑节点宕机等异常情况，是否能在任何写入负载下都保持同步速度与写入速度同步？通过对 MySQL binlog 异步复制等类似场景的观察，湘鹏和我通过排队论的论证和性能实测发现，这个假设是错误的。这一发现促使我们开始进一步探索和设计基于操作变更到状态变更的共识算法。尽管理论上 Leader 侧的 WAL 堆积问题似乎无解，但在实际工程应用中，我们找到了解决办法。我们不仅在多个方面迭代优化以减少 WAL 堆积的可能性，还特别总结了导致 WAL 堆积的八大潜在原因及其解决策略。目前，我们团队已有许多成员能够独立地诊断并解决这一问题，有效地消除了这一单点瓶颈。
• RatisConsensus：今年，我们对 Apache Ratis 社区做出了显著贡献，包括引入了基于 Read-Index 和 Lease Read 的线性一致性读功能，以及若干状态机易用的 API。我们还提高了 Snapshot 传输的稳定性，并提交了超过 30 个 patch，涵盖了各种 bug 修复。除此之外，宋哥不仅多次担任 Ratis 社区的 Release Manager，近期还荣幸被邀请成为 Apache Ratis 社区的 PMC 成员。宋哥作为目前 Ratis 社区 Top3 活跃的开发者，已经时常被我们开玩笑称为 Ratis 社区 Vice PMC Chair 了。
• 共识层：去年，IoTDB 共识层参考了 OSDI 2020 Best Paper Delos 的思路进行了设计和实现，支持了多种具有不同一致性和性能特性的共识算法。今年，我们在性能与一致性级别这两个维度上对其支持的不同共识算法进行了深入的对比分析，为 IoTDB 的实施及用户在选择共识算法时提供了重要参考。我们还广泛调研了多种数据库的共识算法实现，通过文档阅读、代码走读和性能实测等多种方法，从共识算法的功能和性能开销等多个角度进行了细致地对比，并取其精华，去其糟粕。此外，今年我们在一些内存紧张的特殊场景下，发现 IoTConsensus 可能会出现副本不一致的问题。经过排查，我们认识到问题并非出在共识算法本身，而是由于状态机执行的不确定性导致的。虽然理论上根据 RSM 模型，所有副本应当达到一致状态，但在实际工程实践中，许多问题都可能使得 RSM 模型不完全适用，比如 Leader 的磁盘写满而 Follower 的磁盘未写满，可能引发执行的不确定性。针对这一问题，我们咨询了曾在 OB 工作的剑神，并在知乎上发问探寻大佬们的解决思路。收到的许多反馈都倾向于“Fail Fast”的处理原则，这可能是因为对许多 TP 系统而言，一致性比可用性更为重要。然而，对于时序场景，可用性往往比短暂的不一致性更加重要。因此，我们认为在遇到此类问题时直接退出进程并不是一个合适的解决方案。为此，我们通过在共识层捕获此类异常并采取有限重试的策略，以避免让业务感知到这种现象，从而保证了系统的高可用性和一致性。

在可观测性方面，我们主要做了以下工作：

• 监控面板：今年，我们借鉴了火焰图作者在《性能之巅》中的思路，从用户视角和资源视角出发，构建并完善了四个监控面板，共计近四百个 panel。这些面板的建设旨在提供全面的性能监控和分析能力，帮助我们更有效地诊断和解决性能问题。首先，我们设立了 Performance Overview 面板，该面板汇总了集群信息，不仅能帮助我们判断性能瓶颈是否存在于 IoTDB 中，还能进一步拆解并统计不同类型请求的延迟分布，从而精确定位到 IoTDB 内部读写流程的具体瓶颈环节。其次是 System 面板，它聚焦于系统资源，包括网络、磁盘、CPU、线程池利用率、JVM...