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