涛思数据TDengine征稿— ❤️万字长文，TDengine高可用分布式集群详解❤️ (建议收藏)

Posted 2021-06-30 英雄哪里出来

• 本文正在参与“拥抱开源|涛思数据TDengine有奖征稿：投稿地址。

文章目录

• 一、前言
• 二、举个栗子
• • 1、努力工作的小T
  • 2、可怜的小T
  • 3、小T的老婆小D登场
  • 4、小T创业了
  • 5、平衡分配任务
  • 6、公司越做越大
• 三、分布式和集群概览
• • 1、单点
  • • 1）单点概念
    • 2）单点故障
  • 2、主从机制
  • 3、集群
  • • 1）集群概念
    • 2）节点的概念
  • 4、负载均衡
  • 5、分布式系统
  • • 1）高可用
    • 2）高可靠
    • 3）高性能
    • 4）高并发
• 四、TDEngine的分布式架构
• • 1、TDEngine 概述
  • 2、分布式架构
• 五、TDEngine的进程节点
• • 1、物理节点
  • 2、数据节点
  • 3、虚拟节点
  • 4、管理节点
  • 5、虚拟节点组
  • 6、TAOSC
• 六、TDEngine的进程间通讯
• • 1、通讯方式
  • 2、FQDN配置
  • 3、端口配置
  • 4、集群对外通讯
  • 5、集群内部通讯
  • 6、管理节点的选择
  • 7、动态扩容
  • 8、节点重定向

一、前言

  本文将介绍 TDengine 的高可用集群架构，全文通俗易懂，会从最简单的分布式概念开始讲起，想要入坑服务器同学抓紧准备好你的被子，卷起来吧！
  在讲 TDEngine 的架构之前，我们先来复习和巩固一下分布式和集群中的一些常用概念以方便后续文章内容的理解。由于一些概念过于枯燥，所以我打算先举个栗子。

二、举个栗子

1、努力工作的小T

  小 T 作为一个程序员，同样也是一家之主，要担起养家糊口的重任，每天上班努力工作赚钱。

努(整)力(天)赚(摸)钱(鱼)的小T

2、可怜的小T

  突然，有一天，小T不堪重负，工作压力过大，导致便秘、大肠感染、肝脂肪浸润、高血压、高血糖、高血脂、神经性耳鸣、红斑、支气管炎、咳嗽、呕吐、头晕、手脚麻木、两眼无神、记忆衰退，最终进入了医院。于是暂时没法再赚钱养家了。

操劳过度的小T

3、小T的老婆小D登场

  经过几个月的修养，小T终于出院了，但是他觉得，得有一个人，在他生病的时候能够出去赚钱，于是他开始教老婆写代码，小T的老婆叫小D，确实也很聪明。很快就学会了。接下来，小T继续出去赚钱，每天回来把学到的知识教给小D，等哪一天小T病了，小D就去公司帮忙解决问题。久而久之，这个模式下来，也没有出过什么问题。

小T教小D写代码

4、小T创业了

  就这么持续干了十年，小T也有了点积蓄，于是他带着自己的技术，从公司跑路了。自己创办了一个公司，并且请了四五个小兵，一起来写代码。他自己和老婆偶尔也参与一下。

一起来写代码哟

5、平衡分配任务

  成为资本家的小T开始压榨员工，导致员工不堪重负，大家纷纷进了医院。于是他决定，根据情况酌情分配任务，这样，员工们就能轮流去医院，不会一起病倒，这样起码公司就能运作下去。

不要一起倒下哟

6、公司越做越大

  再接下来，公司逐渐步入正轨，于是还是招聘各种岗位，HR、法务、运维、运营，逐渐把公司发展成了上市公司。小T和小D也实现了财务自由。过上了幸福生活。这时候，就算小T和小D不工作，公司也能正常运作一段时间了。他们的公司以夫妻名字命名，叫 TD Company。

• 好了，故事讲完了。那么，接下来，我们来看下，我刚才都讲了些什么！! ?

三、分布式和集群概览

1、单点

1）单点概念

• 单点是分布式设计中的一大忌讳，这里的 “点” 指的是网络中的某个节点：一般指代的是某个进程 （Process） 或者 某台服务器物理机 （Server）。
• 一个进程会提供一个或多个服务，即 Service。
• 如果对于某个服务，我们只部署在一个进程上，这就是单点问题。

