分布式数据库

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支持高可用。

关于如何启用高可用,请参考 高可用部署教程