RDS釋出會解讀｜ AliSQL核心新特性

作者：樓方鑫（黃忠）

AliSQL在2020年做了不少事情，有必要總結分享一下，以便讓大家更好地知道有哪些特性，可以在哪些業務場景中使用到，也是為了在2021年更好的向前發展。在年初時計劃的一些企業級功能基本上都實現了，並且在過程中特別強調了功能的場景通用性，不再是從某個行業某個特定業務或應用場景設計（比如電商秒殺），而是從雲上眾多使用者的不同場景出發，並且不需要使用者應用或SQL改造配合（直接一個開關就可以開啟的），還要求在RDS 56/57/80三個主流版本上都有同樣的體驗，從雲場景而生併為雲場景服務的技術，都是雲原生技術。這一目標角度的調整的確是給自己加了不少難度，但研發讓所有云上使用者都能輕鬆受益享受技術紅利的新技術和功能，仍然讓整個AliSQL團隊興奮不已。

先來看一下2020年已經上線並且使用非常廣泛幾個功能和技術： • InnoDB Mutex Tuning，InnoDB使用B+ Tree來組織資料，當樹的Branch節點需要分裂時，可能會層層向上直到根部，這個分裂是非常昂貴並且難以併發的操作，會嚴重影響效能。AliSQL在InnoDB的Index Mutex上做了最佳化，減少了所有頁面分列的代價，改進演算法最佳化了分裂的頻率和深度，使得TPCC的效能測試提升了35-45%，並且在56/57/80三個版本上都已支援，已在100000+使用者的數十萬例項上平穩執行一週年多了。

• Dynamic Thread Pool，AliSQL團隊透過技術創新和改進，於年初在雲上預設開啟了執行緒池，56/57/80三個版本都已支援，已有100000+使用者的數十萬例項執行線上程池下，也就是讓執行緒池不再挑場景，可以輕鬆勝任高併發的混合請求場景，而不像其他分支（如Percona或MariaDB）的執行緒池那樣要求都是短平快的查詢。到目前為止，我們應當是唯一一家預設開啟執行緒池功能的RDS供應商，可以讓例項支援更高的連線數，可以承受更強的短連線能力，可以節約寶貴的CPU和記憶體資源，可以提升上千併發（真實應用中連線數上千很容易）下的效能，讓RDS客戶在用更少資源得到更高QPS&TPS，享受到實實在在的技術紅利。

• Faster DDL，在遇到幾次使用者業務高峰對小表做DDL的效能抖動後，AliSQL團隊深入分析了整個DDL過程，發現在DDL過程中Buffer Pool的管理方式不夠優雅，就對其進行了改進，並在56/57/80三個版本上同步實現併發布上線，目前已有100000+使用者的數十萬例項開啟了此功能，極大的縮短了業務高峰進行DDL所需的時間，有效地消除了穩定性風險，讓阿里雲RDS客戶享受到了實實在在的好處。

• Performance Agent，為了更好地排查效能問題，AliSQL團隊研發了一個Performance Agent外掛，以秒級頻率和完全無鎖的方式（相比在SQL中執行show global status命令）輸出了數百個效能指標，並且提供了記憶體檢視來查詢和分析這些效能資料，使得我們和客戶可以基於同一份效能資料來快速高效地分析效能問題。同樣在56/57/80三個版本上都實現了Performance Agent，已有100000+使用者的數十萬例項每秒鐘都在記錄實時效能資料。

再來看一下2020年上線但還未達到上述使用量的功能和技術：

