背景信息

熱點(diǎn)行面臨以下問題：

• 當(dāng)一個事務(wù)對一行數(shù)據(jù)進(jìn)行更新時(shí)，會對目標(biāo)數(shù)據(jù)行加鎖，直到事務(wù)提交或回滾時(shí)才釋放。在同一時(shí)段內(nèi)，針對同一數(shù)據(jù)行，只有一個事務(wù)能夠進(jìn)行更新，而其他事務(wù)則需要等待。由此可見，對于單一熱點(diǎn)行的更新請求實(shí)際上是串行執(zhí)行的，傳統(tǒng)的分庫分表策略在性能提升方面并不會有太大幫助。

• 在電商平臺業(yè)務(wù)中，限購、秒殺是常用的促銷手段。在這些場景下，大量對熱點(diǎn)行的更新請求在極短時(shí)間間隔內(nèi)到達(dá)后臺數(shù)據(jù)庫系統(tǒng)，必然造成嚴(yán)重的行鎖競爭和等待，影響系統(tǒng)性能。如果一個更新請求等待執(zhí)行的時(shí)間變長，將會對業(yè)務(wù)層面產(chǎn)生顯著負(fù)面影響。

針對上述問題，單純提高計(jì)算機(jī)硬件配置已經(jīng)無法滿足這樣的低延遲需求。因此PolarDB在數(shù)據(jù)庫內(nèi)核層進(jìn)行了創(chuàng)新性的優(yōu)化，不但能夠自動識別熱點(diǎn)行更新請求，而且將一定時(shí)間間隔內(nèi)對同一數(shù)據(jù)行的更新操作進(jìn)行分組，不同分組采用流水線的方式并行處理，通過這些優(yōu)化，極大地提升了系統(tǒng)的性能。

技術(shù)方案

• 串行處理變流水線處理

  為了提升數(shù)據(jù)庫系統(tǒng)的性能，最直接的方法是使用并行處理，但是對同一熱點(diǎn)行的更新操作很難做到完全并行。PolarDB創(chuàng)新性地使用了流水線處理方式，最大限度地將熱點(diǎn)行更新操作并行化。

  

  熱點(diǎn)行更新操作所使用的SQL語句會用autocommit或者COMMIT_ON_SUCCESS進(jìn)行標(biāo)記。優(yōu)化后的MySQL內(nèi)核層會自動識別帶此類標(biāo)記的更新操作，在一定的時(shí)間間隔內(nèi)，將收集到的更新操作按照主鍵或者唯一鍵進(jìn)行Hash，對于Hash到同一個桶中的更新操作，會將它們按照到達(dá)的先后順序分組分批地進(jìn)行處理和提交。

  為了使用流水線方式處理這些更新操作，需要使用兩個執(zhí)行單元對它們進(jìn)行分組。當(dāng)?shù)谝粋€分組收集完畢準(zhǔn)備提交時(shí)，第二個分組立即開始收集更新操作。當(dāng)?shù)诙€分組收集完畢準(zhǔn)備提交時(shí)，第一個分組已經(jīng)提交完畢并開始收集新一批的更新操作，兩個分組不斷切換，并行執(zhí)行。

  現(xiàn)如今多核CPU的使用已經(jīng)非常普遍。這樣的流水線式的處理方式能夠充分利用硬件資源，提升CPU的使用率和數(shù)據(jù)庫系統(tǒng)的并行處理能力，從而最大限度地提升數(shù)據(jù)庫系統(tǒng)的吞吐量。

• 消除申請行鎖時(shí)的等待

  為了保證數(shù)據(jù)的邏輯一致性，對一個數(shù)據(jù)行進(jìn)行更新時(shí)，首先會對該數(shù)據(jù)行加鎖。如果加鎖請求無法立刻滿足，則進(jìn)入等待狀態(tài)。這樣一來，不但增加了處理延遲，還會觸發(fā)死鎖檢測，導(dǎo)致額外的資源消耗。

  前面提到，我們會按照時(shí)間順序?qū)ν粩?shù)據(jù)行的更新操作進(jìn)行分組。組內(nèi)第一個更新操作為Leader，其讀取目標(biāo)數(shù)據(jù)行并且加鎖。后續(xù)更新操作為Follower，其對目標(biāo)數(shù)據(jù)行加鎖時(shí)，如果發(fā)現(xiàn)Leader已經(jīng)持有行鎖，無需等待，直接獲得行鎖。

  通過這個優(yōu)化，能夠減少行鎖的加鎖次數(shù)和時(shí)間開銷，整個數(shù)據(jù)庫系統(tǒng)的性能顯著提升。

• 減少B-tree索引的遍歷

  MySQL是以B-tree索引的方式管理數(shù)據(jù)的。每次執(zhí)行查詢時(shí)，都需要遍歷索引才能定位到目標(biāo)數(shù)據(jù)行，數(shù)據(jù)表越大，索引層級越多，遍歷時(shí)間就越長。

  在前面提到的對更新操作進(jìn)行分組的機(jī)制中，只有每組的Leader遍歷索引定位數(shù)據(jù)行，之后把更新后的數(shù)據(jù)行緩存（Row Cache）在內(nèi)存中。同組的Follower加鎖成功后，直接從內(nèi)存中讀取目標(biāo)數(shù)據(jù)行，不需要再次遍歷索引。

  這樣一來，從整體上減少了索引遍歷的次數(shù)和時(shí)間開銷。

