共计 4909 个字符，预计需要花费 13 分钟才能阅读完成。
对于任何一家业务疾速成长的企业来说，应答峰值流量冲击，始终是摆在技术团队背后的一大难题。面对海量数据，数据库及业务团队都心愿做到“无感扩容”，但风行的分库、分表计划在扩容速度和一致性上常常不能满足需要。行业期待着性能弱小、简略易用的全新数据库计划，从根本上解决企业面对流量顶峰时的数据库性能瓶颈。
行业需要是技术创新的最大推动力。近年来，由 PingCAP 开发的 TiDB 分布式数据库异军突起，在海量数据处理畛域具备很大的劣势。在此背景下，2020 年初京东智联云联结 PingCAP，基于 TiDB 打造了云端分布式数据库——Cloud-TiDB。
11 月 26 日，京东智联云与英特尔联结举办了主题为“冲破极限，TiDB 在京东智联云的技术架构与实际”的线上直播流动。直播邀请到 京东智联云云产品研发部架构师葛集斌老师，和 PingCAP TiDB 生态技术布道专家戚铮老师 别离带来分享，心愿借此机会帮忙更多企业和开发人员拓展思路，提供一个分库分表路径之外的新抉择，并理解如何在生产实践中施展 TiDB 的价值。
本文总结自本场直播分享，内容有调整。
一、TiDB 在京东智联云的技术架构与实际
直播第一局部，葛老师深入分析了京东智联云为何抉择 TiDB 数据库，并介绍了 TiDB 在京东智联云上的技术架构和技术生态细节。
1，TiDB 数据库心愿解决哪些问题
传统单机数据库在当下的大数据时代暴露出了越来越多的局限性，对于一家快速增长的企业来说，因为数据量会随着企业规模有序扩充，单机数据库很快就会遭逢多个瓶颈：
- 单表、单库数据量过大；
- 单机存储容量达到下限；
- 单机解决能力达到瓶颈。
- 读取提早和存储需要回升，并且无奈扩大写入性能。
- 想要持续晋升性能，传统办法就是对数据库进行分库分表，但分库分表也存在很多人造束缚。
- 在 高可用性 方面，MySQL 须要集成内部程序来解决。
- MySQL 的 故障检测、主从判断和转移 都须要定制策略。
- 异步和半同步复制是非强一致性的，减少了数据失落的危险。
- 此外，MySQL 的 OLAP 数据处理能力较弱，数据分析需要还须要 ETL 到内部剖析零碎。以上这些都是传统数据库计划现实存在的瓶颈。TiDB 的诞生，就是为了解决这些传统数据库常见的问题，心愿可能从根本上冲破单机数据库的能力极限。
具体到技术层面，TiDB 数据库有哪些良药来应答上述问题呢？首先要明确的是，TiDB 不同于传统单机架构，而是一个真正意义上的分布式数据库。采纳计算、存储拆散的架构设计，提供程度线性扩大能力。它还具备强一致性、高可用性，反对主动故障复原，能够对数据进行实时剖析。另外它还高度兼容 MySQL 协定。整体架构来看，TiDB 分为 TiDB Server、分布式存储层和 PD 三大部分：
- TiDB Server 兼容 MySQL 协定，能够程度扩大，因而用户能够将 TiDB 当作 MySQL 应用。
- TiDB 存储层 TiKV 是分布式 KV 存储，能够线性扩大，并通过多正本和 Raft 协定保障强一致性。TiKV 还分为多个 region，以 region 为单位进行治理。数据分布在各个 TiKV 节点上，节点能够程度扩大。
- PD 负责集群治理，包含调度和负载平衡工作，并负责生成全局的 TSO 工夫戳。PD 自身也是无单点故障的集群。
TiDB 应用 TiFlash 列存储引擎来反对实时数据分析。它通过 Raft learner 进行异步复制，配合 MVCC 提供强一致性读取，还反对计算下推，使得其 AP/TP 性能互相无烦扰。应用 TiFlash 时 TiDB 优化器会计算查问代价，依据后果主动抉择 TiKV 行存或 TiFlash 列存。
基于这样的架构设计，TiDB 集群实现了整体的高可用性和数据强一致性，即便多数正本失落也能主动实现数据修复和故障转移，不会烦扰业务层。TiDB 能够实现跨核心的异地多活部署。
2，云上 TiDB 的实现和性能
近年来，京东智联云的客户对数据处理能力的需要一直晋升。针对这样的需要，京东智联云与 PingCAP 联结，基于 TiDB 打造了云端分布式数据库——Cloud-TiDB，次要面向高性能、高牢靠、高可用场景。
上图为京东智联云 Cloud-TiDB 的整体架构，基于这样的架构，Cloud-TiDB 提供了一些业务价值较高的性能，包含程度弹性扩容、备份和复原、实时数据分析、数据迁徙和同步、云端监控告警等。
- 程度弹性扩容。TiDB 能够在线动静增减存储和计算节点，具备靠近有限的程度扩大能力。伸缩操作后，数据库还能够主动实现数据再平衡。
- 备份和复原。TiDB 反对主动 / 手动全量备份，并将数据备份在 OSS 中。复原时数据不会笼罩原有集群，可无效避免误操作。
- 实时数据分析。在反对 OLTP 的同时提供业务数据的实时剖析和解决。
- 数据迁徙和同步。反对全量 / 增量迁徙，能够将数据同步到 MySQL、Kafka 上游存储中。
- 监控与告警。TiDB 提供了丰盛的监控指标，反对浏览器间接拜访。云监控提供资源 / 业务层面的监控告警，云日志能够配置谬误日志监控报警。除上述能力外，在实际利用中 Cloud-TiDB 的另一大劣势就是更低的运维老本。Cloud-TiDB 能够很好地满足云服务按需伸缩的需要，使用户能够准确地管制资源使用量，防止资源节约。
抉择一项新技术的同时也是在抉择一个生态，生态越欠缺，开发和运维效率也会越高。TiDB 生态的一大特点就是兼容 MySQL 协定，从而能够受惠于成熟的 MySQL 生态资源。MySQL 的所有数据库驱动、第三方开发 / 管理工具、数据交换 / 迁徙工具等，都能够用于 TiDB 数据库。
TiDB 与其余支流数据处理技术也能够不便地互联互通。例如 TiDB 数据能够导入 Kafka，接入 Flink，乃至 Hive、HDFS、Amazon S3、Spark 等。用户无需放心技术锁定危险，这也为 TiDB 的生态凋敝打下了根底。
在分享的最初，葛老师对云端数据库的发展趋势做了瞻望：
分布式是将来技术倒退的重要趋势之一，包含操作系统、应用程序和数据库都在向分布式转变。TiDB 作为分布式数据库，比拟合乎这一技术发展趋势。与此同时，数据库上云能够带来很多益处，例如弹性调度、与 AI 联合，还能更好地了解用户的业务视角，实现数据处理的智能优化。
久远来看，数据库上云能够在开发、运维和稳定性层面取得很大收益。正因如此，京东智联云抉择 TiDB 上云，就是心愿能给用户带来更好的应用体验。
二、TiDB 在大数据量和高并发场景下的利用
葛老师的演讲完结后，来自 PingCAP 的 TiDB 生态技术布道专家戚铮分享了 TiDB 在大数据量和高并发场景下的利用实际。
1，TiDB 与 SHARDING 在 OLTP 场景下的解决方案比照
当企业遇到海量数据需要时，往往随同数据量短期内急剧增长的压力。这样的业务须要数据库具备疾速扩容能力和高并发能力，在响应提早和吞吐量指标上都有足够高的程度以应答突发流量。而 OLTP 场景次要波及线上 2C 交易，对数据库稳定性要求较高，数据库性能稳定会间接影响用户体验。
针对这样的需要特点，业内常见的解决方案分为 Sharding、New SQL 和两头的 DB-Based 几大类型。其中，ShardingSphere 和 TiDB，就是第一和第三种类型中的两个典型。两者都是当下沉闷的开源我的项目，别离代表了应答海量数据需要的两大思路。所谓 Sharding 就是分库分表，实际中次要分为程度拆分和垂直拆分两大纬度。垂直纬度个别依照业务模块或者数据系列来拆分，程度纬度能够按取模、工夫、冷热库等形式拆分。Sharding Sphere 作为分库分表思路的代表，其架构大抵如下：
与前文列举的 TiDB 架构相比，Sharding 架构的数据备份、高可用、监控告警等需要，都须要周边第三方工具来配置解决。而 TiDB 本身就是残缺的解决方案，能够一站式满足用户对高性能数据库的各项要求。现在 ShardingSphere 也开始在新版中开始向整体分布式数据库计划转型，从侧面印证了分布式数据库是将来的必然趋势。
2，TiDB 的海量数据利用案例
TiDB 的初衷就是解决分库分表存在的许多问题，但某些场景并不太适宜向 TiDB 迁徙。具体来说，这样的场景中业务不会有快速增长，业务申请比较简单，也没有分布式事务需要。除了这样的场景以外，大部分海量数据需要都能够通过向 TiDB 迁徙失去较好的解决。戚老师这里列举了几个实际案例。
某社区个性化首页和推送业务。因为海量用户的个性化推送业务个性，数据库每天须要生成 30 亿条数据，历史数据高达万亿量级，业务对吞吐量和提早也高度敏感。该用户原有的 MySQL 计划基于分库分表，但 MySQL 实例总量达到上百个，危险和提早都难以满足需要。通过调研，用户认为 TiDB 是惟一能满足他们对高扩大、强统一、高可用需要的解决方案，因而决定全面迁徙。在迁徙过程中，PingCAP 开发了一个疾速导入工具 Lightning 联合 DM 工具来平滑转移数据，迁徙实现后又做出了一系列优化，最终很好地满足了需要。尤其令用户称心的是新架构具备很强的扩大能力，迁徙后数据量从 1.3 万亿逐步增长至 1.8 万亿，性能、可用性仍旧放弃在很高的程度上，老本相比过来也没有明显增加。
某电信集体账单零碎。该用户账单总表有 80 亿数据，对性能要求很高，而原有的 MyCAT 计划已靠近扩大极限，只能存储有余一年的历史数据。因为 MySQL 分库分表的解决瓶颈，持续分片会呈现不少问题，故此用户抉择了 TiDB 进行升级换代。向 TiDB 迁徙后，单表数据量即可达到 100 亿，数据存储周期由半年缩短至 3-5 年，QPS 和提早都有显著改善。
戚老师还介绍了某 O2O 平台 PMC 订单流水业务、某金融外围账务零碎和某互金营销平台向 TiDB 迁徙的案例。这些案例的共同点都是用户原有的数据库分库分表遇到了增长瓶颈，对业务造成了越来越多的负面影响，而迁徙到 TiDB 后齐全解决了原有瓶颈，迁徙过程没有遇到重大故障，老本投入也在可控范畴内。
3，TiDB 5.0 亮点解析
分享的最初环节，戚老师介绍了 TiDB 5.0 版本的性能优化亮点和细节，次要包含以下几项个性。
Async Commit。旧版 TiDB 采纳两阶段提交模式，开销绝对较大。Async Commit 次要在第二阶段实现了异步提交，对于小事务达到相似 1PC 的成果，从而带来了肯定的性能晋升。
Clustered Index。新版的这一个性很适宜条件范畴蕴含主键列的查问，相似 Innodb 聚簇索引，能够节俭这类查问的回表老本。依据 TPCC 测试，新版在这方面能够带来肯定性能增幅。
Compaction Filter。该个性次要针对后盾主动整顿压缩数据引起的性能抖动进行优化，开启后 QPS 的稳定标准差升高到了 5% 以内。
SATA SSD 优化。联合 compaction filter，fsync control，compaction guard 等这些新增个性，5.0 版本在 SATA SSD 上的性能吞吐和提早体现都比 4.0 有了较大改善，因为 SATA 盘自身抖动导致的 QPS 抖动也有显著降落。
三、冲破容量极限，TiDB 突破企业数据库性能瓶颈
相比传统的分库分表，TiDB 是真正一站式的分布式数据库整体解决方案，可能充沛满足企业业务快速增长、海量数据高并发、实时数据分析和金融数据高可用等场景的刻薄需要。通过本场直播两位老师的精彩分享，听众对 TiDB 数据库的能力、实现细节和业务落地实际都有了更深刻的认知，也理解了 TiDB 数据库服务的各项突出劣势。
正如两位老师所言，分布式数据库是业内必然的发展趋势，而 TiDB 适应了这一潮流，将成为越来越多企业根治数据库性能瓶颈的良方。与此同时，TiDB 在京东智联云的利用，为企业疾速采纳 TiDB、尽早享受 TiDB 收益和价值开拓了一条便捷通道。
想要理解更多京东智联云与 TiDB 相干内容，获取演讲 PPT，可在评论区评论PPT，咱们会及时回复获取形式。
点击 【 浏览原文 】 查看视频回放链接。
举荐浏览:
- 京东智联云新一代分布式数据库 TIDB 架构揭秘
- 比 MySQL 快 839 倍！揭开剖析型数据库 JCHDB 的神秘面纱
- 11.11 TECH TALK | 撑持 2715 亿元海量订单 揭秘京东大促背地的数据库基石
欢送点击【京东智联云】，理解开发者社区
更多精彩技术实际与独家干货解析
欢送关注【京东智联云开发者】公众号
