tidb是go语言么

是，TiDB采用go语言编写。TiDB是一个分布式NewSQL数据库；它支持水平弹性扩展、ACID事务、标准SQL、MySQL语法和MySQL协议，具有数据强一致的高可用特性。TiDB架构中的PD储存了集群的元信息，如key在哪个TiKV节点；PD还负责集群的负载均衡以及数据分片等。PD通过内嵌etcd来支持数据分布和容错；PD采用go语言编写。

本教程操作环境：windows7系统、GO 1.18版本、Dell G3电脑。

Go 语言不少重量级项目，而国内最牛逼的 Go 开源项目应该就是 TiDB 了吧。TiDB 是一个分布式数据库，很多人可能对此一无所知。今天就跟大家聊聊这个话题。

TiDB设计简单，官网和代码都非常易读，是学习分布式数据库的首选开源项目。

数据库、操作系统和编译器并称为三大系统，可以说是整个计算机软件的基石。

立即学习“go语言免费学习笔记（深入）”；

很多人用过数据库，但是很少有人实现过一个数据库，特别是实现一个分布式数据库。了解数据库的实现原理和细节，一方面可以提高个人技术，对构建其他系统有帮助，另一方面也有利于用好数据库。

一、TiDB简介

TiDB是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。

OLTP：On-Line Transaction Processing，联机事务处理。
OLAP：On-Line Analytical Processing，联机分析处理。

高度兼容 MySQL 5.7

TiDB 高度兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。虽然 TiDB 支持 MySQL 语法和协议，但是 TiDB 是由 PingCAP 团队完全自主开发的产品，并非基于MySQL开发。

MySQL 5.7 生态中的系统工具 (PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper、Myloader)、客户端等均适用于 TiDB。

TiDB 目前还不支持触发器、存储过程、自定义函数、外键。

易用性

TiDB 使用起来很简单，可以将 TiDB 集群当成 MySQL 来用，可以将 TiDB 用在任何以 MySQL 作为后台存储服务的应用中，并且基本上不需要修改应用代码，同时可以用大部分流行的 MySQL 管理工具来管理 TiDB。

只要支持 MySQL Client/Driver 的编程语言，都可以直接使用 TiDB。

支持分布式事务

无论是一个地方的几个节点，还是跨多个数据中心的多个节点，TiDB 均支持 ACID 分布式事务。

TiDB 事务模型灵感源自 Google Percolator 模型，主体是一个两阶段提交协议，并进行了一些实用的优化。该模型依赖于一个时间戳分配器，为每个事务分配单调递增的时间戳，这样就检测到事务冲突。在 TiDB 集群中，PD 承担时间戳分配器的角色。

TiDB不需要像MySQL一样通过支持XA来满足跨数据库事务，TiDO的本身的分布式事务模型无论是在性能上还是在稳定性上都要比 XA 要高出很多，所以不会也不需要支持 XA。

与传统的单机数据库相比，TiDB 具有以下优势：

纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景

简单来说，TiDB 适合具备下面这些特点的场景：

数据量大，单机保存不下不希望做 Sharding 或者懒得做 Sharding访问模式上没有明显的热点需要事务、需要强一致、需要灾备希望 Real-Time HTAP，减少存储链路

五大核心特性

一键水平扩容或者缩容

得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

金融级高可用

数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

实时 HTAP

提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

云原生的分布式数据库

专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。

兼容 MySQL 5.7 协议和 MySQL 生态

兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

四大核心应用场景

对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO

对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

Real-time HTAP 场景

随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

数据汇聚、二次加工处理的场景

当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。

二、快速上手

TiDB 是一个分布式系统。最基础的 TiDB 测试集群通常由 2 个 TiDB 实例、3 个 TiKV 实例、3 个 PD 实例和可选的 TiFlash 实例构成。通过 TiUP Playground，可以快速搭建出上述的一套基础测试集群，步骤如下：

step1、下载并安装 TiUP。

curl --proto '=https' --tlsv1.2 -sSf https://tiup-mirrors.pingcap.com/install.sh | sh

登录后复制

安装完成后显示：

Successfully set mirror to https://tiup-mirrors.pingcap.comDetected shell: bashShell profile:  /home/user/.bashrc/home/user/.bashrc has been modified to add tiup to PATHopen a new terminal or source /home/user/.bashrc to use itInstalled path: /home/user/.tiup/bin/tiup===============================================Have a try:     tiup playground===============================================

登录后复制

step2、声明全局环境变量。 source ${your_shell_profile}

source /home/user/.bashrc

登录后复制

step3、在当前 session 执行以下命令启动集群。

tiup playground

