TDDMS揭秘（七）Raft一致性协议在TDDMS中发挥了什么作用？承担了什么角色？
友情链接：
- 星环分布式存储TDDMS大揭秘（一）分布式存储技术推出背景以及当前存在的挑战
- 星环分布式存储TDDMS大揭秘（二）TDDMS是什么
- TDDMS揭秘（三）分布式一致性技术是如何实现的（上）
- TDDMS揭秘（四）一致性协议Raft的工作原理及介绍--Raft协议背景及算法初剖析（中）
- TDDMS揭秘（五）一致性协议Raft的工作原理及介绍--领导者选举及日志复制算法详解（中下）
- TDDMS揭秘（六）一致性协议Raft的工作原理及介绍--安全属性及快照机制（下）
多模态数据的统一处理
TDDMS将数据库中的一张表(table)根据一定的分片规则划分成多个数据分片(tablet)，每个tablet包含若干副本，组成一个raft group；通过共识协议各数据副本达成一致。对每个tablet的数据变更操作通过raft算法提交后，在各个tablet上按提交序执行；对数据的读请求最终发送到tablet的某个副本上执行。
显然，分布式协议层并不需要感知底层存储引擎的具体实现，反之底层引擎也不需要关注分布式协议层的具体逻辑，而只需要被动执行确定的读写请求。TDDMS将底层存储引擎抽象成一组接口，实现了底层存储引擎的解耦，使得一套分布式数据库管理系统可以管理多种存储引擎，可以通过实现插件扩展存储能力，针对不同的业务场景提供不同的存储引擎实现，无需再为每类业务场景提供单独的存储引擎，降低开发成本。
TDDMS底层存储引擎拥有以下接口：
a) 数据分片接口
每张表Tablet的分布决定了表的数据实际存放在多少块磁盘上，直接影响了表的读写性能，因此TDDMS提供了多种tablet分布的规则。该接口定义了表的分片规则以及请求的路由规则；
b) 读写接口
提供了多存储引擎的数据修改、读取等操作的接口；
c) Recovery相关接口
快照（Snapshot）将某一时刻系统的状态 dump 下来并落地存储，这样该时刻之前的所有日志就都可以丢弃了，不会再继续占用存储空间。Recovery相关的接口可以创建、使用快照。比如当某个tablet需要为raft group添加新的成员时，可以创建一个用于恢复新成员数据的物理快照，后续可以完整的同步到新成员上。
d) 执行环境相关接口
该接口是为了一些特殊的执行环境所准备，比如非native的存储引擎需要初始化jvm。值得一提的是，TDDMS针对非native存储引擎采用了新的创新点，充分解决了由于JVM自身限制而无法充分发挥大内存机器能力的问题。
正如本系列最开始的内容所介绍的，TDDMS本身不对外提供数据/文件存储服务，而是通过与存储引擎结合的方式，对接不同的存储引擎插件。TDDMS的数据存储方式是对DB-Engine透明的，能够协同处理多模态数据（二维数组、全文检索数据、键值数据等），支持多种不同的数据模型，为不同的数据模型提供了格式化的数据读写接口，便于分布式计算引擎进行数据读写等操作，真正实现了多源数据的高效融合、统一处理。
两地三中心
伴随互联网、移动互联网、物联网、5G等信息通信技术及产业的发展，全球数据量呈现爆发式增长的趋势。对于企业而言，数据已成为数字经济中最重要的资产。核心业务系统作为支撑用户服务的关键，往往具备业务连续性高、并发请求量大、业务激增随机性强的特点，一旦发生故障，其影响范围更广，后果更严重。现阶段，多项政策均明确了灾备中心对于业务系统的重要性，例如《商业银行数据中心监管指引》要求“...其他法人商业银行应设立同城模式灾备中心并实现数据异地备份...”。据STL（2022）调查显示，到2030年，全球数据中心行业价值预计将达到5171.7亿美元。
数据中心对于企业来说提供了一个专用、经济高效、可扩展且安全的解决方案，通过将数据中心分布在不同国家或地区，可以更好地满足企业在数据管理、存储、安全性、合规性等方面的需求。“两地三中心”则指的是一种可以满足监管要求的容灾架构，其中，两地是指同城、异地，三中心是指生产中心、同城容灾中心、异地容灾中心。
通过将业务系统分布在两个地理位置上，并在每个地点都建立数据中心的方式实现了高可用等特性。业务系统在任何一个数据中心发生故障不可用时，其他数据中心可以接管业务并提供服务继续运行。由于业务系统分布在多个地理位置和多个数据中心上，所以两地三中心的架构能够提供灾备能力，为数据中心做好应对意外事件的准备，譬如电源故障、网络攻击或硬件问题等等。如果一个地点或一个数据中心遭受不可预测的灾害，其他地点和数据中心可以继续提供服务，降低RTO和RPO。通过多个数据中心的部署，实现负载均衡。负载可以根据实际情况在不同数据中心之间动态分配，以提高系统的性能和响应能力。
两地三中心的架构挑战
两地三中心架构需要在多个地点和数据中心上部署和管理系统，增加了部署和维护的复杂性。因此需要确保各个数据中心之间的通信和同步，以及数据的一致性和可靠性。
基于TDDMS打造的分布式存储管理系统支持跨数据中心部署，实现了“两地三中心”等部署方式，支持在多个数据中心之间分发相同的目录服务数据副本。其中，多个数据中心的分布和同步均由TDDMS完成，通过tabletserver组成的raft group可以进一步保证跨数据中心的数据一致性。
星环两地三中心方案架构图示例
涉及的相关术语：
- 分片（Tablet）：分布式系统中, 为了减少数据增长对系统带来的影响, 同时提升系统的并发处理能力,通常会将数据分为多个分片存储, 不同的分片存储不同的数据；分片是数据分布的基本单位；
- 副本：分布式系统中, 为了增加系统的可用性, 对于同一份数据, 会存储多份, 这些相同的数据称之为数据的一个副本；
- Raft group：由于副本之间通过raft协议同步数据, 因此我们习惯上将通过raft协议同步数据的副本称为一个raft group。例如，同一分片的所有副本之间构成了一个 raft group；
- Leader：对于同一份数据的多个副本, TDDMS会指定一个副本为leader, 客户端的读写操作均发往leader上；相对地, 除 leader 外的副本我们称之为follower；
- Learner：最终决策的学习者，学习者充当该协议的复制因素(不参与投票) ;
- membership：一个raft group内的所有副本, 共同组成了这个raft group的membership; 当发生副本增加和副本删除的动作时, 该raft group对应的membership也会随之发生改变；
- TDDMS Master：负责存储数据的元信息，包括index元信息，集群元信息等。一般由3或5个一组，内部通过Raft算法保证每个Master内元数据的一致性，并选出Leader统一对外提供服务。因此所有的master也组成了一个raft group；
- TDDMS Tablet Server：每个节点部署一个实例，负责管理该节点所配置的磁盘上的数据存储，并记录数据的信息；
- WebServer：负责监控TDDMS集群的状态，包括Master和Tablet Server，并提供运维管理能力，以及各类Restful API服务。一般一个集群配置一个WebServer即可；
架构分解
为了能更好地理解整个多中心的架构，下面我们将把架构分解为以下几个部分分开讲解，同时也方便您回顾前述章节有关Raft的算法逻辑，希望能对您了解系统的整体运行有帮助。
1) 写操作
如图所示，对于写请求，客户端首先从master处获取要写的表的元信息（主要包含各个分片的元信息），接着客户端根据分片元信息，将写请求发送至对应的tablet server，在tablet server管理的数据分片上先写leader，leader收到客户端发送的写请求，经过 raft 算法在副本之间达成共识同步至follower（具体详见前述章节的介绍），写入日志之后各副本尝试应用写请求，满足leader+follower的1/2以上写完即可回复客户端写成功。需要注意的是这里的master可以有多个副本，若有多个副本，只从leader上获取信息。
2) 读操作
Computing从Master Leader获取表的Tablet信息后，在访问各节点的Tablet Server，获取具体的数据。
如图所示，对于读请求，客户端首先从master处获取要读的表的元信息（主要包含各个分片的元信息），接着客户端根据分片元信息，将读请求发送至各个分片的leader上。Leader响应读请求，生成回复，发送给客户端。需要注意的是这里的master可以有多个副本，若有多个副本，只从leader上获取信息。
3) 跨中心复制
数据可以通过由TDDMS Tablet Server组成的raft group提供的raft机制来保证跨数据中心的数据一致性。
此处解锁一个新角色：DataBlock。在跨中心同步的场景下，同样采用的是Raft机制，通过将数据切分为一个个的datablock进行数据同步。
如上图所示，跨中心的数据同步分为强一致性与最终一致性。一致性指的是说每次发出相同的请求时，数据库查询都返回相同的数据。
强一致性意味着返回最新的数据，当在数据库中进行更新时，该更新最终将反映在存储数据的所有节点中，因此每次查询数据时都会得到相同的响应。但是由于内部一致性方法，可能会存在一定延迟。
最终一致性关键在于“最终”二字，指的是经过一段时间后，最终一定能够达到符合业务定义的一致的状态。虽然在早期最新结果不像强一致性那么一致，因为数据更新需要一定时间才能到达数据库集群中的副本，但提供速度更快且延迟较低。
因此，星环提供了两种不同的同步方式，既保证了所有副本节点最终可以达到相同的数据状态，又保障了数据能够第一时间更新到不同的数据中心。多个数据中心提供了可扩展的部署模型，提供了负载平衡以及在节点或数据中心之一发生故障时的故障转移的能力，能够支持数百万用户的访问管理需求，更加贴合业务场景。
星环“两地三中心”的方案提供了两种不同的数据同步方式，既保证了所有副本节点最终可以达到相同的数据状态，又确保数据能够第一时间更新到不同的数据中心，进而保障企业数据不丢失，应用不中断，提供数据灾备能力和实时故障迁移能力的同时，也更加贴合企业用户的使用。
架构总结
以上就是架构分解，合起来就组成了上图的架构图，可能这个时候大家会注意到Master的部署是以2-2-1的结构进行分布，为什么不以3-1-1的结构是因为假设部署三个master的数据中心出现断电等灾难，那么则有超过一半的server将不可用，将无法对外提供服务。TDDMS采用的是Raft协议，多数派有效机制，2-2-1的结构可以保证任意一个数据中心发生灾难的情况下，多数派可以存活，确保了服务的可用性。
其次，master遵循Raft选主，如果只部3个master每个中心分别部一个，其中一个数据中心坏了则无法选主，因此在两地三中心方案中通常为2-2-1的结构。
同理，容灾表也通常为5副本（2-2-1的结构）。3副本的情况下很容易造成3个副本都在某个数据中心或者一个数据中心2个副本，另一个数据中心一个副本，从而导致存在某个数据中心无数据的情况，不能满足两地三中心的需求，所以一般使用5副本。相比于3副本来说，5副本有更好的数据容错性。同样，2-2-1的架构可以保障任意一个机房故障，不丢数据，并且事务延迟不受影响。但是具体是2-2-1的结构还是3-1-1需要结合业务场景去进行调整。3-1-1结构存在的好处是3个副本会写在指定的datacenter上，可以更快速的达成写操作的共识，2-1-1的情况下，会有1副本跨数据中心，可能会存在延迟。所以如何使用还需要考虑不同的场景，根据不同的场景去进行设置。
星环产品提供了丰富的参数来辅助搭建客户两地三中心系统，比如指定是否需要进行灾备将副本分配在不同的数据中心、指定副本分配结构、将表leader优先分布到指定的数据中心等等。通过设置不同的参数实现性能提升，系统快速响应等效果。
以上就是完整的有关TDDMS中如何实现数据一致性的内容。下一个系列我们将为您介绍TDDMS是如何确保系统可以快速的找到元数据和数据，提供数据读写能力的。
...未完待续
友情链接：
- 星环分布式存储TDDMS大揭秘（一）分布式存储技术推出背景以及当前存在的挑战
- 星环分布式存储TDDMS大揭秘（二）TDDMS是什么
- TDDMS揭秘（三）分布式一致性技术是如何实现的（上）
- TDDMS揭秘（四）一致性协议Raft的工作原理及介绍--Raft协议背景及算法初剖析（中）
- TDDMS揭秘（五）一致性协议Raft的工作原理及介绍--领导者选举及日志复制算法详解（中下）
- TDDMS揭秘（六）一致性协议Raft的工作原理及介绍--安全属性及快照机制（下）
多模态数据的统一处理
TDDMS将数据库中的一张表(table)根据一定的分片规则划分成多个数据分片(tablet)，每个tablet包含若干副本，组成一个raft group；通过共识协议各数据副本达成一致。对每个tablet的数据变更操作通过raft算法提交后，在各个tablet上按提交序执行；对数据的读请求最终发送到tablet的某个副本上执行。
显然，分布式协议层并不需要感知底层存储引擎的具体实现，反之底层引擎也不需要关注分布式协议层的具体逻辑，而只需要被动执行确定的读写请求。TDDMS将底层存储引擎抽象成一组接口，实现了底层存储引擎的解耦，使得一套分布式数据库管理系统可以管理多种存储引擎，可以通过实现插件扩展存储能力，针对不同的业务场景提供不同的存储引擎实现，无需再为每类业务场景提供单独的存储引擎，降低开发成本。
TDDMS底层存储引擎拥有以下接口：
a) 数据分片接口
每张表Tablet的分布决定了表的数据实际存放在多少块磁盘上，直接影响了表的读写性能，因此TDDMS提供了多种tablet分布的规则。该接口定义了表的分片规则以及请求的路由规则；
b) 读写接口
提供了多存储引擎的数据修改、读取等操作的接口；
c) Recovery相关接口
快照（Snapshot）将某一时刻系统的状态 dump 下来并落地存储，这样该时刻之前的所有日志就都可以丢弃了，不会再继续占用存储空间。Recovery相关的接口可以创建、使用快照。比如当某个tablet需要为raft group添加新的成员时，可以创建一个用于恢复新成员数据的物理快照，后续可以完整的同步到新成员上。
d) 执行环境相关接口
该接口是为了一些特殊的执行环境所准备，比如非native的存储引擎需要初始化jvm。值得一提的是，TDDMS针对非native存储引擎采用了新的创新点，充分解决了由于JVM自身限制而无法充分发挥大内存机器能力的问题。
正如本系列最开始的内容所介绍的，TDDMS本身不对外提供数据/文件存储服务，而是通过与存储引擎结合的方式，对接不同的存储引擎插件。TDDMS的数据存储方式是对DB-Engine透明的，能够协同处理多模态数据（二维数组、全文检索数据、键值数据等），支持多种不同的数据模型，为不同的数据模型提供了格式化的数据读写接口，便于分布式计算引擎进行数据读写等操作，真正实现了多源数据的高效融合、统一处理。
两地三中心
伴随互联网、移动互联网、物联网、5G等信息通信技术及产业的发展，全球数据量呈现爆发式增长的趋势。对于企业而言，数据已成为数字经济中最重要的资产。核心业务系统作为支撑用户服务的关键，往往具备业务连续性高、并发请求量大、业务激增随机性强的特点，一旦发生故障，其影响范围更广，后果更严重。现阶段，多项政策均明确了灾备中心对于业务系统的重要性，例如《商业银行数据中心监管指引》要求“...其他法人商业银行应设立同城模式灾备中心并实现数据异地备份...”。据STL（2022）调查显示，到2030年，全球数据中心行业价值预计将达到5171.7亿美元。
数据中心对于企业来说提供了一个专用、经济高效、可扩展且安全的解决方案，通过将数据中心分布在不同国家或地区，可以更好地满足企业在数据管理、存储、安全性、合规性等方面的需求。“两地三中心”则指的是一种可以满足监管要求的容灾架构，其中，两地是指同城、异地，三中心是指生产中心、同城容灾中心、异地容灾中心。
通过将业务系统分布在两个地理位置上，并在每个地点都建立数据中心的方式实现了高可用等特性。业务系统在任何一个数据中心发生故障不可用时，其他数据中心可以接管业务并提供服务继续运行。由于业务系统分布在多个地理位置和多个数据中心上，所以两地三中心的架构能够提供灾备能力，为数据中心做好应对意外事件的准备，譬如电源故障、网络攻击或硬件问题等等。如果一个地点或一个数据中心遭受不可预测的灾害，其他地点和数据中心可以继续提供服务，降低RTO和RPO。通过多个数据中心的部署，实现负载均衡。负载可以根据实际情况在不同数据中心之间动态分配，以提高系统的性能和响应能力。
两地三中心的架构挑战
两地三中心架构需要在多个地点和数据中心上部署和管理系统，增加了部署和维护的复杂性。因此需要确保各个数据中心之间的通信和同步，以及数据的一致性和可靠性。
基于TDDMS打造的分布式存储管理系统支持跨数据中心部署，实现了“两地三中心”等部署方式，支持在多个数据中心之间分发相同的目录服务数据副本。其中，多个数据中心的分布和同步均由TDDMS完成，通过tabletserver组成的raft group可以进一步保证跨数据中心的数据一致性。
星环两地三中心方案架构图示例
涉及的相关术语：
- 分片（Tablet）：分布式系统中, 为了减少数据增长对系统带来的影响, 同时提升系统的并发处理能力,通常会将数据分为多个分片存储, 不同的分片存储不同的数据；分片是数据分布的基本单位；
- 副本：分布式系统中, 为了增加系统的可用性, 对于同一份数据, 会存储多份, 这些相同的数据称之为数据的一个副本；
- Raft group：由于副本之间通过raft协议同步数据, 因此我们习惯上将通过raft协议同步数据的副本称为一个raft group。例如，同一分片的所有副本之间构成了一个 raft group；
- Leader：对于同一份数据的多个副本, TDDMS会指定一个副本为leader, 客户端的读写操作均发往leader上；相对地, 除 leader 外的副本我们称之为follower；
- Learner：最终决策的学习者，学习者充当该协议的复制因素(不参与投票) ;
- membership：一个raft group内的所有副本, 共同组成了这个raft group的membership; 当发生副本增加和副本删除的动作时, 该raft group对应的membership也会随之发生改变；
- TDDMS Master：负责存储数据的元信息，包括index元信息，集群元信息等。一般由3或5个一组，内部通过Raft算法保证每个Master内元数据的一致性，并选出Leader统一对外提供服务。因此所有的master也组成了一个raft group；
- TDDMS Tablet Server：每个节点部署一个实例，负责管理该节点所配置的磁盘上的数据存储，并记录数据的信息；
- WebServer：负责监控TDDMS集群的状态，包括Master和Tablet Server，并提供运维管理能力，以及各类Restful API服务。一般一个集群配置一个WebServer即可；
架构分解
为了能更好地理解整个多中心的架构，下面我们将把架构分解为以下几个部分分开讲解，同时也方便您回顾前述章节有关Raft的算法逻辑，希望能对您了解系统的整体运行有帮助。
1) 写操作
如图所示，对于写请求，客户端首先从master处获取要写的表的元信息（主要包含各个分片的元信息），接着客户端根据分片元信息，将写请求发送至对应的tablet server，在tablet server管理的数据分片上先写leader，leader收到客户端发送的写请求，经过 raft 算法在副本之间达成共识同步至follower（具体详见前述章节的介绍），写入日志之后各副本尝试应用写请求，满足leader+follower的1/2以上写完即可回复客户端写成功。需要注意的是这里的master可以有多个副本，若有多个副本，只从leader上获取信息。
2) 读操作
Computing从Master Leader获取表的Tablet信息后，在访问各节点的Tablet Server，获取具体的数据。
如图所示，对于读请求，客户端首先从master处获取要读的表的元信息（主要包含各个分片的元信息），接着客户端根据分片元信息，将读请求发送至各个分片的leader上。Leader响应读请求，生成回复，发送给客户端。需要注意的是这里的master可以有多个副本，若有多个副本，只从leader上获取信息。
3) 跨中心复制
数据可以通过由TDDMS Tablet Server组成的raft group提供的raft机制来保证跨数据中心的数据一致性。
此处解锁一个新角色：DataBlock。在跨中心同步的场景下，同样采用的是Raft机制，通过将数据切分为一个个的datablock进行数据同步。
如上图所示，跨中心的数据同步分为强一致性与最终一致性。一致性指的是说每次发出相同的请求时，数据库查询都返回相同的数据。
强一致性意味着返回最新的数据，当在数据库中进行更新时，该更新最终将反映在存储数据的所有节点中，因此每次查询数据时都会得到相同的响应。但是由于内部一致性方法，可能会存在一定延迟。
最终一致性关键在于“最终”二字，指的是经过一段时间后，最终一定能够达到符合业务定义的一致的状态。虽然在早期最新结果不像强一致性那么一致，因为数据更新需要一定时间才能到达数据库集群中的副本，但提供速度更快且延迟较低。
因此，星环提供了两种不同的同步方式，既保证了所有副本节点最终可以达到相同的数据状态，又保障了数据能够第一时间更新到不同的数据中心。多个数据中心提供了可扩展的部署模型，提供了负载平衡以及在节点或数据中心之一发生故障时的故障转移的能力，能够支持数百万用户的访问管理需求，更加贴合业务场景。
星环“两地三中心”的方案提供了两种不同的数据同步方式，既保证了所有副本节点最终可以达到相同的数据状态，又确保数据能够第一时间更新到不同的数据中心，进而保障企业数据不丢失，应用不中断，提供数据灾备能力和实时故障迁移能力的同时，也更加贴合企业用户的使用。
架构总结
以上就是架构分解，合起来就组成了上图的架构图，可能这个时候大家会注意到Master的部署是以2-2-1的结构进行分布，为什么不以3-1-1的结构是因为假设部署三个master的数据中心出现断电等灾难，那么则有超过一半的server将不可用，将无法对外提供服务。TDDMS采用的是Raft协议，多数派有效机制，2-2-1的结构可以保证任意一个数据中心发生灾难的情况下，多数派可以存活，确保了服务的可用性。
其次，master遵循Raft选主，如果只部3个master每个中心分别部一个，其中一个数据中心坏了则无法选主，因此在两地三中心方案中通常为2-2-1的结构。
同理，容灾表也通常为5副本（2-2-1的结构）。3副本的情况下很容易造成3个副本都在某个数据中心或者一个数据中心2个副本，另一个数据中心一个副本，从而导致存在某个数据中心无数据的情况，不能满足两地三中心的需求，所以一般使用5副本。相比于3副本来说，5副本有更好的数据容错性。同样，2-2-1的架构可以保障任意一个机房故障，不丢数据，并且事务延迟不受影响。但是具体是2-2-1的结构还是3-1-1需要结合业务场景去进行调整。3-1-1结构存在的好处是3个副本会写在指定的datacenter上，可以更快速的达成写操作的共识，2-1-1的情况下，会有1副本跨数据中心，可能会存在延迟。所以如何使用还需要考虑不同的场景，根据不同的场景去进行设置。
星环产品提供了丰富的参数来辅助搭建客户两地三中心系统，比如指定是否需要进行灾备将副本分配在不同的数据中心、指定副本分配结构、将表leader优先分布到指定的数据中心等等。通过设置不同的参数实现性能提升，系统快速响应等效果。
以上就是完整的有关TDDMS中如何实现数据一致性的内容。下一个系列我们将为您介绍TDDMS是如何确保系统可以快速的找到元数据和数据，提供数据读写能力的。
...未完待续
登录后可评论
.jpg)