• 如上图所示，闪烁的球代表网络通讯，如果单点服务不出问题，那么这个系统就能正常运行，用户能够正常的获取信息，比如屏幕前的你能够正常的查阅这篇文章，就是因为 CSDN 的网站没有挂（当然，它肯定不是单点服务 ~）。

刚才故事里面的小 T，就好比这个单点服务。

2）单点故障

• 当这个单个进程挂了，或者唯一的物理机挂了，服务无法正常提供给用户，这就叫单点故障。

• 如上图所示，唯一的单点服务器故障以后，用户无法正常和服务器通讯，敲她急得都跺脚了~

就像刚才故事里小T住进了医院，这样就会导致他无法再赚钱养家了。

2、主从机制

• 主从机制，又叫主备机制，即 Master / Slave ，一共有两个进程：主进程 和 备用进程。主进程提供服务，而备进程就是备用着，默默的付出，在背后不断接收主进程的数据，等待主机挂了之后取而代之（啊这…… 司马昭之心，路人皆知啊）。
• 因此在主机还存活的情况下，备用机的唯一使命就是同步主机的数据，不对外会提供服务。

• 如上图所示，用户不断和主进行通讯，从不断从主那里同步数据。一旦主宕机了，则迅速切换从为主，然后在最短时间内把主启动起来。

  就好比刚才故事里小T是主，他的老婆小D是从，平时每天等老公下班回家给他分享知识。等老公倒下了，她就代替老公去上班，继续养家糊口，直到老公出院。夫妻间组成了 Master / Slave 模式。

• 常见的数据库 mysql 和 缓存 Redis 都有 主从模式。

3、集群

1）集群概念

• 集群，即多个进程通过网络联系在一起，它们提供相同的服务，任何一个进程都可以向客户端提供服务，某个进程挂了，可以通过数据迁移将用户数据迁移到另一个进程，只要这些进程没有全部挂掉，那么这个集群就是能正常工作的。

• 例如上图中，集群中总共五个进程，只有当五个进程都挂了，整个系统才会完全瘫痪。

就好比小T招募了一批程序员来帮他干活，这样他就不用干活了。这些程序员组成了一个集群。

2）节点的概念

• 节点，node，一般理解为一个进程，或者一台物理机，下文也会返回提到节点的概念。节点之间通过网络联系起来，组成了集群。
  

每个程序员都是集群中的一个节点。

4、负载均衡

• 用户连接网络集群中的进程，如果没有做策略，可能会出现一种情况就是：有些进程连接用户巨多，而有些进程很少有用户连接，这样就造成某些进程的负载过大，而影响正常服务器的运行。
• 基于这样的考虑，我们需要设计一些均衡策略，让用户能够均匀的分布到不同的进程上，这就叫负载均衡。

就好比，刚才每个程序员轮流加班，三班倒，这样整个系统还是能运作下去。

5、分布式系统

• 多个提供不同服务的集群组成一个完整的高可用架构，就是基础的分布式系统。

• 如上图所示，拥有不同功能的服务集群组成的一个大的系统就是分布式系统。
• 分布式系统需要满足 高可用、高可靠、高性能、高并发。

而刚才小T成立的公司，就好比一个分布式系统。

• 接下来，我们对 高可用、高性能、高并发、高可靠进行一些简单的解释。

1）高可用

• 如果一个服务能够正常使用，那么我们称之为 “可用”，比如你现在能看到这篇文章，说明网站处于 “可用” 状态。
• 可用性定义为在足够长的时间里，一个服务可用的时间，服务可用时间越长越好。
• 一般用可服务时间除于总时间算出一个百分比，用百分比作为度量。比如一个服务如果有 5 个 9 的可用性，指的就是一年里 99.999% 时间里服务都是可用的。
• 按照年度可用性，来看一个表格：

可用时间百分比	可用时间(天)	全年故障(天)	全年故障(可视单位)
90%	365天 x 90% = 328.5天	36.5天	> 1个月
99%	365天 x 99% = 361.35天	3.65天	3.65 天
99.9%	365天 x 99.9% = 364.635天	0.365天	8.76 小时
99.99%	365天 x 99.99% = 364.9635天	0.0365天	52.56 分钟
99.999%	365天 x 99.999% = 364.99635天	0.000365天	5.26 分钟

• 这个表格什么意思呢？
• 从上至下， 9 的个数越多，则代表系统的可用性越高。
• 同样，按照月度可用性，我们同样可以得到一个表格如下：

