作者：孫曉光 ，北京知乎軟件架構(gòu)師。
來源：http://itindex.net/
知乎，在古文中意為“你知道嗎？”，它是中國的Quora：一個(gè)問答網(wǎng)站，其中各種問題由用戶社區(qū)創(chuàng)建，回答，編輯和組織。作為中國最大的知識(shí)共享平臺(tái)，知乎平臺(tái)目前擁有2.2億注冊用戶，3000萬個(gè)問題，網(wǎng)站答案超過1.3億。
隨著用戶群的增長，應(yīng)用程序的數(shù)據(jù)大小無法評(píng)估，在一個(gè)名為Moneta的應(yīng)用程序中存儲(chǔ)了大約1.3萬億行數(shù)據(jù)（存儲(chǔ)著用戶已經(jīng)閱讀過的帖子）。由于每月累計(jì)產(chǎn)生大約1000億行數(shù)據(jù)，且不斷增長，這一數(shù)字將在兩年內(nèi)達(dá)到3萬億。
在保持良好用戶體驗(yàn)的同時(shí)，我們在擴(kuò)展后端方面面臨嚴(yán)峻的挑戰(zhàn)。
在這篇文章中，我將深入探討如何在如此大量的數(shù)據(jù)上保持毫秒級(jí)的查詢響應(yīng)時(shí)間，以及TiDB是一個(gè)開源的MySQL兼容的NewSQL混合事務(wù)/分析處理（ HTAP）數(shù)據(jù)庫，如何為我們提供支持獲得對(duì)我們數(shù)據(jù)的實(shí)時(shí)洞察。我將介紹為什么選擇TiDB，如何使用它，學(xué)到了什么，最佳實(shí)踐以及對(duì)未來的一些暢想。
我們的痛點(diǎn)
本節(jié)介紹了我們的Moneta應(yīng)用程序的體系結(jié)構(gòu)，我們嘗試構(gòu)建的理想體系結(jié)構(gòu)，以及 數(shù)據(jù)庫可伸縮性 作為我們技術(shù)團(tuán)隊(duì)的主要難點(diǎn)。
系統(tǒng)架構(gòu)要求
知乎的Post Feed服務(wù)是一個(gè)關(guān)鍵系統(tǒng)，用戶可以通過該系統(tǒng)接收網(wǎng)站上發(fā)布的內(nèi)容。后端的Moneta應(yīng)用程序存儲(chǔ)用戶已閱讀的帖子，并在知乎的推薦頁面的帖子流中過濾掉這些帖子。
Moneta應(yīng)用程序具有以下特征：
- 需要高可用性數(shù)據(jù)：Post Feed是第一個(gè)出現(xiàn)的屏幕，它在推動(dòng)用戶流量到知乎方面發(fā)揮著重要作用。
- 處理巨大的寫入數(shù)據(jù)：例如，在高峰時(shí)間每秒寫入超過4萬條記錄，記錄數(shù)量每天增加近30億條記錄。
- 長期存儲(chǔ)歷史數(shù)據(jù)：目前，系統(tǒng)中存儲(chǔ)了大約1.3萬億條記錄。隨著每月累積約1000億條記錄并且不斷增長，歷史數(shù)據(jù)將在大約兩年內(nèi)達(dá)到3萬億條記錄。
- 處理高吞吐量查詢：在高峰時(shí)間，系統(tǒng)處理平均每秒在1200萬個(gè)帖子上執(zhí)行的查詢。
- 將查詢的響應(yīng)時(shí)間限制為90毫秒或更短：即使對(duì)于執(zhí)行時(shí)間最長的長尾查詢，也會(huì)發(fā)生這種情況。
- 容忍誤報(bào)：這意味著系統(tǒng)可以為用戶調(diào)出許多有趣的帖子，即使有些帖子被錯(cuò)誤地過濾掉了。
考慮到上述事實(shí)，我們需要一個(gè)具有以下功能的應(yīng)用程序架構(gòu)：
- 高可用性：當(dāng)用戶打開Zhihu的推薦頁面時(shí)，找到大量已經(jīng)閱讀過的帖子是一種糟糕的用戶體驗(yàn)。
- 出色的系統(tǒng)性能：我們的應(yīng)用具有高吞吐量和嚴(yán)格的響應(yīng)時(shí)間要求。
- 易于擴(kuò)展：隨著業(yè)務(wù)的發(fā)展和應(yīng)用程序的發(fā)展，我們希望我們的系統(tǒng)可以輕松擴(kuò)展。
勘探
為了構(gòu)建具有上述功能的理想架構(gòu)，我們在之前的架構(gòu)中集成了三個(gè)關(guān)鍵組件：
- 代理：這會(huì)將用戶的請求轉(zhuǎn)發(fā)給可用節(jié)點(diǎn)，并確保系統(tǒng)的高可用性。
- 緩存：這暫時(shí)處理內(nèi)存中的請求，因此我們并不總是需要處理數(shù)據(jù)庫中的請求。這可以提高系統(tǒng)性能。
- 存儲(chǔ)：在使用TiDB之前，我們在獨(dú)立的 MySQL上管理我們的業(yè)務(wù)數(shù)據(jù)。隨著數(shù)據(jù)量的激增，獨(dú)立的MySQL系統(tǒng)還不夠。然后我們采用了 MySQL分片和Master High Availability Manager（ MHA）的解決方案，但是當(dāng)每月有1000億條新記錄涌入我們的數(shù)據(jù)庫時(shí)，這個(gè)解決方案是不可取的。
MySQL Sharding和MHA的缺點(diǎn)
MySQL分片和MHA并不是一個(gè)好的解決方案，因?yàn)镸ySQL分片和MHA都有它們的缺點(diǎn)。
MySQL分片的缺點(diǎn)：
- 應(yīng)用程序代碼變得復(fù)雜且難以維護(hù)。
- 更改現(xiàn)有的分片鍵很麻煩。
- 升級(jí)應(yīng)用程序邏輯會(huì)影響應(yīng)用程序的可用性。
MHA的缺點(diǎn)：
- 我們需要通過編寫腳本或使用第三方工具來實(shí)現(xiàn)虛擬IP（VIP）配置。
- MHA僅監(jiān)視主數(shù)據(jù)庫。
- 要配置MHA，我們需要配置無密碼安全Shell（ SSH）。這可能會(huì)導(dǎo)致潛在的安全風(fēng)險(xiǎn)。
- MHA不為從屬服務(wù)器提供讀取負(fù)載平衡功能。
- MHA只能監(jiān)視主服務(wù)器（而不是從主服務(wù)器）是否可用。
在我們發(fā)現(xiàn)TiDB并將數(shù)據(jù)從MySQL遷移到TiDB之前，數(shù)據(jù)庫可伸縮性仍然是整個(gè)系統(tǒng)的弱點(diǎn)。
什么是TiDB？
TiDB平臺(tái)是一組組件，當(dāng)它們一起使用時(shí)，它們將成為具有HTAP功能的NewSQL數(shù)據(jù)庫。
圖1 TiDB平臺(tái)架構(gòu)
在TiDB平臺(tái)內(nèi)部，主要組件如下：
- TiDB服務(wù)器是一個(gè)無狀態(tài)的SQL層，它處理用戶的SQL查詢，訪問存儲(chǔ)層中的數(shù)據(jù)，并將相應(yīng)的結(jié)果返回給應(yīng)用程序。它與MySQL兼容并且位于TiKV之上。
- TiKV服務(wù)器是數(shù)據(jù)持久存在的分布式事務(wù)鍵值存儲(chǔ)層。它使用 Raft共識(shí)協(xié)議進(jìn)行復(fù)制，以確保強(qiáng)大的數(shù)據(jù)一致性和高可用性。
- TiSpark集群也位于TiKV之上。它是一個(gè)Apache Spark插件，可與TiDB平臺(tái)配合使用，支持商業(yè)智能（BI）分析師和數(shù)據(jù)科學(xué)家的復(fù)雜在線分析處理（OLAP）查詢。
- 放置驅(qū)動(dòng)程序（PD）服務(wù)器是由 etcd支持的元數(shù)據(jù)集群，用于管理和調(diào)度TiKV。
除了這些主要組件之外，TiDB還擁有一個(gè)工具生態(tài)系統(tǒng)，例如用于快速部署的 Ansible腳本，用于從MySQL 遷移的 Syncer和 TiDB數(shù)據(jù)遷移，以及用于收集對(duì)TiDB群集進(jìn)行的邏輯更改并提供增量備份的 TiDB Binlog。復(fù)制到下游（TiDB，Kafka或MySQL）。
TiDB的主要功能
TiDB的主要功能包括：
- 水平可擴(kuò)展性。
- MySQL兼容之語法。
- 具有強(qiáng)一致性的分布式事務(wù)
- 云原生架構(gòu)。
- 使用HTAP進(jìn)行最小提取，轉(zhuǎn)換，加載（ ETL）。
- 容錯(cuò)和Raft恢復(fù)。
- 在線架構(gòu)更改。
我們是如何使用TiDB的
在本節(jié)中，我將向您展示如何在Moneta的架構(gòu)中運(yùn)行TiDB以及Moneta應(yīng)用程序的性能指標(biāo)。
我們架構(gòu)中的TiDB
我們在系統(tǒng)中部署了TiDB，Moneta應(yīng)用程序的整體架構(gòu)變?yōu)椋?/p>
- 頂層：無狀態(tài)和可伸縮的客戶端API和代理。這些組件易于擴(kuò)展。
- 中間層：軟狀態(tài)組件和分層redis緩存作為主要部分。當(dāng)服務(wù)中斷時(shí)，這些組件可以通過恢復(fù)保存在TiDB群集中的數(shù)據(jù)來自我恢復(fù)服務(wù)。
- 底層：TiDB集群存儲(chǔ)所有有狀態(tài)數(shù)據(jù)。它的組件高度可用，如果節(jié)點(diǎn)崩潰，它可以自我恢復(fù)其服務(wù)。
知乎的Moneta應(yīng)用程序中的TiDB架構(gòu)
在該系統(tǒng)中，所有組件都是可自我恢復(fù)的，整個(gè)系統(tǒng)具有全局故障監(jiān)視機(jī)制。然后，我們使用 Kubernetes來協(xié)調(diào)整個(gè)系統(tǒng)，以確保整個(gè)服務(wù)的高可用性。
TiDB的性能指標(biāo)
由于我們在生產(chǎn)環(huán)境中應(yīng)用了TiDB，因此我們的系統(tǒng)具有高可用性和易于擴(kuò)展性，并且系統(tǒng)性能得到顯著改善。
例如，在2019年6月為Moneta應(yīng)用程序采用一組性能指標(biāo)：
在高峰時(shí)間每秒寫入40,000行數(shù)據(jù)。
每秒寫入的數(shù)據(jù)行（數(shù)千）
在高峰時(shí)段每秒檢查30,000個(gè)查詢和1200萬個(gè)帖子。
每秒寫入的數(shù)據(jù)行（數(shù)千）
第99百分位響應(yīng)時(shí)間約為25毫秒，第999百分位響應(yīng)時(shí)間約為50毫秒。實(shí)際上，平均響應(yīng)時(shí)間遠(yuǎn)遠(yuǎn)小于這些數(shù)字，即使對(duì)于需要穩(wěn)定響應(yīng)時(shí)間的長尾查詢也是如此。
第99百分位響應(yīng)時(shí)間
第999百分位響應(yīng)時(shí)間
我們學(xué)到了什么？
我們遷移到TiDB并非順利。在這里，我們想分享一些經(jīng)驗(yàn)教訓(xùn)。
更快地導(dǎo)入數(shù)據(jù)
我們使用TiDB數(shù)據(jù)遷移（DM）來收集MySQL增量binlog文件，然后使用 TiDB Lightning將數(shù)據(jù)快速導(dǎo)入TiDB集群。
令我們驚訝的是，將這1.1萬億條記錄導(dǎo)入TiDB只用了四天時(shí)間。如果我們邏輯地將數(shù)據(jù)寫入系統(tǒng)，可能需要一個(gè)月或更長時(shí)間。如果我們有更多的硬件資源，我們可以更快地導(dǎo)入數(shù)據(jù)。
減少查詢延遲
完成遷移后，我們測試了少量的讀取流量。當(dāng)Moneta應(yīng)用程序首次上線時(shí)，我們發(fā)現(xiàn)查詢延遲不符合我們的要求。為解決延遲問題，我們與PingCap工程師合作調(diào)整系統(tǒng)性能。
在此過程中，我們積累了寶貴的數(shù)據(jù)和數(shù)據(jù)處理知識(shí)：
- 有些查詢對(duì)查詢延遲很敏感，有些則不然。我們部署了一個(gè)單獨(dú)的TiDB數(shù)據(jù)庫來處理對(duì)延遲敏感的查詢。（其他非延遲敏感的查詢在不同的TiDB數(shù)據(jù)庫中處理。）這樣，大型查詢和對(duì)延遲敏感的查詢在不同的數(shù)據(jù)庫中處理，前者的執(zhí)行不會(huì)影響后者。
- 對(duì)于沒有理想執(zhí)行計(jì)劃的查詢，我們編寫了SQL提示來幫助執(zhí)行引擎選擇最佳執(zhí)行計(jì)劃。
- 我們使用低精度時(shí)間戳Oracle（ TSO）和預(yù)處理語句來減少網(wǎng)絡(luò)往返。
評(píng)估資源
在我們嘗試TiDB之前，我們沒有分析我們需要多少硬件資源來支持MySQL端的相同數(shù)據(jù)量。為了降低維護(hù)成本，我們在單主機(jī) - 單從機(jī)拓?fù)渲胁渴鹆薓ySQL。相反，在TiDB中實(shí)現(xiàn)的 Raft協(xié)議至少需要三個(gè)副本。因此，我們需要更多的硬件資源來支持TiDB中的業(yè)務(wù)數(shù)據(jù)，我們需要提前準(zhǔn)備機(jī)器資源。
一旦我們的數(shù)據(jù)中心設(shè)置正確，我們就可以快速完成對(duì)TiDB的評(píng)估。
我們對(duì)TiDB 3.0的期望
在Zhihu，反垃圾郵件和Moneta應(yīng)用程序的架構(gòu)相同。我們在用于生產(chǎn)數(shù)據(jù)的反垃圾郵件應(yīng)用程序中嘗試了TiDB 3.0（ TiDB 3.0.0-rc.1和 TiDB 3.0.0-rc.2）的候選版本中的 Titan和 Table Partition。
Titan縮短了延遲
反垃圾郵件應(yīng)用程序一直受到嚴(yán)重的查詢和寫入延遲折磨。
我們聽說TiDB 3.0將引入Titan，一種鍵值存儲(chǔ)引擎，用于 在使用大值時(shí)減少 RocksDB（TiKV中的底層存儲(chǔ)引擎）的寫入放大。
為了嘗試這個(gè)功能，我們在TiDB 3.0.0-rc.2發(fā)布后啟用了Titan。下圖分別顯示了與RocksDB和Titan相比的寫入和查詢延遲：
在RocksDB和Titan中編寫和查詢延遲
統(tǒng)計(jì)數(shù)據(jù)顯示，在我們啟用Titan后，寫入和查詢延遲都急劇下降。這真是太驚人了！當(dāng)我們看到統(tǒng)計(jì)數(shù)據(jù)時(shí)，我們無法相信自己的眼睛。
表分區(qū)改進(jìn)了查詢性能
我們還在反垃圾郵件應(yīng)用程序中使用了TiDB 3.0的表分區(qū)功能。使用此功能，我們可以按時(shí)將表分成多個(gè)分區(qū)。當(dāng)查詢到來時(shí)，它將在覆蓋目標(biāo)時(shí)間范圍的分區(qū)上執(zhí)行。這大大提高了我們的查詢性能。
讓我們考慮一下如果我們將來在Moneta和反垃圾郵件應(yīng)用程序中實(shí)施TiDB 3.0會(huì)發(fā)生什么。
Moneta應(yīng)用程序中的TiDB 3.0
TiDB 3.0具有諸如gRPC中的批處理消息，多線程Raftstore，SQL計(jì)劃管理和TiFlash等功能。我們相信這些將為Moneta應(yīng)用增添光彩。
gRPC和多線程Raftstore中的批處理消息
Moneta的寫入吞吐量超過每秒4萬次交易（TPS）.TiDB 3.0可以批量發(fā)送和接收Raft消息，并且可以在多個(gè)線程中處理Region Raft邏輯。我們相信這些功能將顯著提高我們系統(tǒng)的并發(fā)能力。
SQL計(jì)劃管理
如上所述，我們編寫了大量SQL提示，以使查詢優(yōu)化器選擇最佳執(zhí)行計(jì)劃。TiDB 3.0添加了一個(gè)SQL計(jì)劃管理功能，可以直接在TiDB服務(wù)器中將查詢綁定到特定的執(zhí)行計(jì)劃。使用此功能，我們不需要修改查詢文本以注入提示。
TiFlash
在TiDB DevCon 2019上，我第一次聽說TiFlash是TiDB的擴(kuò)展分析引擎。它使用面向列的存儲(chǔ)技術(shù)來實(shí)現(xiàn)高數(shù)據(jù)壓縮率，并在數(shù)據(jù)復(fù)制中應(yīng)用擴(kuò)展的Raft一致性算法以確保數(shù)據(jù)安全性。
由于我們擁有高寫入吞吐量的海量數(shù)據(jù)，因此我們無法每天使用ETL將數(shù)據(jù)復(fù)制到 Hadoop進(jìn)行分析。但是對(duì)于TiFlash，我們樂觀地認(rèn)為我們可以輕松分析我們龐大的數(shù)據(jù)量。
反垃圾郵件應(yīng)用程序中的TiDB 3.0
與Moneta應(yīng)用程序的巨大歷史數(shù)據(jù)大小相比，反垃圾郵件應(yīng)用程序具有更高的寫入吞吐量。但是，它僅查詢過去48小時(shí)內(nèi)存儲(chǔ)的數(shù)據(jù)。在此應(yīng)用程序中，數(shù)據(jù)每天增加80億條記錄和1.5 TB。
由于TiDB 3.0可以批量發(fā)送和接收Raft消息，并且它可以在多個(gè)線程中處理Region Raft邏輯，因此我們可以用更少的節(jié)點(diǎn)管理應(yīng)用程序。以前，我們使用了七個(gè)物理節(jié)點(diǎn)，但現(xiàn)在我們只需要五個(gè)。即使我們使用商用硬件，這些功能也可提升性能。
下一步是什么
TiDB是一個(gè)與MySQL兼容的數(shù)據(jù)庫，因此我們可以像使用MySQL一樣使用它。由于TiDB的橫向可擴(kuò)展性，現(xiàn)在我們可以自由擴(kuò)展我們的數(shù)據(jù)庫，即使我們有超過一萬億的記錄來應(yīng)對(duì)。
到目前為止，我們已經(jīng)在我們的應(yīng)用程序中使用了相當(dāng)多的開源軟件。我們還學(xué)到了很多關(guān)于使用TiDB處理系統(tǒng)問題的知識(shí)。我們決定參與開發(fā)開源工具，并參與社區(qū)的長期發(fā)展。基于我們與PingCAP的共同努力，TiDB將變得更加強(qiáng)大和強(qiáng)大。
