2020年是云原生數(shù)據(jù)庫PolarDB全面支撐天貓雙十一的第二年，天貓交易、買家、賣家以及物流等系統(tǒng)在雙十一期間基于PolarDB為億萬客戶提供了順滑的體驗。同時，PolarDB還刷新了去年由自己創(chuàng)造的數(shù)據(jù)庫處理峰值（TPS）紀錄，今年TPS峰值高達1.4億次/秒，較去年提升了60%。

PolarDB是阿里自研的云原生數(shù)據(jù)庫品牌， 通過獨有的存儲計算分離、分布式共享存儲技術(shù)，解決了傳統(tǒng)RDBMS容量有限、擴縮容時間長等問題， 在性能、容量、彈性、以及可用性上都有很大的突破：
? 存儲容量可達100TB，單庫可擴展到16個節(jié)點，滿足企業(yè)級大數(shù)據(jù)存儲需求。
? 高性能、高彈性、低成本，一寫多讀，分鐘級擴縮容
? 多AZ高可用，數(shù)據(jù)高可靠性。跨AZ六副本，故障快速容災(zāi)轉(zhuǎn)移
PolarDB今年下半年發(fā)布了MySQL 5.7的兼容版。至此PolarDB成為全球唯一一家兼容 MySQL 所有在役版本的云數(shù)據(jù)庫，可以覆蓋更多的業(yè)務(wù)場景

性能優(yōu)化

性能對于雙十一大促來說是永恒的主題。在天貓的核心交易鏈路的數(shù)據(jù)庫，在零點峰值場景中，會有大量的數(shù)據(jù)讀寫。而每一年隨著峰值的增長，數(shù)據(jù)庫會遇到更嚴峻的挑戰(zhàn)。在過去的幾年中，隨著數(shù)據(jù)庫硬件的不斷進化，我們?yōu)镻olarDB重點優(yōu)化了索引結(jié)構(gòu)、I/O子系統(tǒng)、鎖系統(tǒng)以及事務(wù)系統(tǒng)來完成并發(fā)性能的提升。

首先是索引結(jié)構(gòu)。眾所周知傳統(tǒng)的InnoDB 索引在這樣的場景下會遇到頻繁的頁面分裂導(dǎo)致的并發(fā)瓶頸。所有的對索引結(jié)構(gòu)的修改都要排隊串行執(zhí)行。為了解決這個問題， PolarDB引入了新的索引結(jié)構(gòu)來替代傳統(tǒng)索引，細化索引結(jié)構(gòu)變更時的并發(fā)粒度，提升了接近20%的讀寫性能。新的索引結(jié)構(gòu)使得原本需要將所有涉及索引分裂的頁面加鎖直到整個分裂動作完成后才釋放的邏輯變成逐層加鎖。這樣原本被索引頁面分裂阻塞的讀操作會有機會在整個分裂動作中間進來：通過對每個節(jié)點增加一個后繼鏈接的方式，使得在分裂的中間狀態(tài)也可以完成對數(shù)據(jù)頁面的安全的訪問，從而提高讀取性能。

其次是IO子系統(tǒng)。由于PolarDB是采用的用戶態(tài)文件系統(tǒng)， 因此需要有一套對應(yīng)的IO系統(tǒng)來確保對底層分布式存儲的高效訪問， InnoDB原有的AIO策略，是將所有異步IO請求按照目標地址進行組織存放在同一個IO數(shù)組中，方便將目標地址連續(xù)的小IO合并成大IO以提升IO的吞吐，但是在分布式存儲的場景下連續(xù)的大IO操作，會使得同一時刻，只有一個或少量存儲節(jié)點處在服務(wù)狀態(tài)，其他的存儲節(jié)點處于空閑狀態(tài)，此外，分布式存儲在高IO負載的場景中會出現(xiàn)網(wǎng)絡(luò)中的Inflight IO較多的情況，IO任務(wù)數(shù)組中添加I和移除請求的開銷都很大。為此PolarDB專門對IO系統(tǒng)進行了重新的設(shè)計，主要包括：合理的選擇IO合并和拆解，充分利分布式存儲的多節(jié)點優(yōu)勢；建立狀態(tài)有序的IO服務(wù)隊列，減少高負載下的IO服務(wù)開銷。新的子系統(tǒng)讓PolarDB在寫入和讀寫混合的場景下性能和穩(wěn)定性都得到了顯著的性能提升。

