在上一篇文章中，已经为大家分享了 RisingWave 相关核心概念和术语。本文将在此基础上为大家介绍 RisingWave 的架构、容错以及数据持久化。

1. 架构

RisingWave 的架构如下图所示。它由三个主要部分组成：Meta 节点、Compute 节点和 Compactor 节点。

• Meta 节点负责管理 Compute 节点和 Compactor 节点的元数据，并协调整个系统的操作符。
• Compute 节点负责从上游系统获取数据，解析和运行 SQL 查询，并将数据传送到下游系统。
• Compactor 节点处理数据存储和从对象存储中检索数据。它们还执行数据压缩，以优化存储效率。
  

2. 容错

RisingWave 是一种容错的分布式流处理系统。让我们通过以下三个方面对其是如何处理故障的做整体了解：

• RisingWave 如何从故障中恢复？
• 发生故障时，RisingWave 如何确保数据的正确性和一致性？
• RisingWave 的故障恢复对计算有何影响？

RisingWave 采用 Chandy-Lamport 算法创建检查点。检查点是代表整个系统在特定时间点的一致状态的全局快照。在 RisingWave 中，检查点被持久化到一个持久且高度可用的远程存储中。

读取查询时，RisingWave 总是从上一个检查点获取数据。这确保了数据的正确性和一致性。

如果发生故障，只有未保存到下一个检查点的状态才会丢失。RisingWave 所有内部有状态的算子都将从上一个检查点获取状态。这种方法避免了全部重新计算，因此不会造成长时间延迟。检查点间隔可以配置，默认为 10 秒。这意味着故障造成的延迟不应超过 10 秒。

例如，假设 RisingWave 集群已摄取 Kafka 数据 24 小时，在 1:00:25 出现故障，而最后一次检查点是在 1:00:20。在这种情况下，RisingWave 不会重新计算一天前的数据，而是从 1:00:20 的检查点开始重新计算。

为了尽量减少对计算的影响并提高效率，检查点是增量创建的。自上次检查点之后生成的状态会增量持久化到远程存储中。RisingWave 会在后台运行远程压缩任务来压缩检查点中的状态。这样可以回收空间，并提高读取性能。

3. 数据持久化

RisingWave 在创建检查点时，流算子和输出结果的增量状态会被持久保存在高可用的远程存储中，默认的检查点间隔为 10 秒。

在 RisingWave 中，Compute 节点在创建检查点之前会在内存中缓冲脏状态（脏状态指的是自上次检查点以来未保存的状态），从而执行写批处理。

当内存缓冲区超过某个内存阈值（可配置）或创建检查点时，脏状态将被刷新并持久保存在远程存储中。

RisingWave 并不要求所有数据都保存在内存中才能运行。数据可以持久化至：

• S3 或与 S3 兼容的对象存储
• 谷歌云存储，或 HDFS/WebHDFS（通过 Apache OpenDAL 实现支持）

如果有更多的内存资源，通常可以实现更好的缓存，从而提高性能，特别是对于要求很高的工作负载来说。不过，也可以通过分配有限的内存资源，实现中小型工作负载中等性能，从而节省一些成本。

4. 关于 RisingWave

RisingWave 是一款开源的分布式流处理数据库，旨在帮助用户降低实时应用的开发成本。RisingWave 采用存算分离架构，提供 Postgres-style 使用体验，具备比 Flink 高出 10 倍的性能以及更低的成本。

👨‍🔬加入 RW 社区，欢迎关注公众号：RisingWave 中文开源社区

🧑‍💻想要了解和探索 RisingWave，欢迎浏览我们的官网：risingwave.com/

🔧快速上手 RisingWave，欢迎体验入门教程：github.com/risingwave

💻深入理解使用 RisingWave，欢迎阅读用户文档：zh-cn.risingwave.com/docs