可用时间百分比	故障时间
90%	3天
99%	7.2小时
99.9%	43.2分钟
99.99%	4.32分钟
99.999%	25.92秒

2）高可靠

• 可靠性定义为一个服务连续无故障运行的时间，无故障运行的时间越长，可靠性就越高。
• 那么可靠性和可用性的区别在哪里呢？
• 想象有一个服务，可靠性很高，平均来说可以稳定运行一百年，但是一旦服务中断，要用十年的时间来恢复，那么它的可用性只有 90%；而另一个服务，可靠性很差，运行 10秒 就会宕机，但是恢复服务只需要1ms, 那么它的可用性是 99.99%。

3）高性能

• 性能对于开发来说是一个老生常谈的问题了，可以简单理解成一个系统某项功能的执行速度。
• 我们平时也无数次的尝试进行性能优化。小到一个 ++i和i++，都有性能区别。

4）高并发

• 高并发是指通过设计保证系统能够同时并行处理很多请求。
• 高并发相关常用的一些指标有：响应时间、吞吐量、QPS、并发用户数。

1. 响应时间

• 系统对请求做出响应的时间。

2. 吞吐量

• 单位时间内处理的请求数量。

3. QPS

• Query Per Second，每秒响应请求数。

4. 并发用户数

• 同时承载正常使用系统功能的用户数量。

四、TDEngine的分布式架构

1、TDEngine 概述

• TDengine 的设计是基于分布式的几个特性而设计的。
• TDengine 采用分布式高可用架构设计，支持水平扩容，这样任何单台或多台服务器发生硬件故障或软件错误都不影响系统的可用性和可靠性。
• 同时，通过节点虚拟化、负载均衡，它能最高效率地利用异构集群中的计算和存储降低硬件资源的投入。

2、分布式架构

• 一个完整的 TDengine 系统是运行在一到多个物理节点上的，逻辑上，它包含数据节点、TDengine客户端以及应用。

-	-
数据节点	dnode
TDEngine 客户端	TAOSC
应用	APP

• 系统中存在一到多个数据节点，这些数据节点组成一个集群。应用通过 taosc 的应用程序接口与 TDengine 集群进行互动。
• 如图所示：
  
• 整个集群由以下几种节点组成：物理节点、数据节点、虚拟节点、管理节点、虚拟节点组、TAOSC，接下来我们一一来介绍这几个节点的用途。

五、TDEngine的进程节点

1、物理节点

物理节点、processnode、pnode

• 物理节点，是一独立运行的、拥有自己的计算、存储和网络能力的计算机，当然，它可以是：
• 1）安装有操作系统的物理机器设备；
• 2）虚拟机，云，例如阿里云、腾讯云等等；
• 3）也可以是容器，例如 Docker；Docker 是一个用于开发，交付和运行应用程序的开放平台。Docker 能够将 应用程序 与 基础架构 分开，从而快速交付软件。

2、数据节点

数据节点、datanode、dnode

• 数据节点，是 TDengine 服务端执行代码 TAOSD 在物理节点上的一个运行实例（也可以认为是一个进程），一个完整的系统中至少需要一个数据节点。如下图红框所示：

