头图
CSDN下载自东方IC
作者
凯文Garnett责编
张文
来源
Garnett的Java之路（ID：gh_af52d4）
随着互联网的发展，业务越来越庞大，客户群体也越来越多，所要存储的数据也越来越多，慢慢的就出现了分库分表的中间件。比如cobar、TDDL、atlas、sharding-jdbc、mycat等，都是非常优秀的产品，解决了各种问题。但是引入了中间件肯定就会增加各方面的维护成本，这篇带大家了解一款替代分库分表的解决方案：分布式数据库：TiDB
前言
如今硬件的性价比越来越高，网络传输速度越来越快，数据库分层的趋势逐渐显现，人们已经不再强求用一个解决方案来解决所有的存储问题，而是通过分层，让缓存与数据库负责各自擅长的业务场景。
当前数据库领域面临各种问题，如在缩放、一致性、大数据分析、与云基础架构集成等方面均存在诸多问题。现有的数据库解决方案和大数据分析引擎解决方案基本处于割裂的状态。由于Oracle、MySQL数据库并不是面向分布式环境而设计，因此即使勉强通过分库、分表或中间件的方式，在数据库层面做了分片，从本质上看也只是复制了相同的堆栈，而非针对分布式系统进行存储和计算优化，这正是进行跨业务查询或跨物理机查询和写入十分繁琐的本质原因。NoSQL虽然解决了数据库弹性扩展的难题，但是却放弃了数据的强一致性以及对ACID事务的支持，带来了新的问题。
为了解决这一问题，TiDB在架构上将计算和存储层进行高度的抽象和分离，对混合负载的场景通过IO优先级队列，智能副本调度，行列混合存储等技术使其变为可能。
大家可能都没有听过TiDB这款分布式数据库，但是它已经出现很久了，随着不断完善，也受到越来越多的企业喜爱，接下来让我们开始了解TiDB吧！
TiDB简介
2.1TiDB是什么？
TiDB是一个分布式NewSQL数据库。它支持水平弹性扩展、ACID事务、标准SQL、MySQL语法和MySQL协议，具有数据强一致的高可用特性，是一个不仅适合OLTP场景还适合OLAP场景的混合数据库。
2.2TiDB怎么来的？
开源分布式缓存服务Codis的作者、PingCAP联合创始人CTO、资深infrastructure工程师的黄东旭，擅长分布式存储系统的设计与实现，开源狂热分子的技术大神级别人物。即使在互联网如此繁荣的今天，在数据库这片边界模糊且不确定地带，他还在努力寻找确定性的实践方向。
年底，他看到Google发布的两篇论文，受到了很大的触动，这两篇论文描述了Google内部使用的一个海量关系型数据库F1/Spanner，解决了关系型数据库、弹性扩展以及全球分布的问题，并在生产中大规模使用。“如果这个能实现，对数据存储领域来说将是颠覆性的”，黄东旭为完美方案的出现而兴奋，PingCAP的TiDB在此基础上诞生了。
TiDB的架构
TiDB在整体架构基本是参考GoogleSpanner和F1的设计，上分两层为TiDB和TiKV。TiDB对应的是GoogleF1，是一层无状态的SQLLayer，兼容绝大多数MySQL语法，对外暴露MySQL网络协议，负责解析用户的SQL语句，生成分布式的QueryPlan，翻译成底层KeyValue操作发送给TiKV。TiKV是真正的存储数据的地方，对应的是GoogleSpanner。是一个分布式KeyValue数据库，支持弹性水平扩展，自动的灾难恢复和故障转移（高可用），以及ACID跨行事务。
值得一提的是TiKV并不像HBase或者BigTable那样依赖底层的分布式文件系统，在性能和灵活性上能更好，这个对于在线业务来说是非常重要。
所以一套这样的架构是由这样的3类角色共同组建而成。每个部分的解释如下：
3.1TiDBServer
TiDBServer负责接收SQL请求，处理SQL相关的逻辑，并通过PD找到存储计算所需数据的TiKV地址，与TiKV交互获取数据，最终返回结果。TiDBServer是无状态的，其本身并不存储数据，只负责计算，可以无限水平扩展，可以通过负载均衡组件（如LVS、HAProxy或F5）对外提供统一的接入地址。
3.2PDServer
PlacementDriver(简称PD)是整个集群的管理模块，其主要工作有三个：
存储集群的元信息（某个Key存储在哪个TiKV节点）；对TiKV集群进行调度和负载均衡（如数据的迁移、Raftgroupleader的迁移等）；分配全局唯一且递增的事务ID。PD是一个集群，需要部署奇数个节点，一般线上推荐至少部署3个节点。3.3TiKVServer
TiKVServer负责存储数据。从外部看TiKV是一个分布式的提供事务的Key-Value存储引擎。存储数据的基本单位是Region，每个Region负责存储一个KeyRange（从StartKey到EndKey的左闭右开区间）的数据，每个TiKV节点会负责多个Region。
TiKV使用Raft协议做复制，保持数据的一致性和容灾。副本以Region为单位进行管理，不同节点上的多个Region构成一个RaftGroup，互为副本。数据在多个TiKV之间的负载均衡由PD调度，这里也是以Region为单位进行调度。
TiDB五大核心特性
4.1一键水平扩缩容
得益于TiDB存储计算分离的架构的设计，可按需对计算、存储分别进行在线扩容或者缩容，扩容或者缩容过程中对应用运维人员透明。
4.2金融级高可用
数据采用多副本存储，数据副本通过Multi-Raft协议同步事务日志，多数派写入成功事务才能提交，确保数据强一致性且少数副本发生故障时不影响数据的可用性。可按需配置副本地理位置、副本数量等策略满足不同容灾级别的要求。
4.3实时HTAP
提供行存储引擎TiKV、列存储引擎TiFlash两款存储引擎。TiFlash通过Multi-RaftLearner协议实时从TiKV复制数据，确保行存储引擎TiKV和列存储引擎TiFlash之间的数据强一致。TiKV、TiFlash可按需部署在不同的机器，解决HTAP资源隔离的问题。
4.4云原生的分布式数据库
专为云而设计的分布式数据库，通过TiDBOperator可在公有云、私有云、混合云中实现部署工具化、自动化。
4.5兼容MYSQL5.7
专为云而设计的分布式数据库，通过TiDBOperator可在公有云、私有云、混合云中实现部署工具化、自动化。
TiDB四大核心应用场景
HTAP给开发者提供了一个实时数据分析方面的新思路，不需要再去维护另一个离线的数据仓库，既减轻了ETL的工作，又能节省很大一部分建立数据仓库所用到的存储和计算成本，HTAP将是未来的重要趋势。
黄东旭介绍了TiDB的四个主要应用场景：MySQL分片与合并、直接替换MySQL、用做数据仓库、作为其他系统的一个模块。
5.1MySQL分片与合并
Syncer：
TiDB应用的第一类场景是MySQL的分片与合并。对于已经在用MySQL的业务，分库、分表、分片、中间件是常用手段，随着分片的增多，跨分片查询是一大难题。TiDB在业务层兼容MySQL的访问协议，PingCAP做了一个数据同步的工具——Syncer，它可以把TiDB作为一个MySQLSlave，将TiDB作为现有数据库的从库接在主MySQL库的后方，在这一层将数据打通，可以直接进行复杂的跨库、跨表、跨业务的实时SQL查询。黄东旭提到，过去的数据库都是一主多从，有了TiDB以后，可以反过来做到多主一从。
5.2替换MySQL
第二类场景是用TiDB直接去替换MySQL。如果你的IT架构在搭建之初并未考虑分库分表的问题，全部用了MySQL，随着业务的快速增长，海量高并发的OLTP场景越来越多，如何解决架构上的弊端呢?
在一个TiDB的数据库上，所有业务场景不需要做分库分表，所有的分布式工作都由数据库层完成。TiDB兼容MySQL协议，所以可以直接替换MySQL，而且基本做到了开箱即用，完全不用担心传统分库分表方案带来繁重的工作负担和复杂的维护成本，友好的用户界面让常规的技术人员可以高效地进行维护和管理。
另外，TiDB具有NoSQL类似的扩容能力，在数据量和访问流量持续增长的情况下能够通过水平扩容提高系统的业务支撑能力，并且响应延迟稳定。
黄东旭在演讲中提到了摩拜单车的案例，摩拜早期的数据库全部用MySQL，随着业务的快速增长，MySQL的弊端逐渐显现，摩拜单车于年初开始使用TiDB替换MySQL。如今，摩拜的IT系统中已部署了数套TiDB集群，近百个节点，承载着数十TB的各类数据。
5.3数据仓库
TiDB本身是一个分布式系统，第三种使用场景是将TiDB当作数据仓库使用。TPC-H是数据分析领域的一个测试集，TiDB2.0在OLAP场景下的性能有了大幅提升，原来只能在数据仓库里面跑的一些复杂的Query，在TiDB2.0里面跑，时间基本都能控制在10秒以内。当然，因为OLAP的范畴非常大，TiDB的SQL也有搞不定的情况，为此PingCAP开源了TiSpark，TiSpark是一个Spark插件，用户可以直接用SparkSQL实时地在TiKV上做大数据分析。
5.4作为其他系统的模块
TiDB是一个传统的存储跟计算分离的项目，其底层的Key-Value层，可以单独作为一个HBase的Replacement来用，它同时支持跨行事务。TiDB对外提供两个API接口，一个是ACIDTransaction的API，用于支持跨行事务；另一个是RawAPI，它可以做单行的事务，换来的是整个性能的提升，但不提供跨行事务的ACID支持。用户可以根据自身的需求在两个API之间自行选择。例如有一些用户直接在TiKV之上实现了Redis协议，将TiKV替换一些大容量，对延迟要求不高的Redis场景。
与MySQL兼容性对比
TiDB支持包括跨行事务，JOIN及子查询在内的绝大多数MySQL的语法，用户可以直接使用现有的MySQL客户端连接。如果现有的业务已经基于MySQL开发，大多数情况不需要修改代码即可直接替换单机的MySQL。包括现有的大多数MySQL运维工具（如PHPMyAdmin,Navicat,MySQLWorkbench等），以及备份恢复工具（如mysqldump,mydumper/myloader）等都可以直接使用。
不过一些特性由于在分布式环境下没法很好的实现，目前暂时不支持或者是表现与MySQL有差异。
一些MySQL语法在TiDB中可以解析通过，但是不会做任何后续的处理，例如CreateTable语句中Engine以及Partition选项，都是解析并忽略。
不支持的特性有以下这些：
存储过程，视图，触发器，自定义函数，外键约束，全文索引，空间索引，非UTF8字符集等