• Binlog In Redo，MySQL為了保證Binlog和InnoDB資料的一至性，使用兩階段XA事務來協調Binlog的落盤和InnoDB Redo Log的落盤，這時每一個事務的提交需要做兩次刷盤操作，這對一些對時延（RT，Response Time）敏感的應用，或者使用雲盤的例項是不夠理想的。AliSQL團隊對事務提交過程進行了仔細嚴謹的梳理，提出了將Binlog寫到Redo Log的方案，使得事務提交時不再需要同步Binlog檔案，僅需要同步Redo Log，相當於減少了一次落盤操作，從而在保證資料一致性的基礎上縮短了事務提交操作的延時，並且提升了事務提交的效能。 • Fast Query Cache，在架構設計中Cache為王，看Oracle 21中增加了對持久化記憶體的支援，累計達到7層快取設計，我們當然不能放過Query Cache。Query Cache具有對應用完全透明的優勢，在仔細壓測分析原生Query Cache功能後，發現效能不夠理想後，設計出了版本化的Fast Query Cache技術，解決了原生Query Cache中的併發性限制，使得純讀效能最高可以提升100%+，並且在寫場景中基本沒有額外效能損耗。歡迎大家來使用Fast Query Cache，如今已經可以自行調整記憶體引數進行開啟，如果你還在用原生的Query Cache，則可以升級到較新的版本，來享受AliSQL帶來了Cache技術紅利。

• Recycle Bin & Data Protect，在2020年業界發生了幾次由刪庫刪表引起的安全事故，我們深表痛惜和警覺，AliSQL團隊設計了Recycle Bin和Data Protect功能，以主動應對類似風險。Recycle Bin會自動將刪除的表先移到回收站，直到進一步清空回收站（可以額外控制許可權）時才會真正刪除表，在Purge之前都可以從回收站中還原資料；而Data Protect則可以嚴格限制可以執行刪除操作的使用者，從許可權和目標兩個維度進行控制，以幫助大家保障資料安全（需要自行開啟）。

再來提前看一下2020年研發完成還未上線的功能和技術（會在2021年Q1釋出上線）：

• Flashback Query，有時侯可能面臨執行錯誤DML語句（比如Delete/Update沒有準確的Where條件）的緊急場景，會要求我們快速將資料恢復到錯誤DML語句執行之前的資料狀態，過去我們需要去下載、分析Binlog檔案，再利用工具去生成反向操作的SQL語句進行恢復，步驟比較複雜。在具備Flashback Query技術後，可以直接穿越到過去的時間點（誤操作之前的）執行SQL語句，將準確的資料找出來進行快速恢復。

• Buffer Pool Freely Resize，為了提升RDS的記憶體彈性，AliSQL團隊仔細研究分析了InnoDB Buffer Pool動態調整的邏輯，識別並最佳化了相關邏輯，使得線上縮減Buffer Pool大小變得基本沒有風險，讓不重啟例項的記憶體規格彈性在技術上先成為可能。

• MultiBlock Read，針對使用者反饋的大表DDL或大查詢慢的問題，AliSQL團隊仔細分析了Buffer IO的程式碼邏輯，並找到了其中的欠缺，每次只讀一個塊是非常低效的行為，對於連續的資料塊訪問（Range Scan或Full Table Scan）可以一次性讀取多個塊來提升IO效率，從而使得大表掃描的速度提以大幅度提升，也就是說大查詢或DDL的時間有望縮短25-50%左右。

• Faster LRU Scan，有相當一部份客戶的業務發展非常好，資料量激增，給系統帶來壓力，在分析和支援客戶發展的過程中，AliSQL團隊發現原生MySQL的Buffer Pool LRU淘汰機制有欠缺，在訪問的資料量遠大於記憶體規格時，會進入低效的Singe Page Flush淘汰機制，存在著邏輯上的欠缺。對此我們最佳化和設計了一種更好的淘態機制，使得同等情況下QPS & TPS可以提升10-20%，讓客戶在同等的資源下可以有更高的效能，為客戶切切實實地節約成本。

• Automatic Hot Queue，這是對電商熱殺秒殺功能的一個技術升級，原來需要應用更改SQL傳入熱點佇列的標識，現在則可以自動分析DML語句中的Where條件，如果是PK或UK訪問，則自動計算一個熱點佇列標識，進行併發控制排隊，無須應用更改SQL傳入熱點標識，只需要簡簡單單地在後臺開啟開關。

我們是第一個提供RDS 80服務的雲產商，給社群排查和反饋了不少問題和缺陷，其中有一些是比較嚴重的會導致Crash的，在這裡就不一一細說了。回顧2020年，真是相當忙而快樂的一年，忙是我們在努力為客戶建立價值（提供技術紅利），快樂是我們的一些技術和功能在雲上得到大量的使用，並且還有一些非常有意義的事情（空間壓縮、安全審計等方面）在等著我們去做。