登录后复制

step4、验证。【现在可以像使用MySQL一样使用TiDB啦】

#新开启一个 session 以访问 TiDB 数据库。#使用 TiUP client 连接 TiDB：tiup client#也可使用 MySQL 客户端连接 TiDBmysql --host 127.0.0.1 --port 4000 -u root#通过 http://127.0.0.1:9090 访问 TiDB 的 Prometheus 管理界面。#通过 http://127.0.0.1:2379/dashboard 访问 TiDB Dashboard 页面，默认用户名为 root，密码为空。#通过 http://127.0.0.1:3000 访问 TiDB 的 Grafana 界面，默认用户名和密码都为 admin。

登录后复制

三、TiDB架构原理

在内核设计上，TiDB 分布式数据库将整体架构拆分成了多个模块，各模块之间互相通信，组成完整的 TiDB 系统。对应的架构图如下：

TiDB Server 负责处理SQL相关的逻辑，将SQL语句转成key，通过PD来查找数据具体在哪个TiKV。TiDB本身是无状态的，不存储数据，只负责计算。TiDB采用go语言编写。【相关推荐：Go视频教程】

PD

PD储存了集群的元信息，如key在哪个 TiKV 节点；PD还负责集群的负载均衡以及数据分片等。PD通过内嵌etcd来支持数据分布和容错。PD采用go语言编写。

TiKV Server

TiKV 是一个分布式的提供事务的 Key-Value 存储引擎，基于Google Spanner, HBase 设计，但脱离了底层较为复杂的HDFS。通过RocksDB将key-value值存在本地地盘，使用 Raft 协议做复制，保持数据的一致性和容灾。TiKV采用Rust语言编写。

一、TiDB简介

TiDB是一个分布式 NewSQL 数据库。它支持水平弹性扩展、ACID 事务、标准 SQL、MySQL 语法和 MySQL 协议，具有数据强一致的高可用特性，是一个不仅适合 OLTP 场景还适合 OLAP 场景的混合数据库。

OLTP：On-Line Transaction Processing，联机事务处理。
OLAP：On-Line Analytical Processing，联机分析处理。

高度兼容 MySQL 5.7

TiDB 高度兼容 MySQL 5.7 协议、MySQL 5.7 常用的功能及语法。虽然 TiDB 支持 MySQL 语法和协议，但是 TiDB 是由 PingCAP 团队完全自主开发的产品，并非基于MySQL开发。

MySQL 5.7 生态中的系统工具 (PHPMyAdmin、Navicat、MySQL Workbench、mysqldump、Mydumper、Myloader)、客户端等均适用于 TiDB。

TiDB 目前还不支持触发器、存储过程、自定义函数、外键。

易用性

TiDB 使用起来很简单，可以将 TiDB 集群当成 MySQL 来用，可以将 TiDB 用在任何以 MySQL 作为后台存储服务的应用中，并且基本上不需要修改应用代码，同时可以用大部分流行的 MySQL 管理工具来管理 TiDB。

只要支持 MySQL Client/Driver 的编程语言，都可以直接使用 TiDB。

支持分布式事务

无论是一个地方的几个节点，还是跨多个数据中心的多个节点，TiDB 均支持 ACID 分布式事务。

TiDB 事务模型灵感源自 Google Percolator 模型，主体是一个两阶段提交协议，并进行了一些实用的优化。该模型依赖于一个时间戳分配器，为每个事务分配单调递增的时间戳，这样就检测到事务冲突。在 TiDB 集群中，PD 承担时间戳分配器的角色。

TiDB不需要像MySQL一样通过支持XA来满足跨数据库事务，TiDO的本身的分布式事务模型无论是在性能上还是在稳定性上都要比 XA 要高出很多，所以不会也不需要支持 XA。

与传统的单机数据库相比，TiDB 具有以下优势：

纯分布式架构，拥有良好的扩展性，支持弹性的扩缩容支持 SQL，对外暴露 MySQL 的网络协议，并兼容大多数 MySQL 的语法，在大多数场景下可以直接替换 MySQL默认支持高可用，在少数副本失效的情况下，数据库本身能够自动进行数据修复和故障转移，对业务透明支持 ACID 事务，对于一些有强一致需求的场景友好，例如：银行转账具有丰富的工具链生态，覆盖数据迁移、同步、备份等多种场景

简单来说，TiDB 适合具备下面这些特点的场景：

数据量大，单机保存不下不希望做 Sharding 或者懒得做 Sharding访问模式上没有明显的热点需要事务、需要强一致、需要灾备希望 Real-Time HTAP，减少存储链路

五大核心特性

一键水平扩容或者缩容