再接下來是鎖系統(tǒng)的優(yōu)化。 PolarDB和MySQL一樣都是采用MVCC的方式看來做事務(wù)之間的并發(fā)控制， 但是在處理寫請求和寫請求之間的并發(fā)時是通過兩階段的鎖來做保護的。大量且頻繁的插入更新刪除帶來了鎖系統(tǒng)的負擔和并發(fā)的瓶頸。 因此PolarDB采取了Partition Lock System的方式，將鎖系統(tǒng)改造成由多個分片組成，每個分片中都有自己局部的并發(fā)控制，從而將這個瓶頸打散。尤其是在這種大壓力的寫入場景下明顯的提升寫入性能。

最后是事務(wù)系統(tǒng)。 PolarDB中支持Snapshot Isolation的隔離級別，通過保留使用的Undo版本信息來支持對不同版本的記錄的訪問，即MVCC。而實現(xiàn)MVCC需要事務(wù)系統(tǒng)有能力跟蹤當前活躍及已經(jīng)提交的事務(wù)信息。在之前的實現(xiàn)中每當有寫事務(wù)開始時，需要分配一個事務(wù)ID，并將這個ID添加到事務(wù)系統(tǒng)中的一個活躍事務(wù)列表中。當有讀請求需要訪問數(shù)據(jù)時，會首先分配一個ReadView，其中包括當前已分配最大的事務(wù)ID，以及當前這個活躍事務(wù)列表的一個備份。每當讀請求訪問數(shù)據(jù)時，會通過從索引開始的指針訪問到這個記錄所有的歷史版本，通過對比某個歷史版本的事務(wù)ID和自己ReadView中的活躍事務(wù)列表，可以判斷是不是需要的版本。然而，這就導(dǎo)致每當有讀事務(wù)開始時，都需要在整個拷貝過程對這個活躍事務(wù)列表加鎖，從而阻塞了新的寫事務(wù)將自己的ID加入。同樣寫事務(wù)和寫事務(wù)之間也有訪問活躍事務(wù)列表的沖突。從而活躍事務(wù)列表在這里變成一個明顯的性能瓶頸，在雙十一這種大壓力的讀寫場景下尤為明顯。對此，我們將事務(wù)系統(tǒng)中的這個活躍事務(wù)列表改造成無鎖Hash實現(xiàn)，寫事務(wù)添加ID以及讀事務(wù)拷貝到ReadView都可以并發(fā)進行。大大提升了性能。

全球數(shù)據(jù)庫技術(shù)

諸如AliExpress這一類針對海外消費者的購物大促，業(yè)務(wù)遍及各個大洲和國家等等。因此數(shù)據(jù)庫的異地可讀，數(shù)據(jù)同步有非常高的要求。在過去DTS承載了區(qū)域間數(shù)據(jù)同步任務(wù)，DTS訂閱了二進制日志然后分發(fā)到不同的區(qū)域并進行高速應(yīng)用以實現(xiàn)區(qū)域間數(shù)據(jù)狀態(tài)一致性。今年P(guān)olarDB集成了全新的全球數(shù)據(jù)庫技術(shù)來解決跨域訪問以及容災(zāi)的問題，PolarDB全球數(shù)據(jù)庫（PolarDB Global Database Network，PolarDB-GDN）采用了數(shù)據(jù)庫物理日志異步復(fù)制的方案。但是達成以上目標需要解決幾個關(guān)鍵難點：高網(wǎng)絡(luò)延遲下的數(shù)據(jù)同步問題和跨Region的數(shù)據(jù)讀寫問題。針對這兩點問題，PolarDB-GDN通過高并發(fā)流水線技術(shù)將同步速度提升7倍，將數(shù)據(jù)跨大洲同步延遲控制在2秒內(nèi)。 全局讀寫分離技術(shù)結(jié)合多級別的一致性能力， 讓業(yè)務(wù)不用做任何的改造的前提下降低整體的訪問延遲。