• 数据节点包含零到多个逻辑的虚拟节点，至多一个逻辑的管理节点。
• dnode在系统中的唯一标识由实例的 End Point (EP) 。
• EP 是 dnode 所在物理节点的域名和端口的组合。通过配置不同的端口，一个物理节点(一台物理机、虚拟机或容器）可以运行多个实例，或有多个数据节点。

3、虚拟节点

虚拟节点，virtualnode，vnode

• 为更好的支持数据分片、负载均衡，防止数据倾斜，防止某些节点过于高频，数据节点一般会被虚拟化成多个虚拟节点。如下图红框所示：

• 每个虚拟节点都是一个相对独立的工作单元，是时序数据存储的基本单元，具有独立的运行线程、内存空间与持久化存储的路径。
• 一个数据节点上能创建的虚拟节点的数量取决于该数据节点所在物理节点的硬件资源，包括但不限于 内存、CPU、网络带宽 等等。
• 一个虚拟节点只属于一个DataBase，但一个 DataBase 可以有多个虚拟节点。一个虚拟节点除了存储的时序数据外，也保存有所包含的表的 SCHEMA、标签值 等等。
• 一个虚拟节点由所属的数据节点的EP，以及所属的vgroup id在系统内唯一标识，由管理节点创建并管理。

4、管理节点

管理节点，managernode，meta node，mnode

• 管理节点负责所有数据节点运行状态的监控和维护，以及节点之间的负载均衡。
• 同时，管理节点也负责元数据的存储和管理，因此也称为 Meta Node。
• TDengine 集群中可配置最多不超过五个管理节点，它们自动构建成为一个虚拟管理节点组。如图中红框所示：

• 管理节点间采用主从机制进行管理，而且采取强一致性进行数据同步，任何数据更新操作只能在主上进行。
• 管理节点集群的创建由程序自动完成。每个数据节点上至多有一个管理节点，由所属的数据节点的 EP 来唯一标识。
• 每个数据节点通过内部消息交互自动获取整个集群中所有管理节点所在的数据节点的 EP。

5、虚拟节点组

虚拟节点组、virtual group、vgroup

• 不同数据节点上的虚拟节点可以组成一个虚拟节点组来保证系统的高可靠。
• 虚拟节点组内采取主从方式进行管理。
• 写操作只能在 “主虚拟节点” 上进行，系统采用异步复制的方式将数据同步到 “从虚拟节点”，这样确保了一份数据在多个物理节点上有拷贝。
• 一个虚拟节点组里虚拟节点个数就是数据的副本数。如果一个DataBase的副本数为 $n$，系统必须有至少 $n$ 个数据节点。副本数在创建DB时通过参数 replica指定，默认值为1。
• 使用 TDengine 的多副本特性，可以不再需要昂贵的磁盘阵列等存储设备，就可以获得同样的数据高可靠性。
• 虚拟节点组由管理节点创建并管理，并且由管理节点分配一个系统唯一标识符，即vgroup id。如果两个虚拟节点的vgroup id相同，说明他们属于同一个组，数据互为备份。
• 虚拟节点组里虚拟节点的个数是可以动态扩容和缩容的，容许只有一个，也就是没有数据复制。vgroup id是永远不变的，即使一个虚拟节点组被删除，它的唯一标识符也不会被收回重复利用。

6、TAOSC

• TAOSC 是TDengine给应用提供的驱动程序，负责处理应用与集群的交互，内嵌于JDBC、ODBC driver 中，或者C、Python、Go语言连接库里。
• 应用都是通过 TAOSC 而不是直接连接集群中的数据节点与整个集群进行交互的。
• 这个模块负责获取并缓存数据，作透传，将请求转发到正确的数据节点，再把结果返回给应用时，还需要负责最后一级的排序、过滤等操作。

六、TDEngine的进程间通讯

1、通讯方式

• TDengine系统的各个数据节点之间，以及应用驱动与各数据节点之间，都是通过 TCP / UDP 进行通讯的。
• 由于 UDP 更加高效，而且不受连接数的限制，所以 TDengine 除采用TCP做传输之外，还采用UDP。
• 在这基础上，TDengine 实现了自己的超时、重传、确认、序列号等机制，确保了可靠传输 UDP 机制。

传输方式	数据大小	操作类型
UDP	$<15k$	非查询类
TCP	$\ge 15k$	-
TCP	-	查询类

• 同时，TDengine根据配置和数据包，会自动对数据进行压缩/解压缩，数字签名/认证/加密等等处理。对于数据节点之间的数据复制，则采用 TCP 方式进行数据传输。

2、FQDN配置

• 一个数据节点有一个或多个 FQDN (即 Fully Qualified Domain Name)，全限定域名，可以在系统配置文件 taos.cfg 通过参数 fqdn进行指定，如果没有指定，系统将自动获取计算机的hostname作为其 FQDN 。如果节点没有配置 FQDN ，可以直接将该节点的配置参数fqdn设置为它的 IP地址。
• 但不建议使用 IP，因为 IP 地址可变，一旦变化，将让集群无法正常工作。
• 一个数据节点的 EP 由 FQDN + Port 组成。采用 FQDN，需要保证 DNS 服务正常工作，或者在节点以及应用所在的节点配置好 hosts 文件。另外，这个参数值的长度需要控制在 96 个字符以内。为了容错性，尽量配置在 80 个字符以下为宜。

3、端口配置

• 一个数据节点对外的端口由 TDengine 的系统配置参数serverPort决定，对集群内部通讯的端口是serverPort+MAXP，其中这里的 MAXP = 5。
• 集群内数据节点之间的数据复制操作还占有一个 TCP 端口，是 serverPort+10，为支持多线程高效的处理 UDP 数据，每个对内和对外的 UDP 连接，都需要占用 5 个连续的端口。因此一个数据节点总的端口范围为serverPort到serverPort+10，总共11个TCP/UDP端口。
• 使用时，需要确保防火墙将这些端口打开，以备使用。每个数据节点可以配置不同的serverPort。

4、集群对外通讯

• TDengine 集群可以容纳单个、多个甚至几千个数据节点。
• 应用只需要向集群中任何一个数据节点发起连接即可，连接需要提供的网络参数是一数据节点的 EP。通过命令行 CLI 启动应用 TAOS 时，可以通过选项-h来指定数据节点的 FQDN, -P来指定其配置的端口号，如果端口不配置，将采用 TDengine 的系统配置参数 serverPort。

5、集群内部通讯

• 各个数据节点之间通过TCP/UDP进行连接。
• 一个数据节点启动时，将获取 管理节点 所在的 数据节点 的 EP 信息，然后与系统中的 管理节点 建立起连接，交换信息。

获取 管理节点 的 EP 信息有三步：
  1）检查 mnodeEpSet 文件是否存在，如果不存在或不能正常打开获得 管理节点 的 EP 信息，则进入第 2 步；
  2）检查系统配置文件 taos.cfg, 获取节点配置参数 firstEp, secondEp (这两个参数指定的节点可以是不带 管理节点 的普通节点，这样的话，节点被连接时会尝试重定向到 管理节点) 如果不存在或者 taos.cfg 里没有这两个配置参数，或无效，进入第 3 步；
  3）将自己的 EP 设为 管理节点 EP, 并独立运行起来。获取 管理节点 EP列表后，数据节点发起连接，如果连接成功，则成功加入进工作的集群，如果不成功，则尝试 管理节点 EP列表中的下一个。如果都尝试了，但连接都仍然失败，则休眠几秒后，再进行尝试。

6、管理节点的选择

• TDengine逻辑上有管理节点，但没有单独的执行代码，服务器侧只有一套执行代码 taosd （d 意思是 deamon ，即后台、守护进程的意思）。那么哪个数据节点会是管理节点呢？这是系统自动决定的。

原则如下：
  一个数据节点启动时，会检查自己的End Point, 并与获取的管理节点 EP 列表进行比对，如果在其中，该数据节点认为自己应该启动管理节点模块，成为管理节点。如果自己的EP不在管理节点 EP List里，则不启动管理节点模块。在系统的运行过程中，由于负载均衡、宕机等原因，管理节点有可能迁移至新的数据节点，但一切都是透明的，无需人工干预，配置参数的修改，是管理节点自己根据资源做出的决定。

7、动态扩容

• 系统有了一个数据节点后，就已经成为一个工作的系统。

添加新的节点进集群时，有两个步骤：
  1）使用 TDengine CLI 连接到现有工作的数据节点，然后用命令 ”create dnode" 将新的数据节点的 End Point 添加进去;
  2）在新的数据节点的系统配置参数文件taos.cfg里，将firstEp, secondEp参数设置为现有集群中任意两个数据节点的EP即可。

• 具体添加的详细步骤请见详细的用户手册。这样就把集群一步一步的建立起来。

8、节点重定向

• 无论是数据节点还是TAOSC，都是要发起与管理节点的连接，但管理节点是系统自动创建并维护的，因此对于用户来说，并不知道哪个数据节点在运行管理节点。
• TDengine只要求向系统中任何一个工作的数据节点发起连接即可。因为任何一个正在运行的数据节点，都维护有目前运行的管理节点 EP 列表。当收到一个来自新启动的数据节点或者TAOSC的连接请求，如果自己不是管理节点，则将管理节点 EP 列表回复给对方，TAOSC或新启动的数据节点收到这个列表，就重新尝试建立连接。当管理节点 EP 列表发生改变，通过节点之间的消息交互，各个数据节点就很快获取最新列表，并通知 TAOSC。

---

📢博客主页：https://blog.csdn.net/WhereIsHeroFrom
📢欢迎各位 👍点赞 ⭐收藏 📝评论，如有错误请留言指正，非常感谢！
📢本文由 英雄哪里出来 原创，转载请注明出处，首发于 🙉 CSDN 🙉
作者的专栏：
  👉C语言基础专栏《光天化日学C语言》
  👉算法进阶专栏《夜深人静写算法》
  👉C/C++大厂面试专栏《C/C++ 面试 100 例》