共计 4271 个字符，预计需要花费 11 分钟才能阅读完成。
曾几何时，“并发高就分库，数据大就分表”曾经成了解决 MySQL 数据增长问题的圣经。
面试官喜爱问，博主喜爱写，候选人也喜爱背，仿佛曾经造成了一个闭环。
但你有没有思考过，分库分表真的适宜你的零碎吗？
分表
在业务刚刚倒退起来的时候，流量全副达到了一个 MySQL 上，用户信息全落到了 user 表。
起初，user 表的数据量越来越大了。
于是，你做了一次垂直拆分，将原来的 user 表拆分成了新的 user 表和 user_details 表。
这样一拆之后，用户的信息扩散到两个表，user 外表的数据量一下就变小了，user 外表数据量过大的问题临时就解决了。
但随着业务的倒退，线上的流量越来越大，单个 MySQL 曾经扛不住流量的压力了。
当个库承受不住压力的时候，就须要分库了。
分库
顾名思义，分库就是将一个库拆成多个库，让多个库分担流量的压力。
拆成多个库也意味着进行了分表，也就是说分库肯定分表，分表不肯定分库。
咱们能够依据 偏利用 还是 偏 DB，将分库分表的实现形式分成三种类型：
- JDBC 代理模式
- DB 代理模式
- Sharding On MySQL 的 DB 模式
JDBC 代理模式
JDBC 代理模式是一种无中心化的架构模式。ShardingSphere-JDBC 就是 JDBC 代理模式的典型实现。
通常以 jar 包含提供服务，让客户端直连数据库，这种模式无需额定部署和依赖，可了解为增强版的 JDBC 驱动。
JDBC 代理模式尽管简略，但违反了 DB 通明的准则，侵入性比拟高，须要针对不同的语言编写不同的 Driver。
美团的 Zebra、MTDDL，阿里 TDDL 都是基于这种模式的实现。
DB 代理模式
DB 代理模式是中心化的架构模式。ShardingSphere-Proxy 就是 DB 代理模式的经典实现。
这种模式旨在实现透明化的数据库代理端，并独立于利用部署，因为独立部署，所以对异构语言没有限度，不会对利用造成侵入。
DB 代理模式比 JDBC 代理模式耗费的连接数会少，相对来说性能也会更好。
但中心化的设计也带来了单点的问题，为了放弃高可用和高性能，还须要引入 LVS/F5 等 VIP 来实现流量的负载平衡，如果逾越 IDC，还依赖诸如 DNS 进行 IDC 散发，大大拉长了利用到数据库的链路，进而进步了响应工夫。
阿里的 MyCat、美团的 Meituan Atlas 和百度 Heisenberg 就是基于 DB 代理模式的实现。
Sharding On MySQL
Sharding On MySQL 相当于屏蔽了分库分表的操作，是运维和中间件联合的积淀，比拟典型的例子是阿里的 DRDS。
这种模式让分库分表变得含糊，对利用来说，更像是一个封装了 MySQL 的新型数据库。
尽管用户应用变得更简略了，但简略的背地是运维的积淀，分库分表该存在的问题它仍然存在。
分库分表的老本
实现分库分表的形式有很多，但不同模式的实现仿佛都是在补救 MySQL 不反对分布式的缺点。
分库分表这种强行让 MySQL 达到一个伪“分布式”的状态，也带来了一些新的问题，比方：
- 性能限度问题：分库分表后跨维度 join、聚合、子查问不复存在，惟一键、外键等全局束缚也只能靠业务保障，DB 缓缓弱化为存储。
- 运维复杂度问题：分库分表后的多个库表的治理麻烦，运维老本十分高，数据查问也很麻烦。
- Sharding Key 问题：非 Sharding key 的查问须要做额定的冗余解决，须要引入 Elasticsearch、ClickHouse 等其余节点，进一步提高了零碎的复杂度。
- 惟一 ID 问题：分库分表后惟一一个 ID 得不到保障，须要惟一 ID 进行革新。
- 分布式事务问题：MySQL 自带的 XA 柔性事务性能太低，须要引入新的分布式事务解决方案。
NewSQL
从上文得悉，分库分表须要就义 MySQL 的一些性能，还带来许多新的问题。
那有没有一种计划，既能领有 MySQL 的性能，又能反对数据的可扩大？
有。那就是 NewSQL。
NewSQL 是一类关系数据库管理系统，旨在为在线事务处理(OLTP) 工作负载提供 NoSQL 零碎的可扩展性，同时放弃传统数据库系统的 ACID 保障。
国内比拟出名的 NewSQL 有阿里的 OceanBase、腾讯的 TDSQL、PingCAP 的 TiDB。它们既有 MySQL 的性能，又有分布式可扩大的能力。
笔者对阿里的 OceanBase 只能说是略懂皮毛，就不过多形容。
咱们重点看一下腾讯的 TDSQL 和 PingCAP 的 TiDB。
从两者的架构图（省略了局部模块）上能够看出，TDSQL 和 TiDB 的架构只有一些命名差异，能够说简直截然不同。
两者整体来说分为三个局部：
- 计算：负责承受客户端的连贯，执行 SQL 解析和优化，最终生成分布式执行打算转发给底层的存储层执行。（TDSQL：SQL Engine、TiDB：TiDB-Server）
- 存储：分布式KV 存储，相似 NoSQL 数据库，反对弹性扩容和缩容。（TDSQL：TDStore、TiDB：TiKV）
- 管控：整个集群的元信息管理模块，是整个集群的大脑。（TDSQL：TDMetaCluster、TiDB：Placement Driver）
两者外围的存储模块（TDStore/TiKV），都是基于 RocksDB 开发而来，都是 KV 存储 的模式。
RocksDB 是由 Facebook 基于 LevelDB 开发的一款提供键值存储与读写性能的 LSM-tree 架构引擎。
底层利用了 WAL(Write Ahead Log)技术和 Sorted String Table，比 B 树类存储引擎更高的写吞吐。
NewSQL 平滑接入计划
因为笔者落地过 TiDB，所以会以 TiDB 为例形容如何接入 NewSQL，做到不影响线上应用的平滑迁徙。
第一步：初始状态，所有线上读和写都落到 MySQL。
第二步：将 TiDB 作为 MySQL 的从节点接入零碎，所有线上读写还是都落到 MySQL，日末通过脚本或者工作验证 MySQL 的数据和 TiDB 的数据是否统一，这一步次要验证 MySQL 数据同步到 TiDB 没有问题。
第三步：将局部读切换到 TiDB，这一步次要验证 TiDB 同步的数据读没有问题，验证零碎 SQL 能失常在 TiDB 执行。
第四步：断掉 MySQL 和 TiDB 之间的同步，双写 MySQL 和 TiDB，所有的线上读流量都落到 MySQL。
第五步：将局部读流量切到 TiDB，验证 TiDB 写入的数据可能失常读取。这一阶段能够将局部幂等工作同时在两个数据源上执行，验证两者数据是否统一。
第六步：将所有的线上读流量切到 TiDB，同时放弃双写，如果出问题随即切到 MySQL。
第七步：断掉 MySQL 的写流量，将 MySQL 作为 TiDB 的一个从库，作为降级应用。
整个计划的根底是：TiDB 兼容 MySQL 协定和 MySQL 生态。
这个计划是建设在 齐全不信赖 TiDB的根底上设计的，验证了 TiDB 和 MySQL 的契合点，所以整体会比拟繁琐，理论落地的时候能够依据状况省略一部分步骤。
NewSQL 真的有那么好吗？
NewSQL 并是不万能的，也不用去过于神化 NewSQL，国内比拟出名的几种 NewSQL 或多或少都存在局部性能缺点，以 TiDB 为例：
- TiDB 的自增 ID 只能保障单个 TiKV 上的自增，并不能保障全局自增。
- 因为 TiKV 存储是依据 key 的二进制顺序排列的，应用自增 ID 可能会造成热块效应。
- TiDB 默认 RC（读已提交）的事务隔离级别，并且不反对 RR（可反复读）隔离级别，尽管提供了根本等价于 RR 的 SI（Snapshot Isolation），但还是存在 写偏斜 问题
- TiDB 的点查（select point）性能比 MySQL 要差不少，在几个亿级别的数据量能力勉强和 MySQL 打平。
- 因为底层基于 Raft 协定做数据同步，所以 TiDB 提早会比 MySQL 要高。
- …
所以说，NewSQL 也并不是屠龙刀，须要依据理论利用去评估这些缺点带来的影响。
NewSQL 的利用
NewSQL 在国内其实曾经倒退了很多年，OceanBase 诞生于 2010 年，TDSQL 可追溯到 2004 年，TiDB 诞生于 2015 年。
三者在国内外积攒了不少的客户案例。
OceanBase
- OceanBase 曾经笼罩 蚂蚁团体100% 外围链路，撑持全副五大业务板块。目前运行数十亿条不同的 SQL、数据量达数百 PB、服务器核数过百万。
- 中国工商银行 全行业务都应用 OceanBase，蕴含不限于存、贷、领取结算及翻新业务等。
- OceanBase 凭借混合云架构、高可用、Oracle 兼容等个性，通过分布式中间件、金融套件、挪动开发平台集成解决方案，撑持 网商银行 外围零碎数字化转型。
- 招商银行 的“海量行情零碎”和“历史收益零碎”就是采纳 OceanBase 作为底层数据库。
TDSQL
- 微众银行 实现了 TDSQL 私有化部署，是一个典型的两地多核心架构。
- 富途证券 的港股交易系统、东吴证券新一代外围交易系统底层存储都是 TDSQL。
- 数字广东 粤省事 、 深圳地铁码上乘车 等业务都是在 TDSQL 下面跑的。
- 安全银行、中国农业银行、华夏银行、中国银行 都有相干业务在 TDSQL 上。
TiDB
- 北京银行 的网联领取业务，所有北京银行的银行卡绑定在比方支付宝、微信上的领取操作，后端的数据库就是运行在 TiDB，而且是一个典型的两地三核心同城双活的架构，这个业务十分的要害，如果业务中断超过肯定工夫，就是须要上报银监会的。
- 日本排名第一的领取公司——Paypay，钱包和领取的业务都在 TiDB 下面。
- 中国人寿 的寿财险业务，正在用 TiDB 陆续替换 Oracle。
- 肯德基 所有的会员登录零碎，包含 KFC 的 APP 以及第三方登录，后盾数据库都是用的 TiDB，这套业务 2020 年 4 月份上线，曾经经验过屡次肯德基的大促等流动，目前肯德基的后盾领取零碎也曾经切换到 TiDB 上。
- 麦当劳 的账户以及订单零碎全副基于 TiDB，如果 TiDB 出问题了，那么国内所有的麦当劳门店，包含线上和线下的点单零碎都将没法失常运行。
- 微众银行 最外围和最赚钱的微粒贷业务，后盾的全量批处理业务就运行在 TiDB 下面。
分库分表和 NewSQL 到底怎么选？
分库分表是一个重量级的计划，它会带来很多新的问题，对基建和运维的要求也很高。
NewSQL 功能强大但也有性能缺点。
如何去抉择须要依据零碎现状和公司状况去综合判断。
分库分表是一个重量级的计划，如果 读写拆散 、 冷热拆散 等轻量级计划能解决的问题就没必要上 分库分表。
如果缓存分流和读写拆散都扛不住了，且你身处互联网企业，基建尚可且运维也跟得上，分库分表 依然是第一抉择；
但如果你身处一个传统的企业，基建很差甚至没有基建，那么你能够思考思考NewSQL。
技术没有高下之分，能解决问题的技术就是好技术，技术计划抉择上切莫炫技，也切勿适度设计！