熱緩存技術(shù)

雙十一對數(shù)據(jù)庫的可用性要求非常高，核心應(yīng)用在大促期間處于高負載的狀態(tài)，長時間高負荷的運行不可避免會存在單一節(jié)點的故障，如何能快速恢復(fù)成為了一個重要的課題。過去的節(jié)點故障恢復(fù)需要經(jīng)歷相當長的時間的恢復(fù)時間，而重啟拉起后的系統(tǒng)還需要緩存預(yù)熱后才能達到最佳訪問性能。

PolarDB今年在存儲計算分離架構(gòu)上繼續(xù)往前邁進一大步，實現(xiàn)了計算和內(nèi)存的分離。通過將內(nèi)存緩沖池從計算節(jié)點剝離，讓計算節(jié)點狀態(tài)最小化 。計算節(jié)點重啟后可以快速恢復(fù)到重啟前的狀態(tài)，避免大量耗時的緩存預(yù)熱。傳統(tǒng)數(shù)據(jù)庫的錯誤恢復(fù)需要檢查點開始掃描所有的redo日志、回放日志、事務(wù)恢復(fù)等步驟，該過程涉及大量磁盤IO、CPU計算等工作量，其時間往往很長。使用了熱緩存技術(shù)的PolarDB在計算節(jié)點崩潰后，需要恢復(fù)的是緩存可能處于不一致的狀態(tài)，如部分尚未修改完成的緩存頁面以及內(nèi)存結(jié)構(gòu)等。而在CPU緩存分離的架構(gòu)下只需要新的計算節(jié)點來根據(jù)各種控制信息和redo日志將這些被污染的內(nèi)存恢復(fù)到一致的狀態(tài)。因為無需重新構(gòu)建緩存池，修復(fù)工作量小。在常規(guī)讀寫負載下，重啟后的數(shù)據(jù)庫最大吞吐下降到原來的5%以下，并在200秒后逐漸恢復(fù)正常水平，而利用了熱緩存技術(shù)的實例幾乎無任何性能下降。

跨AZ容災(zāi)能力

雙十一的核心業(yè)務(wù)必須要能夠跨AZ的容災(zāi)， PolarDB提供了跨AZ容災(zāi)RPO為0的方案。PolarDB 在存儲層（PolarStore）提供3副本的同時，還可以通過自研的 X-Paxos 庫提供跨節(jié)點、跨機房、跨 AZ 級別的數(shù)據(jù)同步能力，提供 RPO = 0 的容災(zāi)解決方案。這個方案利用 PolarDB 經(jīng)過多年驗證的物理復(fù)制技術(shù)和 X-Paxos 一致性協(xié)議庫，提供高可靠、低延遲的數(shù)據(jù)復(fù)制技術(shù)。相比于 RDS/MySQL 的邏輯日志復(fù)制，PolarDB 在節(jié)點切換時，受大事務(wù)/DDL 的影響更小，RTO 小于1分鐘。同時，這個方案在保證數(shù)據(jù)冗余的同時，盡量減少部署成本。PolarDB 跨AZ版可以部署Leader，Follower 和 Log 節(jié)點。其中 Log 節(jié)點只記錄日志，不參與選主，不存儲數(shù)據(jù)，部署成本相比于現(xiàn)有架構(gòu)只增加了 active redo log ，顯著降低了部署成本。

并行查詢增強

