1.3 萬億條數(shù)據(jù)查詢，如何做到毫秒級響應(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 毫秒或更短：即使對于執(zhí)行時(shí)間最長的長尾查詢，也會(huì)發(fā)生這種情況。
• 容忍誤報(bào)：這意味著系統(tǒng)可以為用戶調(diào)出許多有趣的帖子，即使有些帖子被錯(cuò)誤地過濾掉了。

• 高可用性：當(dāng)用戶打開知乎的推薦頁面時(shí)，找到大量已經(jīng)閱讀過的帖子是一種糟糕的用戶體驗(yàn)。
• 出色的系統(tǒng)性能：我們的應(yīng)用具有高吞吐量和嚴(yán)格的響應(yīng)時(shí)間要求。
• 易于擴(kuò)展：隨著業(yè)務(wù)的發(fā)展和應(yīng)用程序的發(fā)展，我們希望我們的系統(tǒng)可以輕松擴(kuò)展。

• 代理：這會(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 分片的缺點(diǎn)：

• 應(yīng)用程序代碼變得復(fù)雜且難以維護(hù)。
• 更改現(xiàn)有的分片鍵很麻煩。
• 升級應(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ù)器）是否可用。

• 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。

• 水平可擴(kuò)展性。
• MySQL 兼容的語法。
• 具有強(qiáng)一致性的分布式事務(wù)。
• 云原生架構(gòu)。
• 使用 HTAP 進(jìn)行最小提取，轉(zhuǎn)換，加載（ ETL）。
• 容錯(cuò)和 Raft 恢復(fù)。
• 在線架構(gòu)更改。

• 頂層：無狀態(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ù)。

• 有些查詢對查詢延遲很敏感，有些則不然。我們部署了一個(gè)單獨(dú)的 TiDB 數(shù)據(jù)庫來處理對延遲敏感的查詢。（其他非延遲敏感的查詢在不同的 TiDB 數(shù)據(jù)庫中處理。）
  這樣，大型查詢和對延遲敏感的查詢在不同的數(shù)據(jù)庫中處理，前者的執(zhí)行不會(huì)影響后者。
• 對于沒有理想執(zhí)行計(jì)劃的查詢，我們編寫了 SQL 提示來幫助執(zhí)行引擎選擇最佳執(zhí)行計(jì)劃。
• 我們使用低精度時(shí)間戳 Oracle（ TSO）和預(yù)處理語句來減少網(wǎng)絡(luò)往返。

④gRPC 和多線程?Raftstore 中的批處理消息

⑤SQL?計(jì)劃管理

⑥TiFlash

⑦反垃圾郵件應(yīng)用程序中的 TiDB 3.0

點(diǎn)個(gè)在看支持我吧，轉(zhuǎn)發(fā)就更好了