前提條件

• PolarDB集群數(shù)據(jù)庫引擎需為以下版本之一：

  • MySQL 5.6，且內(nèi)核小版本需為20200601及以上版本。

  • MySQL 5.7，且內(nèi)核小版本需為5.7.1.0.17及以上版本。

  • MySQL 8.0，且內(nèi)核小版本需為8.0.1.1.10及以上版本。

• PolarDB MySQL版集群已開啟Binlog。

• 集群參數(shù)rds_ic_reduce_hint_enable處于關(guān)閉狀態(tài)。

使用限制

在以下場景中，熱點(diǎn)行性能優(yōu)化將不會被使用：

• 熱點(diǎn)行所屬的數(shù)據(jù)表是分區(qū)表。

• 熱點(diǎn)行所屬的數(shù)據(jù)表上定義了觸發(fā)器（Trigger）。

• 熱點(diǎn)行使用了Statement Queue機(jī)制。

• 在全局Binlog開啟的情況下，若會話級別的Binlog關(guān)閉，執(zhí)行UPDATE語句將不會使用熱點(diǎn)行性能優(yōu)化。

使用說明

1. 開啟熱點(diǎn)行性能優(yōu)化功能。

   您可以在PolarDB控制臺上修改以下參數(shù)，以開啟或關(guān)閉熱點(diǎn)行性能優(yōu)化功能。

   參數(shù)	說明
   hotspot	熱點(diǎn)行性能優(yōu)化功能總開關(guān)。取值范圍如下： ON：開啟。 OFF（默認(rèn)）：關(guān)閉。

   說明

   • 如何修改集群參數(shù)，請參見設(shè)置集群參數(shù)和節(jié)點(diǎn)參數(shù)。

   • 集群參數(shù)在PolarDB控制臺上都已加上MySQL配置文件的兼容性前綴loose_。如果您需要在PolarDB控制臺修改hotspot參數(shù)，請選擇帶loose_前綴的參數(shù)（即loose_hotspot）進(jìn)行修改。

2. 使用Hint語法來使用熱點(diǎn)行性能優(yōu)化功能。

   Hint	是否必選	說明
   COMMIT_ON_SUCCESS	必選	更新成功時(shí)提交。
   ROLLBACK_ON_FAIL	可選	更新失敗時(shí)回滾。
   TARGET_AFFECT_ROW(1)	可選	顯式指定該請求只會更新一行，若不符合則更新失敗。

   說明

   由于Hint語法生效會自動提交事務(wù)，因此Hint需要位于事務(wù)的最后一條SQL語句。

   示例：更新sbtest表中c列的數(shù)值。

   UPDATE /*+ COMMIT_ON_SUCCESS ROLLBACK_ON_FAIL TARGET_AFFECT_ROW(1) */ sbtest SET c = c + 1 WHERE id = 1;

相關(guān)操作

SHOW variables LIKE "hotspot%";

+------------------------------+-------+
|Variable_name                 | Value |
+------------------------------+-------+
|hotspot                       | OFF   |
|hotspot_for_autocommit        | OFF   |
|hotspot_lock_type             | OFF   |
|hotspot_update_max_wait_time  | 100   |
+------------------------------+-------+

SHOW GLOBAL status LIKE 'Group_update%';

性能測試

• 測試所需的數(shù)據(jù)表定義和測試語句如下：

  • 數(shù)據(jù)表定義

    CREATE TABLE sbtest (id INT UNSIGNED NOT NULL, c BIGINT UNSIGNED NOT NULL, PRIMARY KEY (id));

  • 測試語句

    UPDATE /*+ COMMIT_ON_SUCCESS ROLLBACK_ON_FAIL TARGET_AFFECT_ROW(1) */ sbtest SET c = c + 1 WHERE id = 1;

• 測試工具：Sysbench。

• 測試場景和測試結(jié)果。

  • 測試場景1：單個熱點(diǎn)行加8核CPU。

    測試結(jié)果：在單熱點(diǎn)行加8核CPU的場景下，引入熱點(diǎn)行性能優(yōu)化后，庫存熱點(diǎn)性能在高并發(fā)時(shí)提升近64倍。

    

  • 測試場景2：單個熱點(diǎn)行加32核CPU。

    測試結(jié)果：在單熱點(diǎn)行加32核CPU的場景下，引入熱點(diǎn)行性能優(yōu)化后，峰值QPS提升了63倍。高并發(fā)為8000時(shí)，性能提升了46倍。

    

  • 測試場景3：8個熱點(diǎn)行加32核CPU 。

    測試結(jié)果：在多熱點(diǎn)行（8個）加32核CPU的場景下，引入熱點(diǎn)行性能優(yōu)化后，峰值QPS提升了20倍。

    且當(dāng)高并發(fā)達(dá)到16000時(shí)，在未使用熱點(diǎn)行性能優(yōu)化功能的情況下，更新操作會導(dǎo)致數(shù)據(jù)庫出現(xiàn)故障無法返回更新操作結(jié)果。但使用熱點(diǎn)行性能優(yōu)化后，更新操作可以正常返回，且QPS維持穩(wěn)定。