数据库

概述

DolphinDB 有两种运行模式：单实例模式和集群模式。

• 单实例模式仅有一个数据节点，无控制节点和代理节点。

• 集群模式包含四种角色：控制节点、代理节点、数据节点和计算节点。

  • 控制节点。一个集群可以有一个或多个控制节点。控制节点是DolphinDB集群的核心部分。它负责收集代理节点和数据节点的心跳，监控每个节点的工作状态，管理分布式文件系统的元数据和事务。

  • 代理节点。代理节点负责执行控制节点发出的启动和关闭数据节点的命令。在一个集群中，每台物理服务器有且仅有一个代理节点。

  • 数据节点。在数据节点上可以进行数据存储和查询操作（或更加复杂的计算）。每台物理服务器可以配置多个数据节点。

  • 计算节点。只用于计算的节点，应用于包括流计算、分布式关联、机器学习等场景。计算节点不存储数据，故在该节点上不能建库建表，但可以通过 loadTable 加载数据进行计算。

默认情况下，代理节点、数据节点和计算节点通过 UDP 广播，用户也可以修改配置参数 lanCluster=0 来启用 TCP 广播。代理节点、数据节点和计算节点每秒钟发送一次心跳给控制节点，告知控制节点自己仍然活着。如果控制节点连续3秒没有收到某一节点的心跳，就认为该节点是死亡节点。

单实例模式和集群模式的数据模型并无差异，并且都支持事务。两者的区别在于，集群模式采用对等架构，支持高可用。

对等架构

主流的分布式数据库大多采用主从架构，主节点不仅要负责管理元数据和状态同步，还要双机热备来保证高可用，容易成为系统瓶颈，增加系统横向扩展的难度。DolphinDB 采用对等架构，依靠全局可见的元数据服务，任何数据节点都可以成为查询请求和数据写入的入口，不存在系统瓶颈点，更容易做到资源的负载均衡。

高可用

DolphinDB 提供数据、元数据和客户端的高可用方案，即使数据库节点发生故障，数据库仍然可以正常运作，保证业务不会中断。

DolphinDB 采用多副本机制，相同数据块的副本存储在不同的数据节点上。即使集群中一个或多个数据节点宕机，只要集群中还有至少一个副本可用，那么数据库就可以提供服务。在生产环境中，一般把副本个数设置为 2，既能够保证数据的高可用 ，也能够起到负载均衡的作用，DolphinDB 读取数据时会选择从负载较低的节点读取。

为了进一步保证数据的安全和高可用，DolphinDB 还支持在不同的物理服务器上存储数据副本，并且副本之间保持强一致性。即使一台物理服务器宕机，也可以通过访问其他机器上的副本来提供数据服务。默认情况下，DolphinDB 允许相同数据块的副本分布在同一台机器的不同数据节点上。

数据存储时会产生元数据，例如每个数据块存储在哪些数据节点的哪个位置等信息。元数据存储在控制节点上。为了保证元数据的高可用，DolphinDB 采用 Raft 协议，通过配置多个控制节点来组成一个 Raft 组。Raft 组中只有一个 Leader，其他都是 Follower, Leader 和 Follower 上的元数据保持强一致性。数据节点只能和 Leader 的控制节点进行交互。如果当前 Leader 不可用，Raft 组会立即选举出新的 Leader 来提供元数据服务。Raft 组能够容忍小于半数的控制节点宕机，例如包含三个控制节点的集群可以容忍一个控制节点出现故障，包含五个控制节点的集群可以容忍两个控制节点出现故障。要设置元数据高可用，集群中控制节点的数量至少为3个，同时需要设置数据高可用，即副本数必须大于1。

DolphinDB API提供了自动重连和切换机制。使用 API 与 DolphinDB 的数据节点/计算节点交互时，如果连接的数据节点/计算节点宕机，API会先尝试重连，若重连失败会自动切换连接到集群中其他可用的数据节点/计算节点，继续执行未完成的任务。切换连接数据节点/计算节点对用户是透明的，用户不会感知到当前连接的节点已经切换。目前 Java, C#, Python 和 C++ API 支持高可用。

关于如何启用高可用，参考： 高可用部署教程 。