得益于 TiDB 存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。

金融级高可用

数据采用多副本存储，数据副本通过 Multi-Raft 协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。

实时 HTAP

提供行存储引擎 TiKV、列存储引擎 TiFlash 两款存储引擎，TiFlash 通过 Multi-Raft Learner 协议实时从 TiKV 复制数据，确保行存储引擎 TiKV 和列存储引擎 TiFlash 之间的数据强一致。TiKV、TiFlash 可按需部署在不同的机器，解决 HTAP 资源隔离的问题。

云原生的分布式数据库

专为云而设计的分布式数据库，通过 TiDB Operator 可在公有云、私有云、混合云中实现部署工具化、自动化。

兼容 MySQL 5.7 协议和 MySQL 生态

兼容 MySQL 5.7 协议、MySQL 常用的功能、MySQL 生态，应用无需或者修改少量代码即可从 MySQL 迁移到 TiDB。提供丰富的数据迁移工具帮助应用便捷完成数据迁移。

四大核心应用场景

对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高的金融行业属性的场景

众所周知，金融行业对数据一致性及高可靠、系统高可用、可扩展性、容灾要求较高。传统的解决方案是同城两个机房提供服务、异地一个机房提供数据容灾能力但不提供服务，此解决方案存在以下缺点：资源利用率低、维护成本高、RTO (Recovery Time Objective) 及 RPO (Recovery Point Objective) 无法真实达到企业所期望的值。TiDB 采用多副本 + Multi-Raft 协议的方式将数据调度到不同的机房、机架、机器，当部分机器出现故障时系统可自动进行切换，确保系统的 RTO

对存储容量、可扩展性、并发要求较高的海量数据及高并发的 OLTP 场景

随着业务的高速发展，数据呈现爆炸性的增长，传统的单机数据库无法满足因数据爆炸性的增长对数据库的容量要求，可行方案是采用分库分表的中间件产品或者 NewSQL 数据库替代、采用高端的存储设备等，其中性价比最大的是 NewSQL 数据库，例如：TiDB。TiDB 采用计算、存储分离的架构，可对计算、存储分别进行扩容和缩容，计算最大支持 512 节点，每个节点最大支持 1000 并发，集群容量最大支持 PB 级别。

Real-time HTAP 场景

随着 5G、物联网、人工智能的高速发展，企业所生产的数据会越来越多，其规模可能达到数百 TB 甚至 PB 级别，传统的解决方案是通过 OLTP 型数据库处理在线联机交易业务，通过 ETL 工具将数据同步到 OLAP 型数据库进行数据分析，这种处理方案存在存储成本高、实时性差等多方面的问题。TiDB 在 4.0 版本中引入列存储引擎 TiFlash 结合行存储引擎 TiKV 构建真正的 HTAP 数据库，在增加少量存储成本的情况下，可以在同一个系统中做联机交易处理、实时数据分析，极大地节省企业的成本。

数据汇聚、二次加工处理的场景

当前绝大部分企业的业务数据都分散在不同的系统中，没有一个统一的汇总，随着业务的发展，企业的决策层需要了解整个公司的业务状况以便及时做出决策，故需要将分散在各个系统的数据汇聚在同一个系统并进行二次加工处理生成 T+0 或 T+1 的报表。传统常见的解决方案是采用 ETL + Hadoop 来完成，但 Hadoop 体系太复杂，运维、存储成本太高无法满足用户的需求。与 Hadoop 相比，TiDB 就简单得多，业务通过 ETL 工具或者 TiDB 的同步工具将数据同步到 TiDB，在 TiDB 中可通过 SQL 直接生成报表。

二、快速上手

TiDB 是一个分布式系统。最基础的 TiDB 测试集群通常由 2 个 TiDB 实例、3 个 TiKV 实例、3 个 PD 实例和可选的 TiFlash 实例构成。通过 TiUP Playground，可以快速搭建出上述的一套基础测试集群，步骤如下：

step1、下载并安装 TiUP。

#简单来说，没有 MVCC 之前，可以把 TiKV 看做这样的Key1 -> ValueKey2 -> Value……KeyN -> Value#有了 MVCC 之后，TiKV 的 Key 排列是这样的：Key1-Version3 -> ValueKey1-Version2 -> ValueKey1-Version1 -> Value……Key2-Version4 -> ValueKey2-Version3 -> ValueKey2-Version2 -> ValueKey2-Version1 -> Value……KeyN-Version2 -> ValueKeyN-Version1 -> Value……

登录后复制

安装完成后显示：

以上就是tidb是go语言么的详细内容，更多请关注【创想鸟】其它相关文章！