作者|沈建在做业务架构的过程中，有遇到过类似的痛点吗？(1)数据量过大，将容量的复杂性上移到业务层；（2）并发量过大，将性能的复杂度上移到业务层；（3）前后端存储异构，满足不同的查询需求；（4）线上线下存储异构，满足大数据需求；(5)存储系统迁移成本高，不敢轻易重构；在线业务存储。近年来，遇到的问题逐渐增多，严重影响了研发效率。TiDB这几年很火，所以最近研究了一下，分享给大家。喜欢一贯的风格，再多说说：TiDB解决了什么问题，为什么要这样设计，体现了什么样的架构思想。这就引出了一个问题，MySQL架构有什么问题？相信很多人都看过上面这张MySQL架构图：上游：MySQL客户端；下游：MySQL服务器，包括连接池、语法分析、语义分析、查询优化、缓冲池、存储引擎、物理存储、管理功能……等诸多模块；画外音：太复杂了，我看不清字。对MySQL架构做了一个简化：如上图所示：上游：MySQL客户端；中：通过MySQL协议进行通信；下游：MySQL服务器；画外音：对不起，容忍我画的丑图。核心服务器主要分为两层：一层，计算层；一层，存储层；MySQL是谁谁，自然存在什么问题？[1]计算和存储是天然耦合的。由于计算层和存储层都在同一个MySQL进程中，所有的CPU资源和内存资源都是共享的，必然存在资源竞争耦合。除了先天不足之外，在典型的大数据、大并发的互联网业务场景下使用MySQL还有哪些痛点？我们都知道，当读写量增大时，MySQL通常会组成一个主从集群：如上图所示：主从同步，读写分离，线性扩展系统的读性能通过线性增加从库。画外音：对于大部分业务而言，读书很容易成为主要矛盾。我们也知道，当存储容量增加时，MySQL通常会水平拆分集群：如上图所示：使用一个键值进行数据分片，以达到更大的存储容量。所以，其实线上的MySQL集群是这样的：既有横向分片，也有多重分片；还有主从组，每个分片有一个主从集群；服务需要关注，导致下一个痛点：[2]调用方需要关注存储细节，将底层存储的复杂性转移到上层应用。另外，除了线上应用，大部分互联网公司还有各种大数据处理需求：线下分析：比如商报；在线分析：比如分析师抓取数据；实时处理：例如实时报表；类需求，还需要将MySQL中的数据同步到各个大数据系统的集群中：使用一系列的大数据技术系统来解决各种大数据处理的需求。这就引出了另一个痛点：[3]技术端需要关注数据同步、数据一致性，以及大数据集群的复杂性。当然，很多技术经理也会研究各种替代产品来解决以上1-3个问题。例如NoSQL的代表之一MongoDB，不得不[4]升级迁移，需要大量的系统改造。经过综合评估，他们往往不得不放弃迁移计划，继续遭受MySQL带来的各种问题的困扰。历史痛点往往是创新的契机。TiDB，它来了！TiDB是如何设计来解决：（1）计算和存储的耦合；(2)底层存储层的复杂性转移；(3)大数据系统的复杂性转移；(4)系统迁移成本高；和其他问题？首先，TiDB在诞生之初就确定了总体设计方向：复用MySQL协议；计算和存储分离；如上图所示：Upstream：无需做任何改动，可以使用各种MySQL驱动访问TiDB；中：通过MySQL协议进行通信；下游：将计算层和存储层拆分为两个进程，消除资源争用鲁棒耦合，两层之间的通信采用内部协议，对调用者透明；这样就解决了问题（1）和（4）。如何解决读写量扩容、存储量扩容等“底层复杂性转移”问题？对于计算层，连接池、语法分析、语义分析、查询优化等模块实现无状态，通过集群进行扩展。这就是TiDB架构中的“计算引擎tidb-server”集群。对于调用者来说，接入层的TiDB集群是入口，背后的复杂性对上游来说是不可见的。上图中简称为【接入层（计算层）】。画外音：在微服务架构中，站点应用和微服务层也必须是无状态的，才能实现轻松的集群扩展，这也是一个道理。存储层实现了共识算法、分布式事务、MVCC并发控制、算子下推等模块，实现原子KV存储，也可以通过集群自动扩展。这就是TiDB架构中的“存储引擎TiKV-”。服务器”集群。上图中简称为【存储层】。画外音：这与GFS中的chunk-server非常相似。有了它，无需手动拆分扩容。此外，还需要一个具有全局视觉、元数据存储、ID分配（key-id、事务ID）、时间戳生成、心跳检测、集群信息收集等模块的master。这就是架构PD-server”集群中的“TiDB”，在上图中，简写为【managementmanagement】。画外音：这个很像GFS中的master-server，这样一来，问题（2)存储底层读写容量和存储容量的复杂传输问题也得到了解决，TiDB内部也屏蔽了大数据系统的复杂性：扩展访问层允许独立访问大数据，比如图中的TiSpark上图；扩展存储层来匹配大数据的存储，如上图TiFlash；画外音：TiKV和TiFlash独立存储，进行异步数据同步，相互解耦。扩展管理层，管理部分同时处理大数据；这样一来，（3）大数据的数据同步、数据一致性、大数据集群的复杂性等问题也得到了解决，TiDB的架构处处体现着这样的设计原则ere：方便用户使用，繁琐麻烦的地方都屏蔽在TiDB内部。回到开头，你是否遇到了类似的痛点？数据量过大，容量的复杂性上移到业务层；并发量过大，性能复杂度上移到业务层；前后端存储异构；在线和离线存储是异构的；存储系统迁移成本高；...也许，试试TiDB。最后一个问题，如何将业务架构快速迁移到TiDB？从MySQL到TiDB的迁移过程也很顺利：(1)第一步维护服务读写原MySQL集群；(2)第二步，将原MySQL集群中的数据同步到TiDB；画外音：TiDB工具集非常齐全，本文不展开介绍。(3)第三步，业务流量切换到TiDB；画外音：由于维护了MySQL协议，业务代码几乎不需要修改，这是TiDB成功的重要原因。今天讲了TiDB架构的宏观设计原则，希望大家有所收获。如果大家对TiDB的核心感兴趣，以后可以再聊聊它的实现细节。画外音：你有兴趣吗？源代码：https://github.com/pingcap/tidb
