對於任何一家業務快速成長的企業來講，應對峯值流量衝擊，一直是擺在技術團隊面前的一大難題。面對海量數據，數據庫及業務團隊都但願作到「無感擴容」，但流行的分庫、分表方案在擴容速度和一致性上常常不能知足需求。行業期待着性能強大、簡單易用的全新數據庫方案，從根本上解決企業面對流量高峯時的數據庫性能瓶頸。數據庫
行業需求是技術創新的最大推進力。近年來，由 PingCAP 開發的 TiDB 分佈式數據庫異軍突起，在海量數據處理領域具備很大的優點。在此背景下，2020 年初京東智聯雲聯合 PingCAP，基於 TiDB 打造了雲端分佈式數據庫——Cloud-TiDB。瀏覽器
11 月 26 日，京東智聯雲與英特爾聯合舉辦了主題爲「突破極限，TiDB 在京東智聯雲的技術架構與實踐」的線上直播活動。直播邀請到_京東智聯云云產品研發部架構師葛集斌老師，和 PingCAP TiDB 生態技術佈道專家戚錚老師_分別帶來分享，但願藉此機會幫助更多企業和開發人員拓展思路，提供一個分庫分表途徑以外的新選擇，並瞭解如何在生產實踐中發揮 TiDB 的價值。性能優化
本文總結自本場直播分享，內容有調整。架構
1、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 S三、Spark 等。用戶無需擔憂技術鎖定風險，這也爲 TiDB 的生態繁榮打下了基礎。
在分享的最後，葛老師對雲端數據庫的發展趨勢作了展望：
分佈式是將來技術發展的重要趨勢之一，包括操做系統、應用程序和數據庫都在向分佈式轉變。TiDB 做爲分佈式數據庫，比較符合這一技術發展趨勢。與此同時，數據庫上雲能夠帶來不少好處，例如彈性調度、與 AI 結合，還能更好地理解用戶的業務視角，實現數據處理的智能優化。
長遠來看，數據庫上雲能夠在開發、運維和穩定性層面得到很大收益。正因如此，京東智聯雲選擇 TiDB 上雲，就是但願能給用戶帶來更好的使用體驗。
2、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 抖動也有明顯降低。
3、突破容量極限，TiDB打破企業數據庫性能瓶頸
相比傳統的分庫分表，TiDB 是真正一站式的分佈式數據庫總體解決方案，可以充分知足企業業務快速增加、海量數據高併發、實時數據分析和金融數據高可用等場景的苛刻需求。經過本場直播兩位老師的精彩分享，聽衆對 TiDB 數據庫的能力、實現細節和業務落地實踐都有了更深刻的認知，也瞭解了 TiDB 數據庫服務的各項突出優點。
正如兩位老師所言，分佈式數據庫是業內必然的發展趨勢，而 TiDB 順應了這一潮流，將成爲愈來愈多企業根治數據庫性能瓶頸的良方。與此同時，TiDB 在京東智聯雲的應用，爲企業快速採用 TiDB、儘早享受 TiDB 收益和價值開闢了一條便捷通道。
想要了解更多京東智聯雲與 TiDB 相關內容，獲取演講PPT，可在評論區評論PPT，咱們會及時回覆獲取方式。
點擊_【閱讀原文】_查看視頻回放連接。
推薦閱讀:
歡迎點擊【京東智聯雲】，瞭解開發者社區
更多精彩技術實踐與獨家乾貨解析
歡迎關注【京東智聯雲開發者】公衆號