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

>>釋出會傳送門

：

https://yqh.aliyun.com/live/detail/21815 點選檢視詳情 https://yqh.aliyun.com/live/2021rds

作者：樓方鑫（黃忠）

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年，真是相當忙而快樂的一年，忙是我們在努力為客戶建立價值（提供技術紅利），快樂是我們的一些技術和功能在雲上得到大量的使用，并且還有一些非常有意義的事情（空間壓縮、安全審計等方面）在等着我們去做。