咱们的痛点
本节介绍了咱们的 Moneta 应用程序的体系结构，咱们尝试构建的现实体系结构，以及数据库可伸缩性作为咱们的次要难点。
零碎架构要求
知乎的 Post Feed 服务是一个要害零碎，用户能够通过该零碎接管网站上公布的内容。
后端的 Moneta 应用程序存储用户已浏览的帖子，并在知乎的举荐页面的帖子流中过滤掉这些帖子。
Moneta 应用程序具备以下特色：
- 须要高可用性数据：Post Feed 是第一个呈现的屏幕，它在推动用户流量到知乎方面施展着重要作用。
- 解决微小的写入数据：例如，在顶峰工夫每秒写入超过 4 万条记录，记录数量每天减少近 30 亿条记录。
- 长期存储历史数据：目前，零碎中存储了大概 1.3 万亿条记录。随着每月累积约 1000 亿条记录并且一直增长，历史数据将在大概两年内达到 3 万亿条记录。
- 解决高吞吐量查问：在顶峰工夫，零碎解决均匀每秒在 1200 万个帖子上执行的查问。
- 将查问的响应工夫限度为 90 毫秒或更短：即便对于执行工夫最长的长尾查问，也会产生这种状况。
- 容忍误报：这意味着零碎能够为用户调出许多乏味的帖子，即便有些帖子被谬误地过滤掉了。
思考到上述事实，咱们须要一个具备以下性能的应用程序架构：
- 高可用性：当用户关上知乎的举荐页面时，找到大量曾经浏览过的帖子是一种蹩脚的用户体验。
- 杰出的零碎性能：咱们的利用具备高吞吐量和严格的响应工夫要求。
- 易于扩大：随着业务的倒退和应用程序的倒退，咱们心愿咱们的零碎能够轻松扩大。
勘探
为了构建具备上述性能的现实架构，咱们在之前的架构中集成了三个要害组件：
- 代理：这会将用户的申请转发给可用节点，并确保零碎的高可用性。
- 缓存：这临时解决内存中的申请，因而咱们并不总是须要解决数据库中的申请。这能够进步零碎性能。
- 存储：在应用 TiDB 之前，咱们在独立的 MySQL 上治理咱们的业务数据。随着数据量的激增，独立的 MySQL 零碎还不够。
而后咱们采纳了 MySQL 分片和 Master High Availability Manager（MHA）的解决方案，然而当每月有 1000 亿条新记录涌入咱们的数据库时，这个解决方案是不可取的。
MySQL Sharding 和 MHA 的毛病
MySQL 分片和 MHA 不是一个好的解决方案，因为 MySQL 分片和 MHA 都有它们的毛病。
MySQL 分片的毛病：
- 利用程序代码变得复杂且难以保护。
- 更改现有的分片键很麻烦。
- 降级利用程序逻辑会影响应用程序的可用性。
MHA 的毛病：
- 咱们须要通过编写脚本或应用第三方工具来实现虚构 IP（VIP）配置。
- MHA 仅监督主数据库。
- 要配置 MHA，咱们须要配置无明码平安 Shell（SSH）。这可能会导致潜在的平安危险。
- MHA 不为隶属服务器提供读取负载平衡性能。
- MHA 只能监督主服务器（而不是从主服务器）是否可用。
在咱们发现 TiDB 并将数据从 MySQL 迁徙到 TiDB 之前，数据库可伸缩性依然是整个零碎的弱点。
什么是 TiDB？
TiDB 平台是一组组件，当它们一起应用时，它们将成为具备 HTAP 性能的 NewSQL 数据库。
在 TiDB 平台外部，次要组件如下：
- TiDB 服务器是一个无状态的 SQL 层，它解决用户的 SQL 查问，拜访存储层中的数据，并将相应的后果返回给应用程序。它与 MySQL 兼容并且位于 TiKV 之上。
- TiKV 服务器是数据长久存在的分布式事务键值存储层。它应用 Raft 共识协定进行复制，以确保弱小的数据一致性和高可用性。
- TiSpark 集群也位于 TiKV 之上。它是一个 Apache Spark 插件，可与 TiDB 平台配合应用，反对商业智能（BI）分析师和数据科学家的简单在线剖析解决（OLAP）查问。
- 搁置驱动程序（PD）服务器是由 etcd 反对的元数据集群，用于治理和调度 TiKV。
除了这些次要组件之外，TiDB 还领有一个工具生态系统，例如用于疾速部署的 Ansible 脚本，用于从 MySQL 迁徙的 Syncer 和 TiDB 数据迁徙。
以及用于收集对 TiDB 群集进行的逻辑更改并提供增量备份的 TiDB Binlog。复制到上游（TiDB，Kafka 或 MySQL）。
TiDB 的次要性能包含：
- 程度可扩展性。
- MySQL 兼容的语法。
- 具备强一致性的分布式事务。
- 云原生架构。
- 应用 HTAP 进行最小提取，转换，加载（ETL）。
- 容错和 Raft 复原。
- 在线架构更改。
咱们如何应用 TiDB
在本节中，我将向您展现如何在 Moneta 的架构中运行 TiDB 以及 Moneta 应用程序的性能指标。
咱们架构中的 TiDB
咱们在零碎中部署了 TiDB，Moneta 应用程序的整体架构变为：
- 顶层：无状态和可伸缩的客户端 API 和代理。这些组件易于扩大。
- 中间层：软状态组件和分层 Redis 缓存作为次要局部。当服务中断时，这些组件能够通过复原保留在 TiDB 群集中的数据来自我复原服务。
- 底层：TiDB 集群存储所有有状态数据。它的组件高度可用，如果节点解体，它能够自我复原其服务。
在该零碎中，所有组件都是可自我复原的，整个零碎具备全局故障监督机制。而后，咱们应用 Kubernetes 来协调整个零碎，以确保整个服务的高可用性。
TiDB 的性能指标
因为咱们在生产环境中利用了 TiDB，因而咱们的零碎具备高可用性和易于扩展性，并且零碎性能失去显著改善。例如，在 2019 年 6 月为 Moneta 应用程序采纳一组性能指标。
在顶峰工夫每秒写入 40,000 行数据：
在顶峰时段每秒查看 30,000 个查问和 1200 万个帖子：
第 99 百分位响应工夫约为 25 毫秒，第 999 百分位响应工夫约为 50 毫秒。实际上，均匀响应工夫远远小于这些数字，即便对于须要稳固响应工夫的长尾查问也是如此。
咱们学到了什么
咱们迁徙到 TiDB 并非顺利，在这里，咱们想分享一些经验教训。
更快地导入数据
咱们应用 TiDB 数据迁徙（DM）来收集 MySQL 增量 Binlog 文件，而后应用 TiDB Lightning 将数据疾速导入 TiDB 集群。
令咱们诧异的是，将这 1.1 万亿条记录导入 TiDB 只用了四天工夫。如果咱们逻辑地将数据写入零碎，可能须要一个月或更长时间。如果咱们有更多的硬件资源，咱们能够更快地导入数据。
缩小查问提早
实现迁徙后，咱们测试了大量的读取流量。当 Moneta 应用程序首次上线时，咱们发现查问提早不合乎咱们的要求。为解决提早问题，咱们与 PingCap 工程师单干调整零碎性能。
在此过程中，咱们积攒了贵重的数据和数据处理常识：
- 有些查问对查问提早很敏感，有些则不然。咱们部署了一个独自的 TiDB 数据库来解决对提早敏感的查问。（其余非提早敏感的查问在不同的 TiDB 数据库中解决。）
这样，大型查问和对提早敏感的查问在不同的数据库中解决，前者的执行不会影响后者。 - 对于没有现实执行打算的查问，咱们编写了 SQL 提醒来帮忙执行引擎抉择最佳执行打算。
- 咱们应用低精度工夫戳 Oracle（TSO）和预处理语句来缩小网络往返。
评估资源
在咱们尝试 TiDB 之前，咱们没有剖析咱们须要多少硬件资源来反对 MySQL 端的雷同数据量。
为了升高保护老本，咱们在单主机 – 单从机拓扑中部署了 MySQL。相同，在 TiDB 中实现的 Raft 协定至多须要三个正本。
因而，咱们须要更多的硬件资源来反对 TiDB 中的业务数据，咱们须要提前准备机器资源。
一旦咱们的数据中心设置正确，咱们就能够疾速实现对 TiDB 的评估。
对 TiDB 3.0 的冀望
在知乎，反垃圾邮件和 Moneta 应用程序的架构雷同。咱们在用于生产数据的反垃圾邮件应用程序中尝试了 TiDB 3.0（TiDB 3.0.0-rc.1 和 TiDB 3.0.0-rc.2）的候选版本中的 Titan 和 Table Partition。
①Titan 缩短了提早
反垃圾邮件应用程序始终受到重大的查问和写入提早折磨。
咱们据说 TiDB 3.0 将引入 Titan，一种键值存储引擎，用于在应用大值时缩小 RocksDB（TiKV 中的底层存储引擎）的写入放大。为了尝试这个性能，咱们在 TiDB 3.0.0-rc.2 公布后启用了 Titan。
下图别离显示了与 RocksDB 和 Titan 相比的写入和查问提早：
统计数据显示，在咱们启用 Titan 后，写入和查问提早都急剧下降。这真是太惊人了！当咱们看到统计数据时，咱们无奈置信本人的眼睛。
②表分区改良了查问性能
咱们还在反垃圾邮件应用程序中应用了 TiDB 3.0 的表分区性能。应用此性能，咱们能够按时将表分成多个分区。
当查问到来时，它将在笼罩指标工夫范畴的分区上执行。这大大提高了咱们的查问性能。
让咱们考虑一下如果咱们未来在 Moneta 和反垃圾邮件应用程序中施行 TiDB 3.0 会产生什么。
③Moneta 应用程序中的 TiDB 3.0
TiDB 3.0 具备诸如 gRPC 中的批处理音讯，多线程 Raftstore，SQL 打算治理和 TiFlash 等性能。咱们置信这些将为 Moneta 利用增添光彩。
④gRPC 和多线程 Raftstore 中的批处理音讯
Moneta 的写入吞吐量超过每秒 4 万次交易（TPS），TiDB 3.0 能够批量发送和接管 Raft 音讯，并且能够在多个线程中解决 Region Raft 逻辑。咱们置信这些性能将显著进步咱们零碎的并发能力
⑤SQL 打算治理
如上所述，咱们编写了大量 SQL 提醒，以使查问优化器抉择最佳执行打算。
TiDB 3.0 增加了一个 SQL 打算治理性能，能够间接在 TiDB 服务器中将查问绑定到特定的执行打算。应用此性能，咱们不须要批改查问文本以注入提醒。
⑥TiFlash
在 TiDB DevCon 2019 上，我第一次据说 TiFlash 是 TiDB 的扩大剖析引擎。
它应用面向列的存储技术来实现高数据压缩率，并在数据复制中利用扩大的 Raft 一致性算法以确保数据安全性。
因为咱们领有高写入吞吐量的海量数据，因而咱们无奈每天应用 ETL 将数据复制到 Hadoop 进行剖析。然而对于 TiFlash，咱们乐观地认为咱们能够轻松剖析咱们宏大的数据量。
⑦反垃圾邮件应用程序中的 TiDB 3.0
与 Moneta 应用程序的微小历史数据大小相比，反垃圾邮件应用程序具备更高的写入吞吐量。
然而，它仅查问过来 48 小时内存储的数据。在此应用程序中，数据每天减少 80 亿条记录和 1.5 TB。
因为 TiDB 3.0 能够批量发送和接管 Raft 音讯，并且它能够在多个线程中解决 Region Raft 逻辑，因而咱们能够用更少的节点管理应用程序。
以前，咱们应用了七个物理节点，但当初咱们只须要五个。即便咱们应用商用硬件，这些性能也可晋升性能。
下一步是什么
TiDB 是一个与 MySQL 兼容的数据库，因而咱们能够像应用 MySQL 一样应用它。
因为 TiDB 的横向可扩展性，当初咱们能够自在扩大咱们的数据库，即便咱们有超过一万亿的记录来应答。
到目前为止，咱们曾经在咱们的应用程序中应用了相当多的开源软件。咱们还学到了很多对于应用 TiDB 解决零碎问题的常识。
咱们决定参加开发开源工具，并参加社区的长期倒退。基于咱们与 PingCAP 的共同努力，TiDB 将变得更加弱小。
起源：http://itindex.net