雙十一不僅是消費者的盛筵， 也是眾多賣家的狂歡。 賣家經(jīng)常需要實時的查詢自己的銷售數(shù)據(jù)以及做一些快速的分析。PolarDB擁有查詢引擎，在眾多場景下能滿足一些即時查詢的需求，它充分利用硬件多核優(yōu)勢，并基于COST自動選擇并行查詢引擎，顯著提升了查詢性能。今年P(guān)olarDB在該方向并沒有停止腳步，利用并行查詢引擎了優(yōu)化更多的應(yīng)用場景。在大規(guī)格的實例中， 并行的提升效果尤為顯著。

在今年， PolarDB的并行查詢新增加了眾多場景的覆蓋， 有聯(lián)合(Union)子查詢的并行優(yōu)化，擴展并行查詢引擎對聯(lián)合(Union)子查詢的支持；派生表(Derived Table)的并行優(yōu)化；用戶自定義臨時表的并行優(yōu)化；Count的并行優(yōu)化；Limit的并行優(yōu)化；條件下推優(yōu)化，減少數(shù)據(jù)匯總代價；HASH JOIN 的并行優(yōu)化，同時優(yōu)化算子和執(zhí)行的并行度。

除此之外， POLARDB對GROUP BY / Distinct / SEMI-JOIN / 常量表以及包含Window函數(shù)的子查詢也做了并行優(yōu)化，通過利用更多的CPU資源， 有效降低了這些場景下的查詢耗時。在標準的TPC-H場景下，POLARDB的并行查詢框架取得了非常好的表現(xiàn)。

并行schema變更

在阿里的業(yè)務(wù)中大量的POLARDB承載了超大規(guī)模的數(shù)據(jù)，然而業(yè)務(wù)的需求是實時變化的。過去對這些大表做DDL會持續(xù)數(shù)小時甚至數(shù)天，如此之高的延遲是難以容忍的。以創(chuàng)建二級索引為例，過高延遲的DDL操作會阻塞后續(xù)依賴新索引查詢的DML操作。DDL操作會消耗CPU/Memory/IO資源，對業(yè)務(wù)DML帶來一定的影響，因此用戶往往在業(yè)務(wù)低峰期進行schema變更，但是如果不能確保變更在業(yè)務(wù)低峰期之內(nèi)完成會對業(yè)務(wù)的穩(wěn)定性產(chǎn)生嚴重的影響。

我們認為大表DDL運行緩慢的根本原因在于傳統(tǒng)的DDL操作是針對單核和傳統(tǒng)硬盤設(shè)計的。隨著多核處理器的日益發(fā)展和高速存儲的普及，DDL的并行化是可以取得非常好的效果的。

Online DDL分為創(chuàng)建臨時表掃描拷貝全量數(shù)據(jù)加上增量應(yīng)用期間的變更等幾個主要階段。以增加索引為例需要掃描主鍵所有記錄，生成新的二級索引記錄，寫入磁盤文件中；對所有二級索引記錄進行排序，寫入磁盤文件；將有序的二級索引記錄插入到新的二級索引中。

POLARDB可以對索引樹進行并行掃描、并行多路歸并的Merge Sort、并行的Bulk Load索引。 在8core32G規(guī)格的實例中針對CPU Bound 和 IO Bound的場景分別進行了測試，都可以達到6-13倍的速度提升。

總結(jié)

今年的雙十一對PolarDB在性能和功能上提出了更高的要求。 PolarDB在并發(fā)性能、跨域、彈性以及可用性上都更進了一步，POLARDB不僅承載著整個阿里集團的實時OLTP數(shù)據(jù)業(yè)務(wù)，而且在云上為更為廣大的客戶提供服務(wù)。 我們的目標是將云原生的數(shù)據(jù)庫技術(shù)普惠所有的企業(yè)客戶，幫助客戶更好的實現(xiàn)業(yè)務(wù)價值。

?

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的深度| 每秒1.4亿次！再度刷新TPS记录的PolarDB如何应对双11“尖峰时刻”？的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。