本文向您介绍分布式数据库和TIDB的整体架构。内容非常详细。感兴趣的朋友可以参考一下，希望对你有所帮助。
TIDB是一个分布式、强一致性和水平可扩展的关系数据库。在TIDB设计之初，它专注于四个设计点。
1横向扩展，横向扩展是设计之初最基本的要求，通过增加机器来扩展存储容量和计算能力。
2高可用性，TIDB是一个具有许多节点的分布式数据库。对于节点故障和数据库滚动升级，需要解决少量节点故障的问题。
Acid事务，虽然有些数据库为了更高效地存储和处理数据，放弃了SQL和事务，但是在生产中的事务场景中，事务是非常重要的。另一个主要原因是，如果事务的问题不是存储在本地，而是通过业务或中间件来解决，很难实现高效率。
4SQL支持，MYSQL支持，使得数据库整体使用变得容易。
下面是TIDB的结构图。
TIDB存储引擎是TIKV数据库存储引擎，采用分层架构实现。
1笔交易
2 MVCC
3筏
4本地kv存储
容灾能力和特点
高度分层，底层为ROCKSDB，数据存储通过raft高度可用。高度分层的主要原因是分层切换可以更独立地进行。数据存储在多个副本中，通过raft实现了很强的一致性。多个副本中只有一个领导者，其他节点都是追随者。其中，领导者和追随者的价值观是不固定的。领导者失败后，通过算法选择追随者转变为领导者的角色转换。
Raft本身支持一个数据的强大且一致的多个副本。如何对分布式数据进行切片，如何将不同的切片放在不同的位置，需要一种基于哈希切片或范围划分的切片算法。但是，因为数据库可能涉及连续的值查询，所以使用范围切片更合理。划分存储KEY的空间，主要是根据KEY VALUE存储的阈值，默认将数据除以96MB。
下图显示了多节点系统中节点区域从节点1到节点4的过程。
那么问题来了，在数据迁移的过程中，谁来控制整个迁移，Placement Driver集群来控制。
如上图所示，另外，在事务模型中，PD的领导者会根据时间算法提供一个时间戳作为事务的标签，整体设计理念是去中心化。在3.0之前，乐观锁被用作锁，它不是在数据事务中被锁定，而是在提交过程中被锁定。3.0提供悲观锁，类似于传统数据库的锁设计。
Tidbsql引擎
下图是整个TIDB SQL层的图表。
如果计算COUNT，那么TIDB PD知道这些数据在哪个区域，并且该区域根据条件在哪里累加和求和满足条件的数据。最后，每个区域将自己的累计和汇总到TIDB服务器，并汇总该和。
4 DDL在线修改，TIDB按照f1-schema-change的思路设计整个DDL操作。可以具体参考以下文献，总结几句。
1给出修改DDL操作的时间范围。
2在DDL操作中，每个区域将提供两种状态，可以删除也可以写入。
3租约的概念，在系统中设置的租约到期后，需要重新加载SCHEMA。
什么是分布式数据库和TIDB的整体架构将在这里分享，我希望
内容来源网络，如有侵权，联系删除，本文地址：https://www.230890.com/zhan/129610.html