理解 ThingsDB 的核心机制

Source: Dev.to

查询处理

当查询发送到 ThingsDB 节点时，节点首先检查自己的状态。

• AWAY 模式 – 节点不在本地处理请求，而是将查询转发给集群中另一个活跃节点，确保客户端永远不会遇到连接阻塞。

如果节点接受查询，它会检查内部缓存：

• 缓存命中 – 已经见过完全相同的查询，ThingsDB 跳过编译，直接使用预编译的版本。
• 缓存未命中 – 查询是新的，ThingsDB 开始编译过程。

在编译期间，引擎会判断查询是否需要 更改。

只读查询

如果不需要修改数据，查询会立即在该节点上执行。不会涉及其他节点，使得读取操作非常快速。

过程（Procedures）

过程始终是预编译的。ThingsDB 能立即知道它们是否需要更改，从而节省宝贵的微秒。

更改处理

如果查询需要修改数据，ThingsDB 会为下一个 Change ID 发起一次“争夺”：

1. 查看当前全局 Change ID 并提议下一个递增值（Current + 1）。
2. 通过基于多数节点的共识，必须有多数节点同意此 ID。

达成共识后，开始处理更改。所有对集合的修改都绑定到该特定 ID，并在整个集群中同步，保证每个节点以完全相同的顺序处理更改，从而保持完美的数据一致性。

Futures

ThingsDB 使用 Futures 来处理复杂逻辑。如果查询中包含一个或多个需要更改的 futures，每个 future 可以获得自己的 Change ID。此优化：

• 防止在调用外部模块时系统被锁住。
• 让大量的“更改”逻辑与过程或查询的其余部分隔离。

策略提示：
如果一个过程大多数情况下是只读的，但偶尔需要写入数据，可以将写入部分包装在一个 future 中。这样可以避免每次调用都生成全局更改（参见 ThingsDB 书中的示例）。

数据持久化

ThingsDB 采用双重机制进行持久化：

• 完整状态转储 – 在特定时间点对整个数据状态进行快照。
• 归档文件 – 对每一次单独更改的连续日志。

节点启动与恢复

节点启动时遵循严格的恢复路径：

1. 加载最近的完整状态转储。
2. 从该转储中识别出最后的 Change ID，并从归档文件中重放其后的所有更改。
3. 等待一个对等节点进入 Away 模式。启动的节点报告其最后处理的 Change ID，Away 节点同步缺失的增量。

如果节点与集群的同步差距很大（或新增了全新节点），会进行 完整同步，从头传输整个状态转储。

Away 模式

Away 模式 是 ThingsDB 用于在不中断服务的情况下进行维护的机制。当节点处于 Away 模式时，它会执行一些重量级任务，例如：

• 完整状态转储（快照）
• 垃圾回收（内存管理）
• 定时备份
• 同步对等节点

在 Away 模式期间，节点仍然与客户端保持通信，但会将它们的查询转发出去，以保持系统响应。更改会在后台收集，并在节点离开 Away 模式、重新加入集群之前统一应用。一次只能有一个节点处于 Away 模式，确保集群其余部分能够继续执行主要任务。

总结

通过将阻塞的维护任务与客户端请求解耦，并使用精细的共识机制来处理更改，ThingsDB 提供了高性能且高度弹性的数据库体验。

接下来：客户端侧。